[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-04 Thread luto at kernel dot org
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-04 Thread hjl.tools at gmail dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-04 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-04 Thread hjl.tools at gmail dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-04 Thread hjl.tools at gmail dot com
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 +

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-04 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 H.J. Lu changed: What|Removed |Added Attachment #41920|0 |1 is obsolete|

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-03 Thread hpa at zytor dot com
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.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-03 Thread luto at kernel dot org
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.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-03 Thread luto at kernel dot org
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-03 Thread hpa at zytor dot com
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,

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-03 Thread hjl.tools at gmail dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-03 Thread hjl.tools at gmail dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-08-02 Thread ubizjak at gmail dot com
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: > >

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-31 Thread ubizjak at gmail dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-20 Thread luto at kernel dot org
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 >

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-20 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-20 Thread ubizjak at gmail dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-20 Thread hpa at zytor dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 --- Comment #11 from H. Peter Anvin --- Not primarily.

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-20 Thread rguenth at gcc dot gnu.org
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?

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-20 Thread trippels at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread luto at kernel dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81490 Andy Lutomirski changed: What|Removed |Added CC||luto at kernel dot org --- Comment #8

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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)

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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

[Bug target/81490] x86: Handling of symbol ranges for __seg_fs/__seg_gs

2017-07-19 Thread hpa at zytor dot com
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