This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ptid from core section

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]