Re: [PATCH v8 09/10] Validate symbol file using build-id

[Doug Evans <dje@google.com>]

On Sat, Jun 27, 2015 at 4:05 PM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 23 Jun 2015 00:25:52 +0200, Doug Evans wrote:
>> On Sun, Jun 21, 2015 at 5:16 AM, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
>> > --- a/gdb/solist.h
>> > +++ b/gdb/solist.h
>> > @@ -75,6 +75,22 @@ struct so_list
>> >         There may not be just one (e.g. if two segments are relocated
>> >         differently); but this is only used for "info sharedlibrary".  */
>> >      CORE_ADDR addr_low, addr_high;
>> > +
>> > +    /* Build id in raw format, contains verbatim contents of
>> > +       .note.gnu.build-id including note header.
>>
>> Including the note header will be confusing to readers.
>> Is there a reason to include it?
>>
>> OTOH, given the above call to hex2bin,
>> does this really include the note header?
>
> It does not, only the comment was wrong.  Changed it to:
>     /* Build id decoded from .note.gnu.build-id without note header.  This is
>        actual BUILD_ID which comes either from the remote target via qXfer
>
>
>> > ... This is actual
>> > +       BUILD_ID which comes either from the remote target via qXfer
>> > +       packet or via reading target memory.  Therefore, it may differ
>> > +       from the build-id of the associated bfd.  In a normal
>> > +       scenario, this so would soon lose its abfd due to failed
>> > +       validation.
>>
>> I can't read this last sentence.
>> What are you trying to say here?
>
> It was written by Aleksandar Ristovski and I find it OK myself.
> So as an explanation the process is:
>
> 1. GDB reads/receives so->build_id from GDB server.
> 2. GDB opens local BFD so->abfd.
> 3. GDB compares so->build_id with so->abfd->build_id (by ops->validate)
> 4. If they differ so->abfd is freed/cleared (in solib_map_sections).
>
> Therefore could you suggest a different comment?

I'd be ok with just deleting the last two sentences:

This is actual
BUILD_ID which comes either from the remote target via qXfer
packet or via reading target memory.

But if you want more I'm ok with:

This is actual
BUILD_ID which comes either from the remote target via qXfer
packet or via reading target memory. Note that if there's a
mismatch with the associated bfd then so->abfd will be cleared.