Re: [PATCH 2/3] gdb: Add soname to build-id mapping for corefiles

[Tom Tromey <tom@tromey.com>]

>>>>> "Aaron" == Aaron Merey via Gdb-patches <gdb-patches@sourceware.org> writes:

>> Can you explain why we are opening bfd->filename?  Doesn't "abfd"
>> represent the exact same thing than "bfd"?  So why can't we use "bfd"
>> directly to look up the soname?

Aaron> bfd->flags does not contain the correct value.  This causes the check
Aaron> for ET_DYN to fail even for shared libraries.  Also bfd->build_id always
Aaron> seems to be NULL.  Opening "abfd" with gdb_bfd_open and passing it to
Aaron> bfd_check_format populates flags and build_id with the correct values.
Aaron> Passing "bfd" to bfd_check_format still does not populate these fields
Aaron> with the correct values.

Aaron> It looks like this happens because the format of "abfd" is initially
Aaron> set to bfd_unknown.  In this case bfd_check_format rereads the file and
Aaron> updates some fields with the correct values, including flags and build_id.
Aaron> Since format of "bfd" is instead bfd_object, bfd_check_format returns
Aaron> early and skips updating any fields.

This seems strange to me.

At first I was surprised that re-opening the BFD like this wouldn't
simply return the same BFD, since gdb uses a BFD cache.  However, now I
see that corelow isn't using the cache:

	    bfd = bfd_map[filename] = bfd_openr (expanded_fname.get (),
						 "binary");

(as opposed to using gdb_bfd_openr here.)

If re-opening and then calling bfd_check_format sets the flags
correctly, then I suppose the question is just why the call in
build_file_mappings isn't doing that:

	    if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))

Possibly the answer is that corelow passes "binary" as the target, but
your code does:

Aaron> +  gdb_bfd_ref_ptr abfd = gdb_bfd_open (bfd->filename, gnutarget);

But then I wonder why "binary" is appropriate in corelow.

Tom