Re: [review] Core file build-id support

[Keith Seitz <keiths@redhat.com>]

On 12/5/19 12:27 PM, Tom Tromey (Code Review) wrote:
> Tom Tromey has posted comments on this change.
> 
> Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/509
> ......................................................................
> 
> 
> Patch Set 1: Code-Review+2
> 
> (1 comment)
> 
> I'm sorry about the delay on this review.

No big deal -- there's still plenty to do in this area!

> This patch looks good.  Impressive test case!  Thank you for doing this.
> 
> I had one nit in a comment, but no need for a re-review.
> 
> One thing I don't understand is how shared libraries work in this scenario.
> How does gdb find the correct version of these from the core file?

That is coming up in a follow-on patch. I don't fully understand it, either,
just yet. I've been attempting to work my way through this recently.

> | --- gdb/build-id.h
> | +++ gdb/build-id.h
> | @@ -39,10 +37,19 @@ /* Find and open a BFD given a build-id.  If no BFD can be found,
> | -   the caller.  */
> | +/* Find and open a BFD for a debuginfo file  given a build-id.  If no BFD
> | +   can be found, return NULL.  The returned reference to the BFD must be
> | +   released by the caller.  */
> |  
> |  extern gdb_bfd_ref_ptr build_id_to_debug_bfd (size_t build_id_len,
> |  					      const bfd_byte *build_id);
> |  
> | +/* Find and open a BFD for an executable file given a build-id.  If no BFD
> | +   can be found, return NULL.  The returned reference to the BFD must be
> | +   released by the caller.  */
> 
> PS1, Line 46:
> 
> This text is just a leftover from before we had ref pointers.
> Now I think it's implicit in the type and can just be left out.
> 

Indeed. Just reading that and seeing gdb_bfd_ref_ptr makes me cringe. Forest,
meet trees.

Thank you for the reivew, I've pushed this.

Keith