Re: ptid from core section

[Aleksandar Ristovski <aristovski at qnx dot com>]

Pedro Alves wrote:
> On Thursday 04 June 2009 19:31:58, Aleksandar Ristovski wrote:
> > Pedro Alves wrote:
> > > This is mostly OK as far as I'm concerned.  One question though: 
> > >
> > > >         (ptid_from_core_section, core_section_name_from_ptid): New 
> > > > functions.
> > > Is there still a reason the former takes bfd and bfd section pointers,
> > > instead of being a mirror of the latter (say, ptid_from_core_section_name)?
> > Not a good reason. I just used what was available at the 
> > calling site. The attached patch makes arguments of the two 
> > new callbacks symmetrical (as much as was possible) as well 
> > as makes their names symmetrical.
> >
> > This time, gdbarch.[ch] included.
>
> Hmm, sorry I missed something before...
>
> AFAICS, core_gdbarch can end up being left NULL.   Most code
> that accesses it in corelow.c handles it's NULL-ness, while your

In core_open, there is already a gdbarch callback which 
doesn't check for its NULL-ness (piece added by me), namely 
gdbarch_target_signal_from_host.

What are the circumstances under which core_gdbarch would 
not be found? If we are opening a core from a system gdb was 
not configured for?


> change adds some unconditional accesses.  The path of
> least resistence to fix this, is to move the callback defaults
> to corelow.c, make the new callbacks optional, and check
> for 'core_gdbarch && gdbarch_foo_p (core_gdbarch)' predicates
> before calling the optional callbacks.
>
> ( This does raise the question of which gdbarch is the best in these
> case: core_gdbarch; the executable's gdbarch; the more refined
> target_gdbarch, which in turn is refined from current_gdbarch
> through core_read_description.  Yuk. )


--
Aleksandar Ristovski
QNX Software Systems