This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Increase the size of .data.rel section for -z relro check


Thanks for the explanation.  I still don't really understand why ld
doesn't produce a PT_GNU_RELRO for that test (which gold does).  But I
gleaned enough to adjust the test so that F15's ld, and trunk ld, and
trunk gold all pass it.

In fact, it does not work just to have a small writable data section.
(What I tried was 'int data = 1;'.)  However, that did work with -z now
added, for some reason.  I had to use an initialized data section of
substantial size to make it work.  It also didn't work with just .bss,
i.e. uninitialized data, no matter what the size.

In one of the permutations, it emitted a PT_NULL entry but still no
PT_GNU_RELRO.  I did not try every permutation with trunk ld (or with
gold, which AFAIK never fails to produce PT_GNU_RELRO), only with F15's.

Though I did not entire follow it, your explanation gave me the
impression that it would violate some intended constraint to produce
PT_GNU_RELRO from the original example (with a tiny .data.rel.ro and no
.data or .bss).  But gold does produce such a PT_GNU_RELRO and I can't
see anything wrong with what it produces.  (Seeing your explanation, Ian
didn't seem to think there was any reason gold shouldn't.)  I guess I
misunderstood you.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]