[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #5 from Richard Guenther 2012-01-19 09:16:32 UTC --- (In reply to comment #4) > Both ld and ld.so go extra efforts to make sure that > the same function pointer value is used for protected > function in the entire process. If we drop this requirement, > we can simplify ld and ld.so quite a bit. Well, if we make sure ld.so resolves the GOT entry to the function address instead of the PLT then that will work - in the module the protected symbol binds locally we get it resolved to the function address directly anyway (see GCC assembly from the testcase). Sounds easier allover the place, no? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13602] gold -Ttext and --section-start=.text mismatch
http://sourceware.org/bugzilla/show_bug.cgi?id=13602 --- Comment #2 from christophe.lyon at st dot com 2012-01-19 10:00:44 UTC --- Sorry, I thought gold was a drop-in replacement for bfd-ld. I could not find a gold man page in my binutils-2.22 install. Where should I look to have the actual gold man page? Thanks. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #6 from Alan Modra 2012-01-19 10:00:36 UTC --- In comment #2 I was forgetting what we do in an executable. In the main executable (which might be non-PIC), if we take the address of foo and the address of foo is written into a read-only section (.text or .rodata or somesuch) then we have a problem. You've got three choices: a) either the address location needs a dynamic relocation which results in that page of the executable being non-shared, or b) we need the hack of making the address of foo be the plt code for foo in the executable, with all the pain in ld.so that causes, or c) you ensure that function addresses never appear in read-only sections. At the moment we do (b), so I was wrong to say this was a ld bug unless it's true that x86_64 gcc already does (c). -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #7 from rguenther at suse dot de 2012-01-19 10:22:22 UTC --- On Thu, 19 Jan 2012, amodra at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=13600 > > --- Comment #6 from Alan Modra 2012-01-19 10:00:36 > UTC --- > In comment #2 I was forgetting what we do in an executable. In the main > executable (which might be non-PIC), if we take the address of foo and the > address of foo is written into a read-only section (.text or .rodata or > somesuch) then we have a problem. You've got three choices: > a) either the address location needs a dynamic relocation which results in > that > page of the executable being non-shared, or > b) we need the hack of making the address of foo be the plt code for foo in > the > executable, with all the pain in ld.so that causes, or > c) you ensure that function addresses never appear in read-only sections. > > At the moment we do (b), so I was wrong to say this was a ld bug unless it's > true that x86_64 gcc already does (c). Why is it not a ld bug that it doesn't do what GCC asks it to do? That is, bind foo locally? It sure can do that. Whether what GCC asks it to do is "bad" is a completely different issue, no? For the issue you bring up you are thinking of extern void foo (void); const void *p = (void *)foo; ? Regardless of if the app is PIC, PIE or not GCC generates .globl p .data .align 8 .type p, @object .size p, 8 p: .quad foo thus, it doesn't put p into .rodata (it needs a relocation after all). So, how would you put those function address into a readonly section? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600
--- Comment #8 from Alan Modra 2012-01-19 10:50:45
UTC ---
const void *const p = (void *)foo; might be more interesting. Or
const struct blah {
int (*f) ();
int x,y,z,w;
} f = { .f = printf };
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600
--- Comment #9 from rguenther at suse dot de 2012-01-19 11:05:40 UTC ---
On Thu, 19 Jan 2012, amodra at gmail dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=13600
>
> --- Comment #8 from Alan Modra 2012-01-19 10:50:45
> UTC ---
> const void *const p = (void *)foo; might be more interesting. Or
>
> const struct blah {
> int (*f) ();
> int x,y,z,w;
> } f = { .f = printf };
Both go to .rodata. But that of course has the same problems, whether
foo's defintion is protected or default?
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #10 from Alan Modra 2012-01-19 11:57:15 UTC --- That's why you make the address of foo the plt entry for foo in the executable. The address is fixed at link time. However, it does mean that address of a default or protected visibility foo in a shared lib must have a relocation. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #11 from rguenther at suse dot de 2012-01-19 12:04:23 UTC --- On Thu, 19 Jan 2012, amodra at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=13600 > > --- Comment #10 from Alan Modra 2012-01-19 11:57:15 > UTC --- > That's why you make the address of foo the plt entry for foo in the > executable. Well, if I put that constant into a shared library _and_ I put one into the executable I'm still lost, no? Btw, with -fPIC or -fPIE GCC puts the constants in .data.rel.ro instead. > The address is fixed at link time. However, it does mean that address of a > default or protected visibility foo in a shared lib must have a relocation. Which means a lost optimization (we need to go through the GOT here). But well, I guess it's supposed to pay off in the executable which requires only one relocation for each address-taken function. Still, if GCC tells ld to resolve the address of a protected visibility foo in a shared lib without a relocation why can't it simply do so as surely it is techincally possible? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #12 from Alan Modra 2012-01-19 12:49:02 UTC --- > Well, if I put that constant into a shared library _and_ I put one into > the executable I'm still lost, no? No, because shared libraries must be -fpic/PIC and as you note > Btw, with -fPIC or -fPIE GCC puts the constants in .data.rel.ro > instead. and .data.rel.ro can have relocs. > Which means a lost optimization (we need to go through the GOT here). Choose your poison. :) > Still, if GCC tells ld to resolve the address of a protected visibility > foo in a shared lib without a relocation why can't it simply do so > as surely it is techincally possible? It is possible, but will break function pointer comparisons if a pointer to foo is passed between the shared lib and executable in either direction, since the address of foo in the shared lib and the address of the same foo in the executable will be different. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/13600] protected visibility creates bogus relocation
http://sourceware.org/bugzilla/show_bug.cgi?id=13600 --- Comment #13 from rguenther at suse dot de 2012-01-19 13:22:03 UTC --- On Thu, 19 Jan 2012, amodra at gmail dot com wrote: > http://sourceware.org/bugzilla/show_bug.cgi?id=13600 > > --- Comment #12 from Alan Modra 2012-01-19 12:49:02 > UTC --- > > Well, if I put that constant into a shared library _and_ I put one into > > the executable I'm still lost, no? > > No, because shared libraries must be -fpic/PIC and as you note > > > Btw, with -fPIC or -fPIE GCC puts the constants in .data.rel.ro > > instead. > > and .data.rel.ro can have relocs. > > > Which means a lost optimization (we need to go through the GOT here). > > Choose your poison. :) > > > Still, if GCC tells ld to resolve the address of a protected visibility > > foo in a shared lib without a relocation why can't it simply do so > > as surely it is techincally possible? > > It is possible, but will break function pointer comparisons if a pointer to > foo > is passed between the shared lib and executable in either direction, since the > address of foo in the shared lib and the address of the same foo in the > executable will be different. True. Just GCC did it that way since forever ... I don't have older ld to verify if only now ld rejects this behavior (there is certainly a set of programs that were not affected by this "bug" of GCC that now ld breaks). We'll fix the GCC issue on the GCC side. Richard. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12017] Would like to disable compiler warning re use of tmpnam
http://sourceware.org/bugzilla/show_bug.cgi?id=12017 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton 2012-01-19 17:12:15 UTC --- As has been pointed out the warning is actually originating in the C library that you are using, not the compiler or the linker. There are a couple of workarounds that might be applicable to you: *) You could post-process gcc's output and strip out the warning message. *) You could remove the offending section (.gnu.warning) from the C library (in the tmpman.o archive element). *) You could use a custom linker script that discards the particular .gnu.warning section. Fixing the problem by disabling all warnings generated via .gnu.warning sections is a very bad idea. These warnings are not meant to be ignored. The specific tmpnam warning could be suppressed[1] but I am not particularly keen on the idea. Cheers Nick [1]: Search the linker sources for instances of warn_multiple_gp to see how this has already been done for a different warning message. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12017] Would like to disable compiler warning re use of tmpnam
http://sourceware.org/bugzilla/show_bug.cgi?id=12017 Mike Frysinger changed: What|Removed |Added CC||vapier at gentoo dot org --- Comment #3 from Mike Frysinger 2012-01-19 20:17:28 UTC --- i believe latest glibc builds do .gnu.warning., so that might make it easier to filter (by throwing out the .gnu.warning.tmpnam section) -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/13602] gold -Ttext and --section-start=.text mismatch
http://sourceware.org/bugzilla/show_bug.cgi?id=13602 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Ian Lance Taylor 2012-01-20 06:19:22 UTC --- There is no gold man page as yet. Sorry. gold is not a pure drop-in replacement for GNU ld. It is for normal use, but it is impossible to make it identical in all cases. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
