https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #23 from Fangrui Song ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
>
> I gave you the correct usage for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #22 from Yuxuan Shui --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #20 from Yuxuan Shui ---
(In reply to Andrew Pinski from comment #18)
> (In reply to Yuxuan Shui from comment #17)
> > Sorry, I am here to report a bug, not to find a workaround for my use case.
>
> I gave you the correct usage for y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Resolution|WORKSFORME |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #18 from Andrew Pinski ---
(In reply to Yuxuan Shui from comment #17)
> Sorry, I am here to report a bug, not to find a workaround for my use case.
I gave you the correct usage for your use case. If you don't like it is not my
fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #17 from Yuxuan Shui ---
(In reply to H.J. Lu from comment #16)
> (In reply to Yuxuan Shui from comment #15)
> > Your code is going to dereference the value stored in the ABS symbol as an
> > address (e.g. if the symbol has value 10,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #16 from H.J. Lu ---
(In reply to Yuxuan Shui from comment #15)
> Your code is going to dereference the value stored in the ABS symbol as an
> address (e.g. if the symbol has value 10, your code will access (*(char
> *)10), barring th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #15 from Yuxuan Shui ---
(In reply to H.J. Lu from comment #12)
> (In reply to Yuxuan Shui from comment #11)
> > (In reply to Andrew Pinski from comment #8)
> > > Also it is wrong for a person to assume a normal C variable could be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #14 from H.J. Lu ---
(In reply to H.J. Lu from comment #13)
> The current relocation doesn't support PC32 relocation against SHN_ABS
> in PIE nor shared library. I will change ld to issue an error.
I opened:
https://sourceware.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #13 from H.J. Lu ---
The current relocation doesn't support PC32 relocation against SHN_ABS
in PIE nor shared library. I will change ld to issue an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #12 from H.J. Lu ---
(In reply to Yuxuan Shui from comment #11)
> (In reply to Andrew Pinski from comment #8)
> > Also it is wrong for a person to assume a normal C variable could be
> > SHN_ABS; that is the bug here. It is a bug in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #11 from Yuxuan Shui ---
(In reply to Andrew Pinski from comment #8)
> Also it is wrong for a person to assume a normal C variable could be
> SHN_ABS; that is the bug here. It is a bug in the user code.
> I showed up to fix it by usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #10 from Fangrui Song ---
> extern unsigned long _binary_a_c_size;
> unsigned long foo() { return _binary_a_c_size; }
This is incorrect. The code will treat the value of _binary_a_c_size as an
address (load base + size) and dereferen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #9 from H.J. Lu ---
(In reply to Fangrui Song from comment #5)
> This bug exposes several problems:
>
> * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS
> symbol
> * GCC should not produce R_X86_64_PC32 referen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #8 from Andrew Pinski ---
Also it is wrong for a person to assume a normal C variable could be SHN_ABS;
that is the bug here. It is a bug in the user code.
I showed up to fix it by using an top level inline-asm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #7 from Andrew Pinski ---
(In reply to Fangrui Song from comment #5)
> This bug exposes several problems:
>
> * GNU ld does not reject a PC-relative relocation referencing a SHN_ABS
> symbol
> * GCC should not produce R_X86_64_PC32 r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
--- Comment #6 from Fangrui Song ---
> It is incorrect to reference a non-preemptible symbol with a PC relative
> relocation in a -pie link. GNU ld allows it but the code can be incorrect at
> runtime.
Correction: It is incorrect to reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5 from F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
H.J. Lu changed:
What|Removed |Added
Resolution|WONTFIX |WORKSFORME
--- Comment #4 from H.J. Lu ---
(I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Yuxuan Shui changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94391
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
23 matches
Mail list logo
