This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v8 09/10] Validate symbol file using build-id
- From: Doug Evans <dje at google dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, Aleksandar Ristovski <ARistovski at qnx dot com>
- Date: Wed, 8 Jul 2015 10:39:14 -0500
- Subject: Re: [PATCH v8 09/10] Validate symbol file using build-id
- Authentication-results: sourceware.org; auth=none
- References: <20150614192542 dot 18346 dot 87859 dot stgit at host1 dot jankratochvil dot net> <20150614192655 dot 18346 dot 17075 dot stgit at host1 dot jankratochvil dot net> <20150621101644 dot GA12733 at host1 dot jankratochvil dot net> <CADPb22TH5nfFSkCzW9cCiHuoJFAG+P5z=qZawgwGUgYQ5kfd5Q at mail dot gmail dot com> <20150627210519 dot GA19048 at host1 dot jankratochvil dot net>
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.