dynrelro section for read-only dynamic symbols copied into executable

Alan Modra amodra@gmail.com
Fri Jan 6 22:41:00 GMT 2017


On Fri, Jan 06, 2017 at 06:43:05PM +0000, Szabolcs Nagy wrote:
> On 06/01/17 10:47, Kyrill Tkachov wrote:
> > 
> > On 03/01/17 11:56, Alan Modra wrote:
> >> On Tue, Jan 03, 2017 at 11:12:38AM +0100, Christophe Lyon wrote:
> >>> For the record, I see failures on some arm targets:
> >>> FAIL: Build pr20995-2.so
> >>> FAIL: pr20995-2
> >>> for arm-netbsdelf and arm-none-eabi
> >> That will be because these tests require working -z relro support, at
> >> least to the point of generating a GNU_RELRO header.
> >>
> > 
> > So should these tests be XFAILED on arm targets?

Probably not.

> i think arm has -z relro support however PT_GNU_RELRO
> header is not emitted if there is no DATA_SEGMENT_RELRO_END
> specification in the linker script (which we probably
> only have on linux, since shared libs and related features
> are not used on baremetal targets).
> 
> i assume we could change the arm elf linker script, but
> i don't know what are the exact implications of that.

COMMONPAGESIZE needs to be defined in a target's ld/emulparams/ file.
-z relro will then actually do something.

Before doing this you probably should check that the target system
ld.so will not be confused by the presense of a PT_GNU_RELRO header.
(I think current netbsd does support it.)

Since arm-none-eabi is a generic target, anyone using it likely
doesn't create shared libraries.  However, I see that shared libs are
supported so you may as well support relro there too.

-- 
Alan Modra
Australia Development Lab, IBM



More information about the Binutils mailing list