Re: ptid from core section

[Aleksandar Ristovski <aristovski@qnx.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