This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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] |
On Monday, September 19, 2011 15:35:40 Joseph S. Myers wrote: > On Mon, 19 Sep 2011, Mike Frysinger wrote: > > the logic in setjmp/__longjmp incorrectly tie to "PIC" to figure out > > whether the code is going into a shared library when it should be using > > "SHARED". otherwise, building static PIC code goes wrong. > > You'll need to give a better explanation (testcase) of what you mean by > "goes wrong". failure to link due to wrong symbol name used > Static PIEs aren't supported on x86_64 so I don't suppose they are > supported on ARM; PIEs have to use shared libraries. upstream glibc tends to list static PIEs as unsupported. in practice, they do work because glibc has proper "PIC" and "SHARED" differentiation, and Gentoo has long enabled support for these when people ask (our hardened setup builds everything as PIC/PIE). > But if they were > supported, the PIC code here looks better than the non-PIC - you can't > just put an absolute address in a constant pool in the text section in > position-independent code the way the non-PIC code does; the conditional > really does seem to be about "must the text be position-independent?". so it sounds there are two issues. there is PIC code behind "#ifdef PIC" which is good, but the code also decides which symbol name (which is a SHARED define) via PIC ? that's the part that i'm trying to fix. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |