http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #31 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #30 from Thiago Macieira 2012-01-19
18:52:57 UTC ---
This does solve the problem.
It's just unfortunate that it does so by creating more work for the library
even if no executable ever takes the address of this protected function.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #29 from H.J. Lu 2012-01-19 18:29:39
UTC ---
(In reply to comment #28)
> Final conclusion: We need to resolve to the executables PLT consistently,
> even from inside the shared object where the function binds locally. This
> is beca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
Richard Guenther changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #27 from Richard Guenther 2012-01-18
15:17:19 UTC ---
(In reply to comment #26)
> The linker, however, mandates that the address to symbol should not be loaded
> directly, but only through the GOT. This is necessary because the psABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #26 from Thiago Macieira 2012-01-18
13:28:05 UTC ---
ld *can* link, it just chooses not to.
$ cat > foo.c
__attribute__((visibility("protected")))
void * foo (void) { return (void *)foo; }
$ gcc -fPIC -shared foo.c
/usr/b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #25 from Richard Guenther 2012-01-18
09:21:14 UTC ---
LD bug: http://sourceware.org/bugzilla/show_bug.cgi?id=13600
The GCC side is a QOI thing and maybe a conformance thing. ICC generates
for
__attribute__((visibility("protected"))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
Andrew Pinski changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Comment #23 from Thiago Macieira 2012-01-16
14:56:50 UTC ---
I've changed my opinion on this matter. I think GCC is generating the proper
code (most efficient). It's ld that should accept this decision.
--- Comment #22 from thiago at kde dot org 2007-01-11 18:42 ---
Is there any update on this bug?
According to http://sourceware.org/ml/binutils/2005-01/msg00401.html, a
protected function symbol cannot be used in a R_386_GOTOFF. I don't claim to
understand the full implications of the i
--- Comment #21 from simon dot strandman at telia dot com 2005-11-06 09:50
---
(In reply to comment #18)
> I posted an updated patch
>
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html
>
> I hope it will work better.
Sorry to bother but where is the updated patch? That link l
--- Additional Comments From hjl at lucon dot org 2005-02-03 15:59 ---
Each psABI defines how function address works. Not all of psABIs have
the same treatment for function address. Function address may mean different
things for different psABIs. You can't even compare function address be
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-03 15:51
---
FWIW, the reason this leaves a bad taste in my mouth is that I strongly believe
symbol visibility should be consistent between ELF platforms. There's at least
one ELF platform where resolving a function pointe
--- Additional Comments From hjl at lucon dot org 2005-02-02 23:05 ---
I posted an updated patch
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00196.html
I hope it will work better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Additional Comments From hjl at lucon dot org 2005-02-02 16:17 ---
Please keep in mind that my proposal affects FUNCTION symbols only and my change
won't change function CALL, which will still be local. It only changes the
function pointer.
BTW, I believe ld.so in the current glibc i
--- Additional Comments From amodra at bigpond dot net dot au 2005-02-02
13:15 ---
Confirming that the bug is real.
I can't say I like HJ's solution though. It seems to require that ld.so resolve
a protected symbol in a shared library to a symbol defined in the main app.
That's weird.
--- Additional Comments From hjl at lucon dot org 2005-01-24 18:35 ---
This is the updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01551.html
This is the testcase patch:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01550.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Additional Comments From hjl at lucon dot org 2005-01-21 06:47 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01394.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--
What|Removed |Added
CC||ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Additional Comments From ian at airs dot com 2005-01-21 06:35 ---
I think this bug report is reporting an actual bug. At least when using ELF,
when the compiler takes the address of a protected function, it has to act as
though it is taking the address of an ordinary function, and re
--- Additional Comments From hjl at lucon dot org 2005-01-20 22:34 ---
Ignore the copy relocation. There is not much a compiler can do when the psABI
doesn't support protected symbols with copy relocation. See:
http://sources.redhat.com/ml/binutils/2003-03/msg00413.html
--
http://gcc
--- Additional Comments From hjl at lucon dot org 2005-01-20 19:28 ---
Depending on the psABI, because of copy relocation on data symbols and
function pointer on function symbols, a protected symbol has to be
treated very carefully. We have to check 2 things:
1. If the psABI uses copy re
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
03:41 ---
Well I think there is wrong reloc somewhere or a reloc being resolved wrongly
because foo binds locally in x.c otherwise the protect is visibility is really
useless otherwise (except
maybe to make sure tha
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
03:31 ---
So help out here, which is more correct the GOT or the GOTOFF?(In reply to
comment #7)
> Please take a closer look at the testcase. It is different from
> bug 10908. Basically, main executable and DSO see d
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
03:11 ---
The difference between non protected and protected functions is the following
in the asm:
movl[EMAIL PROTECTED](%ebx), %eax
leal[EMAIL PROTECTED](%ebx), %eax
but really add -fPIC to
--- Additional Comments From hjl at lucon dot org 2005-01-19 01:47 ---
Please take a closer look at the testcase. It is different from
bug 10908. Basically, main executable and DSO see different
function pointer values for the SAME function. From the linker
/* Will references to this sym
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
00:56 ---
protected always binds local as you cannot override it so the bug is in the
linker/asm.
*** This bug has been marked as a duplicate of 10908 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
00:47 ---
This is really a dup of bug 10908.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Additional Comments From hjl at lucon dot org 2005-01-19 00:41 ---
They aren't the same. It is function pointer vs. function. The other looks
like a linker bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Additional Comments From hjl at lucon dot org 2005-01-19 00:35 ---
The same bug also happen on i686-pc-linux-gnu:
gcc -fPIC -c -o x.o x.c
gcc -shared -o libx.so x.o
gcc -o foo m.c libx.so -Wl,-rpath,.
./foo
called from main foo_p: 0x80483e4
called from shared foo: 0x111524
shared f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
00:34 ---
Isn't this just binutils ld/584?
http://sources.redhat.com/bugzilla/show_bug.cgi?id=584
Alan M. claims this is a ld bug rather than a gcc bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
--- Additional Comments From hjl at lucon dot org 2005-01-19 00:27 ---
Created an attachment (id=7985)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7985&action=view)
A testcase
With the new linker, I got
[EMAIL PROTECTED] x86_64-3]$ make
gcc -fPIC -c -o x.o x.c
gcc -shared -o l
32 matches
Mail list logo
