https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Nick Desaulniers changed:
What|Removed |Added
CC||ndesaulniers at google dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #14 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:ab0b5fbfe90168d2e470aefb19e0cf31526290bc
commit r12-7126-gab0b5fbfe90168d2e470aefb19e0cf31526290bc
Author: H.J. Lu
Date: Sat Jun 19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #13 from Fangrui Song ---
(In reply to H.J. Lu from comment #12)
> We should handle it in the whole Linux software stack:
>
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
>
> not just in compiler.
It is great that you have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #11 from Fangrui Song ---
(In reply to Alexander Monakov from comment #10)
> Is there something wrong or undesirable with making this under -fno-plt (or
> the noplt attribute as in your example)?
>
> (after all, it is a kind of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #10 from Alexander Monakov ---
Is there something wrong or undesirable with making this under -fno-plt (or the
noplt attribute as in your example)?
(after all, it is a kind of PLT-avoidance transformation, just for addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #9 from Fangrui Song ---
I have a patch to implement this Clang.
It'd be good to have a name even if GCC wants to postpone the implementation
for now. How about -fdirect-access-external-function &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #8 from Fangrui Song ---
Seems that -fno-plt -fno-pic does have the required properties.
A side effect is that all external calls use the (x86-64) call
*f@GOTPCREL(%rip) (x86-32) call *f@GOT form.
The instruction is one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #7 from Alexander Monakov ---
Thanks. I agree that inferring address significance on the linker side is
problematic.
Thinking about your original request, I was about to say that it would be very
reasonable to do under -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #6 from Fangrui Song ---
(In reply to Alexander Monakov from comment #5)
> Hm, I still don't think I'm misunderstanding what you're saying. I'm
> familiar with the ELF standard (and FWIW I have read your blog posts on
> related
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #5 from Alexander Monakov ---
Hm, I still don't think I'm misunderstanding what you're saying. I'm familiar
with the ELF standard (and FWIW I have read your blog posts on related
matters). I am responding to this sentiment from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #4 from Fangrui Song ---
(In reply to Alexander Monakov from comment #3)
> I understand what you're saying, but it seems we're talking past each other.
>
> I agree that if a library is linked with any -Bsymbolic* flag, the main
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #3 from Alexander Monakov ---
I understand what you're saying, but it seems we're talking past each other.
I agree that if a library is linked with any -Bsymbolic* flag, the main
executable is at risk of broken address uniqueness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
--- Comment #2 from Fangrui Song ---
(In reply to Alexander Monakov from comment #1)
> It is not necessary to change -fno-pic code generation to gain most of the
> -Bsymbolic benefit
It is necessary, otherwise the function address taken from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100593
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
16 matches
Mail list logo
