Re: PT_GNU_RELRO flags

[jose dot marchesi at oracle dot com (Jose E. Marchesi)]

    > The thing is, eu-elflint checks precisely for that, and complains for
    > shared objects linked with -zrelro:
    > 
    >   loadable segment [5] flags do not match GNU_RELRO [1] flags
    > 
    > Was this change intended?  Does it makes sense to have RELRO=R/LOAD=RWE
    > pairs in elf files? (RELRO segments contain .plt sections in sparc, for
    > example, and I would expect these to be executable...).
    
    The change was intended to fix a problem with objcopy/strip when
    making separate debug files from executables created by gold.  I
    don't think there was an intention to change the behaviour of ld.
    
    However, I like the current GNU ld behaviour of setting PT_GNU_RELRO
    p_flags to PF_R.  Of any flag value I think that makes most sense
    because that is the protection applied to the RELRO segment by glibc.
    (See elf/dl-reloc.c:_dl_protect_relro.)  Some larger PT_LOAD segment
    covering the same addresses might indeed be PF_X, but I don't see that
    being relevant.

    The smaller PT_GNU_RELRO segment does not contain executable
    sections.  (You're wrong in your claim that RELRO segments contain
    .plt sections in sparc binaries.  They don't.  The RELRO segment
    finishes just before .plt.)

Ugh, right.  I misread the output of readelf -l.  Well, I agree: it
makes all sense to have the same perms that are applied later by the
dynamic loader, and E is not needed.

Time to update the elfutils test.