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: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>, Aleksandar Ristovski <ARistovski at qnx dot com>
- Date: Sat, 27 Jun 2015 23:05:19 +0200
- 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>
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?
Thanks,
Jan