This is the mail archive of the
mailing list for the glibc project.
Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
- From: Florian Weimer <fweimer at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 07 Nov 2018 19:27:30 +0100
- Subject: Re: V2 [PATCH] Check multiple NT_GNU_PROPERTY_TYPE_0 notes [BZ #23509]
- References: <CAMe9rOoXP7fz+XaM5hFnzDa=qSzz=8r3HkoddaTscrh7HUt03g@mail.gmail.com> <firstname.lastname@example.org> <CAMe9rOoAXzKfS0Ce=CF+pZhyQ2-Pzq6U+5a-pNx9M2fEKE-Vcg@mail.gmail.com> <email@example.com>
* 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.
Or am I confused about this?