binutils ld and new PT_GNU_PROPERTY segment
Mark Wielaard
mark@klomp.org
Thu Feb 20 22:43:00 GMT 2020
More information about the Binutils mailing list
Thu Feb 20 22:43:00 GMT 2020
- Previous message (by thread): binutils ld and new PT_GNU_PROPERTY segment
- Next message (by thread): binutils ld and new PT_GNU_PROPERTY segment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi, On Thu, 2020-02-20 at 03:51 -0800, H.J. Lu wrote: > On Thu, Feb 20, 2020 at 1:37 AM Mark Wielaard <mark@klomp.org> wrote: > > On Wed, 2020-02-19 at 14:17 -0800, H.J. Lu wrote: > > > > > > Binaries with .note.gnu.property section have been put into many > > > OS releases. We must support them. > > > > OK. Then it is option 1. The kernel will need to support PT_NOTE for > > parsing the properties, since such older binaries won't have a > > PT_GNU_PROPERTY program header. Then we can simply get rid of > > PT_GNU_PROPERTY since nobody uses it and all information is already > > available through the PT_NOTE segment. > > > > Kernel loader only checks ld.so and static executable. Re-link them with > newer linker will get PT_GNU_PROPERTY. But ld.so needs to check > PT_NOTE for older binaries. Having different loaders check different program headers seems very confusing. And it doesn't really seem to provide backwards compatibility since depending on how the code was linked previously you might still require a rebuild. Having a mix of PT_NOTE/PT_GNU_PROPERTY segments both based on SHT_NOTEs, but one of them based on magic section names, makes things really complicated for other tools. Please lets either really keep things as they are or redesign things based on PT_GNU_PROPERTY and a new section type. Thanks, Mark
- Previous message (by thread): binutils ld and new PT_GNU_PROPERTY segment
- Next message (by thread): binutils ld and new PT_GNU_PROPERTY segment
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list