This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 7 Nov 2018 12:24:25 -0800
- Subject: Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
- References: <CAMe9rOoXP7fz+XaM5hFnzDa=qSzz=8r3HkoddaTscrh7HUt03g@mail.gmail.com> <87a7ocmtvd.fsf@oldenburg.str.redhat.com> <CAMe9rOoAXzKfS0Ce=CF+pZhyQ2-Pzq6U+5a-pNx9M2fEKE-Vcg@mail.gmail.com> <871s9mdhy8.fsf@oldenburg.str.redhat.com> <87ftwcg2ul.fsf@oldenburg.str.redhat.com>
On Wed, Nov 7, 2018 at 10:27 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Florian Weimer:
>
> >>> If yes, this should be mentioned in the commit message.
> >>>
> >>> This seems to be an unrelated change?
> >>>
> >>> + /* Property type must be in ascending order. */
> >>> + if (type < last_type)
> >>> + return;
> >>>
> >>
> >> This is the part of property spec. If properties aren't properly
> >> sorted, it is invalid.
> >
> > Okay, that part makes sense because it's internal to the notes AFAICS.
> > And note merging without GNU property note awareness will likely violate
> > this constraint. Maybe you could add a comment to this effect?
>
> Hmm, isn't the point that this is the internal type in the note (not the
> tag), and there isn't any *note* merging, only note *section* merging in
> an old linker. The latter leaves the note boundaries intact, so the
> internal layout will be unmodified.
>
Older linkers will concatenate all input GNU property note sections
into a single output GNU property note section without merging them.
--
H.J.