https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #10 from Andrew Pinski ---
(In reply to Rui Ueyama from comment #6)
> If it silently produces a value that doesn't make sense, shouldn't we ban
> the use of the variable or at least show a warning?
That is PR 51437 for a warning on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #8 from H.J. Lu ---
GCC generates _GLOBAL_OFFSET_TABLE_ to indicate GOTPC32 relocation. It can't
be
treated as a normal symbol.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
H.J. Lu changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #6 from Rui Ueyama ---
If it silently produces a value that doesn't make sense, shouldn't we ban the
use of the variable or at least show a warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #5 from H.J. Lu ---
To access this special symbol:
[hjl@gnu-tgl-3 tmp]$ cat c.c
#include
extern char GLOBAL_OFFSET_TABLE[];
char *ptr = GLOBAL_OFFSET_TABLE;
int main() {
printf("%lx\n", (unsigned long)ptr);
}
[hjl@gnu-tgl-3 tmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #4 from Jakub Jelinek ---
I think there are ways to get around it, adding an alias to _G_O_T_ and using
that alias.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
--- Comment #3 from Alexander Monakov ---
It would be unfortunate if that makes it difficult or even impossible to make a
R_386_32 relocation for the address of GOT in hand-written assembly.
In any case, it seems GCC is not making the rules her
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106835
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
10 matches
Mail list logo
