https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #28 from Andy Lutomirski ---
hjl, I don't understand what problem you're trying to solve here. Your patch
makes it relatively straightforward to access global variables using __seg_gs
if the environment sets up the %gs base exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #27 from H.J. Lu ---
(In reply to H. Peter Anvin from comment #26)
> @GPREL (altough it probably should be @GPOFF by analogy with @TPOFF?) gives
> the linker an option to distinguish the relocations which need to be
> adjusted at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #26 from H. Peter Anvin ---
@GPREL (altough it probably should be @GPOFF by analogy with @TPOFF?) gives the
linker an option to distinguish the relocations which need to be adjusted at
link/load time and the ones that don't.
We have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #25 from H.J. Lu ---
Comment on attachment 41920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41920
A binutils patch
This has been replaced by users/hjl/gprel/master branch at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #24 from H.J. Lu ---
(In reply to Andy Lutomirski from comment #20)
>
> Can someone elaborate on what the @GPREL suffix actually means?
"%seg:foo@GPREL" is used to address symbol, foo, relative to __gp. foo is
addressed by %seg +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
H.J. Lu changed:
What|Removed |Added
Attachment #41920|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #22 from H. Peter Anvin ---
There are other issues, too (we'd have to drop the kernel memory model,
probably replace it with the small-pic model) but %gs: addressing is one of
those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #21 from Andy Lutomirski ---
Re: the stack canary, I filed bug 81708. It seems to me that __seg_gs is
analogous and users should be able to directly specify the addressing mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #20 from Andy Lutomirski ---
We have issues putting modules more than 2G from the main kernel no matter
what, but I don't see what this has to do with %gs addressing.
I still think that GCC should let us directly control the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #19 from H. Peter Anvin ---
So the Linux kernel, right now, basically does (b); we'd like to do something
more like (a).
Because the stack canary (which is a percpu variable in the Linux kernel) is
hard-coded in gcc to be %gs:0x28,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #18 from H.J. Lu ---
(In reply to H.J. Lu from comment #17)
> Created attachment 41920 [details]
> A binutils patch
>
With this patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 587dbe61e8b..953c153a834
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #17 from H.J. Lu ---
Created attachment 41920
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41920=edit
A binutils patch
This binutils patch adds R_X86_64_GPREL to assembler and linker. It
supports:
.text
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #16 from Uroš Bizjak ---
(In reply to Andy Lutomirski from comment #14)
> (In reply to H. Peter Anvin from comment #13)
> > On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com
> > wrote:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #15 from Uroš Bizjak ---
I'm testing the following patch:
--cut here--
Index: i386.c
===
--- i386.c (revision 250745)
+++ i386.c (working copy)
@@ -19421,8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #14 from Andy Lutomirski ---
(In reply to H. Peter Anvin from comment #13)
> On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com
> wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #13 from H. Peter Anvin ---
On July 20, 2017 10:47:54 AM PDT, ubizjak at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
>
>--- Comment #12 from Uroš Bizjak ---
>(In reply to Andy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #12 from Uroš Bizjak ---
(In reply to Andy Lutomirski from comment #8)
> I would like to see something along these lines but even stronger: a way to
> instruct GCC to use a particular type of access and relocation. For
> example, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #11 from H. Peter Anvin ---
Not primarily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #10 from Richard Biener ---
Am I correct that this is about __seg uses in inline asm?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
Andy Lutomirski changed:
What|Removed |Added
CC||luto at kernel dot org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #7 from H. Peter Anvin ---
Thinking about this some more, this is really not an aspect of __seg_* but
rather the section the symbol is placed in. An embedded system kernel, for
example, could quite possibly want to access an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #6 from H. Peter Anvin ---
It is probably inappropriate to generate non-absolute address references for
these symbols for any kind of PIC or PIE output (as that would require unwanted
relocation!), so #2 is probably not really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #5 from H. Peter Anvin ---
The test case was compiled with:
gcc -fno-plt -fpie -fvisibility=hidden -mcmodel=small -O2
(note: no code changes between -fpie and -fpic)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #4 from H. Peter Anvin ---
Created attachment 41801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41801=edit
Test case: assembly output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #3 from H. Peter Anvin ---
Created attachment 41800
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41800=edit
Test case: preprocessor output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #2 from H. Peter Anvin ---
Created attachment 41799
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41799=edit
Test case: object file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490
--- Comment #1 from H. Peter Anvin ---
Created attachment 41798
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41798=edit
Test case: source code
28 matches
Mail list logo