Re: [x32] Allow R_X86_64_64
>>> On 12.08.11 at 06:37, "H.J. Lu" wrote:
> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote:
>> Hi,
>>
>> It turns out that x32 needs R_X86_64_64. One major reason is
>> the displacement range of x32 is -2G to +2G. It isn't a problem
>> for compiler since only small model is required for x32.
>>
>> However, to address 0 to 4G directly in assembly code, we have
>> to use R_X86_64_64 with movabs. I am checking the follow patch
>> into x32 psABI to allow R_X86_64_64.
>>
>>
>
> X32 Linker should treats R_X86_64_64 as R_X86_64_32
> zero-extended to 64bit for output. I will update x32 psABI with
I'm sorry to say that, but the situation about x32 seems to be
getting worse with each change you do, every time again
revolving around mixing up ABI specification and a particular
implementation thereof.
Here, if you need something zero-extended (though I can't see
why you would), then you should use a new relocation type. As
pointed out before, there are valid possible uses of R_X86_64_64
that would require the semantics of x86-64.
Jan
> ---
> diff --git a/object-files.tex b/object-files.tex
> index 7f0fd14..d1543b5 100644
> --- a/object-files.tex
> +++ b/object-files.tex
> @@ -451,7 +451,7 @@ or \texttt{Elf32_Rel} relocation.
>\multicolumn{1}{c}{Calculation} \\
>\hline
>\texttt{R_X86_64_NONE} & 0 & none & none \\
> - \texttt{R_X86_64_64} & 1 & \textit{word64} & \texttt{S + A} \\
> + \texttt{R_X86_64_64} $^{\dagger\dagger}$ & 1 & \textit{word64}
> & \texttt{S + A} \\
>\texttt{R_X86_64_PC32} & 2 & \textit{word32} & \texttt{S + A - P} \\
>\texttt{R_X86_64_GOT32} & 3 & \textit{word32} & \texttt{G + A} \\
>\texttt{R_X86_64_PLT32} & 4 & \textit{word32} & \texttt{L + A - P} \\
> @@ -487,6 +487,8 @@ or \texttt{Elf32_Rel} relocation.
> % \texttt{R_X86_64_PLT64} & 17 & \textit{word64} & \texttt{L + A - P} \\
> \cline{1-4}
> \multicolumn{3}{l}{\small $^\dagger$ This relocation is used only
> for LP64.}\\
> +\multicolumn{3}{l}{\small $^{\dagger\dagger}$ This relocation only
> +appears in relocatable files for X32.}\\
> \end{tabular}
>\end{center}
> \Hrule
>
>
> I opened:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=13082
>
> and will fix it.
>
Re: [LLVMdev] Handling of pointer difference in llvm-gcc and clang
On Thu, Aug 11, 2011 at 10:36 PM, Joe Buck wrote: > On Thu, Aug 11, 2011 at 1:58 PM, Joseph S. Myers > wrote: >> -ftrapv and -fwrapv should have no effect on pointer subtraction. > > Gaby writes: > >> Yes! > > Wouldn't it suffice to convert the pointers to unsigned, do an unsigned > subtraction, and then convert the result to signed? This would then guarantee > that gcc uses two's complement semantics, independent of -ftrapv. Of course, I think that is what is being proposed. Richard.
Re: [LLVMdev] Handling of pointer difference in llvm-gcc and clang
So it seems like we agreed that this is a problem that should be fixed. Shall I create a bug report suggesting for it? Am Friday, 12. August 2011, 09:32:11 schrieb Richard Guenther: > On Thu, Aug 11, 2011 at 10:36 PM, Joe Buck wrote: > > On Thu, Aug 11, 2011 at 1:58 PM, Joseph S. Myers > > > > wrote: > >> -ftrapv and -fwrapv should have no effect on pointer subtraction. > > > > Gaby writes: > >> Yes! > > > > Wouldn't it suffice to convert the pointers to unsigned, do an unsigned > > subtraction, and then convert the result to signed? This would then > > guarantee that gcc uses two's complement semantics, independent of > > -ftrapv. > > Of course, I think that is what is being proposed. > > Richard.
Re: clobber CC for arithmetic instructions
On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj wrote: > Hello All, > > I am working on 32-bit target with gcc 4.6.0. I need some help on the > following: > > For my target, If my CCR register is set, all the arithmetic > instructions update the CC register else the don't update. > Setting the CCR register is done by a built-in function. > > Can any one help how to proceed with this? or any other target where a > similar case has been implemented? > > Thanks, > Rohit > Adding more info: Note: There is 2 cycle latency between compare and branch instructions. A) Without CCR register being set. cmp insn branch insn Here i can insert any arithmetic instruction e.g. 'addsi' in-between 'cmp' and 'branch' as the CC register doesn't get modified. B) With CCR register being set. Here i cannot insert any arithmetic instruction e.g. 'addsi' in-between 'cmp' and 'branch' as the CC register will get modified. ~Rohit
Re: Move insn out of the way
On Thu, Aug 11, 2011 at 3:27 PM, Vladimir Makarov wrote: > Yes, that is mostly correct. The first could be done by -fweb (if the live > range where the pseudo is equal to the constant is disjoint). The first > could be done also by Jeff Law's project which can provide splitting not > only on the border of loops. > I was thinking that one possible solution in the short term would be to add a new pass just before IRA which does constant assignment moves. So, an insn where a register which is assigned a constant can be moved as much as possible to the place right before the use of the register or if there's no use of the register inside the current BB, it can be moved as the last instruction of the BB. What do you think about this? Would this work? I know it's not very general, however, it's useful at least for my backend to get this right as soon as possible due to several size test failures we have which are a consequence of this problem. Paulo Matos
Re: clobber CC for arithmetic instructions
On Fri, Aug 12, 2011 at 11:48 AM, Rohit Arul Raj wrote: > On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj > wrote: >> Hello All, >> >> I am working on 32-bit target with gcc 4.6.0. I need some help on the >> following: >> >> For my target, If my CCR register is set, all the arithmetic >> instructions update the CC register else the don't update. >> Setting the CCR register is done by a built-in function. >> >> Can any one help how to proceed with this? or any other target where a >> similar case has been implemented? >> >> Thanks, >> Rohit >> > > Adding more info: > > Note: There is 2 cycle latency between compare and branch instructions. > > A) Without CCR register being set. > > cmp insn > branch insn > > Here i can insert any arithmetic instruction e.g. 'addsi' > in-between 'cmp' and 'branch' as the CC register doesn't get modified. > > B) With CCR register being set. > > Here i cannot insert any arithmetic instruction e.g. 'addsi' > in-between 'cmp' and 'branch' as the CC register will get modified. What does the ABI say about the CCR register state on function entry? 1) Implement that and disallow modifying the CCR register. 2) Add a -mccr flag and make the backend assume nothing about the contents of the CCR register (I suppose a cmp instruction will nevertheless modify CC), similar to how we have -frounding-math If you want to exploit CCR in your backend you probably want to do so late in machine reorg. Richard. > ~Rohit >
Re: [x32] Allow R_X86_64_64
On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: On 12.08.11 at 06:37, "H.J. Lu" wrote: >> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: >>> Hi, >>> >>> It turns out that x32 needs R_X86_64_64. One major reason is >>> the displacement range of x32 is -2G to +2G. It isn't a problem >>> for compiler since only small model is required for x32. >>> >>> However, to address 0 to 4G directly in assembly code, we have >>> to use R_X86_64_64 with movabs. I am checking the follow patch >>> into x32 psABI to allow R_X86_64_64. >>> >>> >> >> X32 Linker should treats R_X86_64_64 as R_X86_64_32 >> zero-extended to 64bit for output. I will update x32 psABI with > > I'm sorry to say that, but the situation about x32 seems to be > getting worse with each change you do, every time again > revolving around mixing up ABI specification and a particular > implementation thereof. > > Here, if you need something zero-extended (though I can't see > why you would), then you should use a new relocation type. As > pointed out before, there are valid possible uses of R_X86_64_64 > that would require the semantics of x86-64. > When does x32 need the semantics of x86-64 for R_X86_64_64? No, you can't mix ELF32 with ELF64. -- H.J.
Re: [x32] Allow R_X86_64_64
>>> On 12.08.11 at 14:09, "H.J. Lu" wrote: > On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: > On 12.08.11 at 06:37, "H.J. Lu" wrote: >>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: Hi, It turns out that x32 needs R_X86_64_64. One major reason is the displacement range of x32 is -2G to +2G. It isn't a problem for compiler since only small model is required for x32. However, to address 0 to 4G directly in assembly code, we have to use R_X86_64_64 with movabs. I am checking the follow patch into x32 psABI to allow R_X86_64_64. >>> >>> X32 Linker should treats R_X86_64_64 as R_X86_64_32 >>> zero-extended to 64bit for output. I will update x32 psABI with >> >> I'm sorry to say that, but the situation about x32 seems to be >> getting worse with each change you do, every time again >> revolving around mixing up ABI specification and a particular >> implementation thereof. >> >> Here, if you need something zero-extended (though I can't see >> why you would), then you should use a new relocation type. As >> pointed out before, there are valid possible uses of R_X86_64_64 >> that would require the semantics of x86-64. >> > > When does x32 need the semantics of x86-64 for R_X86_64_64? When referencing an assembler or linker defined constant that exceeds 32-bit in width. Given that this is a 64-bit architecture with 32-bit addresses, at least I would expect such to work. > No, you can't mix ELF32 with ELF64. That wasn't the question, but clearly your tying of x32 to ELF32 is another limitation that makes such assembler defined constants not work (not sure about linker script defined ones). Jan
Re: [x32] Allow R_X86_64_64
On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote: On 12.08.11 at 14:09, "H.J. Lu" wrote: >> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: >> On 12.08.11 at 06:37, "H.J. Lu" wrote: On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: > Hi, > > It turns out that x32 needs R_X86_64_64. One major reason is > the displacement range of x32 is -2G to +2G. It isn't a problem > for compiler since only small model is required for x32. > > However, to address 0 to 4G directly in assembly code, we have > to use R_X86_64_64 with movabs. I am checking the follow patch > into x32 psABI to allow R_X86_64_64. > > X32 Linker should treats R_X86_64_64 as R_X86_64_32 zero-extended to 64bit for output. I will update x32 psABI with >>> >>> I'm sorry to say that, but the situation about x32 seems to be >>> getting worse with each change you do, every time again >>> revolving around mixing up ABI specification and a particular >>> implementation thereof. >>> >>> Here, if you need something zero-extended (though I can't see >>> why you would), then you should use a new relocation type. As >>> pointed out before, there are valid possible uses of R_X86_64_64 >>> that would require the semantics of x86-64. >>> >> >> When does x32 need the semantics of x86-64 for R_X86_64_64? > > When referencing an assembler or linker defined constant that > exceeds 32-bit in width. Given that this is a 64-bit architecture > with 32-bit addresses, at least I would expect such to work. > Yes, it should work just fine for x32 by zero-extending 32bit address to 64bit. -- H.J.
Re: [x32] Allow R_X86_64_64
>>> On 12.08.11 at 15:22, "H.J. Lu" wrote: > On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote: > On 12.08.11 at 14:09, "H.J. Lu" wrote: >>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: >>> On 12.08.11 at 06:37, "H.J. Lu" wrote: > On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: >> Hi, >> >> It turns out that x32 needs R_X86_64_64. One major reason is >> the displacement range of x32 is -2G to +2G. It isn't a problem >> for compiler since only small model is required for x32. >> >> However, to address 0 to 4G directly in assembly code, we have >> to use R_X86_64_64 with movabs. I am checking the follow patch >> into x32 psABI to allow R_X86_64_64. >> >> > > X32 Linker should treats R_X86_64_64 as R_X86_64_32 > zero-extended to 64bit for output. I will update x32 psABI with I'm sorry to say that, but the situation about x32 seems to be getting worse with each change you do, every time again revolving around mixing up ABI specification and a particular implementation thereof. Here, if you need something zero-extended (though I can't see why you would), then you should use a new relocation type. As pointed out before, there are valid possible uses of R_X86_64_64 that would require the semantics of x86-64. >>> >>> When does x32 need the semantics of x86-64 for R_X86_64_64? >> >> When referencing an assembler or linker defined constant that >> exceeds 32-bit in width. Given that this is a 64-bit architecture >> with 32-bit addresses, at least I would expect such to work. >> > > Yes, it should work just fine for x32 by zero-extending 32bit > address to 64bit. For a constant that has more than 32 significant bits??? Jan
Re: [x32] Allow R_X86_64_64
On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wrote: On 12.08.11 at 15:22, "H.J. Lu" wrote: >> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote: >> On 12.08.11 at 14:09, "H.J. Lu" wrote: On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: On 12.08.11 at 06:37, "H.J. Lu" wrote: >> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: >>> Hi, >>> >>> It turns out that x32 needs R_X86_64_64. One major reason is >>> the displacement range of x32 is -2G to +2G. It isn't a problem >>> for compiler since only small model is required for x32. >>> >>> However, to address 0 to 4G directly in assembly code, we have >>> to use R_X86_64_64 with movabs. I am checking the follow patch >>> into x32 psABI to allow R_X86_64_64. >>> >>> >> >> X32 Linker should treats R_X86_64_64 as R_X86_64_32 >> zero-extended to 64bit for output. I will update x32 psABI with > > I'm sorry to say that, but the situation about x32 seems to be > getting worse with each change you do, every time again > revolving around mixing up ABI specification and a particular > implementation thereof. > > Here, if you need something zero-extended (though I can't see > why you would), then you should use a new relocation type. As > pointed out before, there are valid possible uses of R_X86_64_64 > that would require the semantics of x86-64. > When does x32 need the semantics of x86-64 for R_X86_64_64? >>> >>> When referencing an assembler or linker defined constant that >>> exceeds 32-bit in width. Given that this is a 64-bit architecture >>> with 32-bit addresses, at least I would expect such to work. >>> >> >> Yes, it should work just fine for x32 by zero-extending 32bit >> address to 64bit. > > For a constant that has more than 32 significant bits??? > Can you give me an example in assembly code? -- H.J.
Re: Move insn out of the way
On 08/12/2011 06:00 AM, Paulo J. Matos wrote: On Thu, Aug 11, 2011 at 3:27 PM, Vladimir Makarov wrote: Yes, that is mostly correct. The first could be done by -fweb (if the live range where the pseudo is equal to the constant is disjoint). The first could be done also by Jeff Law's project which can provide splitting not only on the border of loops. I was thinking that one possible solution in the short term would be to add a new pass just before IRA which does constant assignment moves. So, an insn where a register which is assigned a constant can be moved as much as possible to the place right before the use of the register or if there's no use of the register inside the current BB, it can be moved as the last instruction of the BB. What do you think about this? Would this work? I know it's not very general, however, it's useful at least for my backend to get this right as soon as possible due to several size test failures we have which are a consequence of this problem. Sorry, Paulo. I don't think it is a good idea to have such a general pass. A constant depending on its value could be prohibited to be used in insn. Moving assignment to the constant most probably worsens insn schedule on targets where the 1st insn scheduling is a default. But moving the pass before 1st insn scheduling could work if register pressure sensitive insn scheduling is used. Still it is too specialized pass. I think register pressure relief as it is described in Simpson's thesis would be a more general approach. But to be honest, I think, the best solution would be in RA because it is dealing with insn constraints and costs. I'll think about solving this problem in RA.
[GSOC] Customizable warnings with a GCC plugin
Hello,
As the GSOC ending is approching, I tried on a real project (GNU Grub)
the plugin that I am developping.
This plugin allows the user to add warnings when compiling, depending of
rules that he has previously written. Here is an exemple of possible rules :
(testNull "grub_malloc")
This means that when there is a call to function "grub_malloc", we will
check that it is immediately followed by a condition, testing that what
was returned by grub_malloc was (not) null.
(testNull "grub_malloc")
We also have operator testZero and test testNeg, allowing to work on
functions that return int.
We could also use such rule (event if it is quite unusual):
(testNull "function_that_modify_first_arg" 1)
It means that instead of testing that there is a condition on the result
of the function, we test that there is a test on the first argument of
the function.
Using this feature has more sense with the following type of test:
(testFollowedBy "grub_bufio_open" 0 "grub_bufio_close" 1)
This means that in a function body, if you have a call to the function
"grub_bufio_open", we will check that the returned variable (0) is later
tested to be first argument (1) of a call to grub_bufio_close.
There is also a testNotFollowedBy working the same way which emit a
warning if the first function is followed by the second one.
The last kind of test is "testImmediatlyFollowedBy" testing that a call
to a function is immediatly followed by a call to another one, for
exemple we might want to use :
(testImmediatlyFollowedBy "chroot" 1 "chdir" 1)
The plugin seems to return quite interesting warnings without to much
false positives. False positives comes from several particular
situations, for exemple for testFollowedBy, if you have someting like that:
int myFunction(void)
{
void * myPtr = first_function_to_be_tested();
if(something does not works)
{
return ERROR;
}
second_function(myPtr);
return 0;
}
It will return a warning as you can exit the function without running
second_function. The problem is that it is more a design problem than a
problem from the plugin.
If you want to see the detail of my result when running a few tests on
Grub, you can have a look on the grub mailing list :
https://lists.gnu.org/archive/html/grub-devel/2011-08/msg9.html .
I would be glad to have your opinion on my plugin. Do you thing in can
be really useful in real project ? Would you use it ? Have you idea of
tests that we could run over GCC or another project ? I guess this can
be a pretty good tools, but it needs to have clear coding standard in
order to know what should be tested.
For the moment, the plugin has only be tested on C code, this might
works with only few changes for C++. It needed the following patchs
http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg13086.html which
had been commited yesterday + some changes in MELT (the plugin is
developped in MELT). Moreover as the plugin uses some newly added
functionalities of MELT, it might be quite hard to use until the release
of MELT 0.9 (which might be ready for the end of August). I have named
the plugin Talpo, it means mole in esperanto, the idea is that we dig
blindly into GCC finding the information we want, the project is
available here : https://gitorious.org/talpo. I will focus on
documentation and help next week.
Thanks for your interest!
Pierre Vittet
Re: Move insn out of the way
On Fri, Aug 12, 2011 at 3:21 PM, Vladimir Makarov wrote: > > Sorry, Paulo. I don't think it is a good idea to have such a general pass. Thanks for the observation and the points you made. I understand and agree that this should be sorted at the IRA level. What I might do in the meantime is to implement such a pass on my port of GCC until it is sorted upstream. > > But to be honest, I think, the best solution would be in RA because it is > dealing with insn constraints and costs. I'll think about solving this > problem in RA. > Thanks! I will be eagerly waiting for an update. Cheers, -- PMatos
Re: [x32] Allow R_X86_64_64
On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote: On 12.08.11 at 16:47, "H.J. Lu" wrote: >> On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich wrote: >> On 12.08.11 at 16:02, "H.J. Lu" wrote: On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wrote: On 12.08.11 at 15:22, "H.J. Lu" wrote: >> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich wrote: >> On 12.08.11 at 14:09, "H.J. Lu" wrote: On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich wrote: On 12.08.11 at 06:37, "H.J. Lu" wrote: >> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote: >>> Hi, >>> >>> It turns out that x32 needs R_X86_64_64. One major reason is >>> the displacement range of x32 is -2G to +2G. It isn't a problem >>> for compiler since only small model is required for x32. >>> >>> However, to address 0 to 4G directly in assembly code, we have >>> to use R_X86_64_64 with movabs. I am checking the follow patch >>> into x32 psABI to allow R_X86_64_64. >>> >>> >> >> X32 Linker should treats R_X86_64_64 as R_X86_64_32 >> zero-extended to 64bit for output. I will update x32 psABI with > > I'm sorry to say that, but the situation about x32 seems to be > getting worse with each change you do, every time again > revolving around mixing up ABI specification and a particular > implementation thereof. > > Here, if you need something zero-extended (though I can't see > why you would), then you should use a new relocation type. As > pointed out before, there are valid possible uses of R_X86_64_64 > that would require the semantics of x86-64. > When does x32 need the semantics of x86-64 for R_X86_64_64? >>> >>> When referencing an assembler or linker defined constant that >>> exceeds 32-bit in width. Given that this is a 64-bit architecture >>> with 32-bit addresses, at least I would expect such to work. >>> >> >> Yes, it should work just fine for x32 by zero-extending 32bit >> address to 64bit. > > For a constant that has more than 32 significant bits??? > Can you give me an example in assembly code? >>> >>> Something like >>> >>> .equ sym, 0x1234567890 >>> .global sym >>> >> >> "sym" is truncated to 32bit: > > Yes, because of your tying of the ABI to ELF32. X32 uses ELF32 and won't change. >> Symbol table '.symtab' contains 5 entries: >> Num: Value Size Type Bind Vis Ndx Name >> 0: 0 NOTYPE LOCAL DEFAULT UND >> 1: 0 SECTION LOCAL DEFAULT 1 >> 2: 0 SECTION LOCAL DEFAULT 2 >> 3: 0 SECTION LOCAL DEFAULT 3 >> 4: 34567890 0 NOTYPE GLOBAL DEFAULT ABS sym >> >> However, one can write >> >> .quad main + 0x800 > > And I suppose that wouldn't work either with your R_X86_64_64 > implied zero-extension... > I will investigate. -- H.J.
Re: [GSOC] Customizable warnings with a GCC plugin
On 12 August 2011 15:54, Pierre Vittet wrote:
>
> For the moment, the plugin has only be tested on C code, this might
> works with only few changes for C++.
Would your example tests for grub warn about the following C++ code?
struct Guard {
Guard(void* p) : p(p) { if (!p) throw std::bad_alloc(); }
~Guard() { grub_free(p); }
void* p;
};
void func(grub_size_t n)
{
Guard g(grub_malloc(n));
// do something with g.p
}
For it to be useful for C++ it would be necessary to not warn about that code.
Re: Move insn out of the way
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/11 04:00, Paulo J. Matos wrote: > On Thu, Aug 11, 2011 at 3:27 PM, Vladimir Makarov > wrote: >> Yes, that is mostly correct. The first could be done by -fweb (if >> the live range where the pseudo is equal to the constant is >> disjoint). The first could be done also by Jeff Law's project >> which can provide splitting not only on the border of loops. >> > > I was thinking that one possible solution in the short term would be > to add a new pass just before IRA which does constant assignment > moves. So, an insn where a register which is assigned a constant can > be moved as much as possible to the place right before the use of > the register or if there's no use of the register inside the current > BB, it can be moved as the last instruction of the BB. I thought we already had code to do this in response to a pseudo not getting a hard reg and the pseudo has an appropriate REG_EQUIV note on its assignment insn. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJORVC7AAoJEBRtltQi2kC7zKAH/iesdm/aO4C9OQMfwGgZ6Xht PvStoxWtOUo5JuafwYlRppi67rld+PBnBz65te6TauSwSA6WwJ4tzfSAQ3IyLYZB /k8lgfCRt46XGwAHr3Zva5nOC/zfYyyoMRz8Z6XpfoGsnwt4Zq3Kej9iOXFQZleo PWMHKiQDi6MxBPjGChTME0ct/yvClG/qb5WjbqPeLCLXnn0/VYmvicajvNi/Dscf fYtS8wpw8Kh5ylQ0mKmTsRWRQvXZZToDazqngFsOSxVe+Yoxssk40A9UIJrB1xAP Z7kuJ/i8hHYQkeeHaFd84wKrgHl4Ciue/58K2Nm6H7T93hJstt6eT/rLNCsuV2g= =mG8D -END PGP SIGNATURE-
Re: [x32] Allow R_X86_64_64
On Fri, Aug 12, 2011 at 8:52 AM, H.J. Lu wrote:
> On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote:
> On 12.08.11 at 16:47, "H.J. Lu" wrote:
>>> On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich wrote:
>>> On 12.08.11 at 16:02, "H.J. Lu" wrote:
> On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wrote:
> On 12.08.11 at 15:22, "H.J. Lu" wrote:
>>> On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich
>>> wrote:
>>> On 12.08.11 at 14:09, "H.J. Lu" wrote:
> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich
> wrote:
> On 12.08.11 at 06:37, "H.J. Lu" wrote:
>>> On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu wrote:
Hi,
It turns out that x32 needs R_X86_64_64. One major reason is
the displacement range of x32 is -2G to +2G. It isn't a problem
for compiler since only small model is required for x32.
However, to address 0 to 4G directly in assembly code, we have
to use R_X86_64_64 with movabs. I am checking the follow patch
into x32 psABI to allow R_X86_64_64.
>>>
>>> X32 Linker should treats R_X86_64_64 as R_X86_64_32
>>> zero-extended to 64bit for output. I will update x32 psABI with
>>
>> I'm sorry to say that, but the situation about x32 seems to be
>> getting worse with each change you do, every time again
>> revolving around mixing up ABI specification and a particular
>> implementation thereof.
>>
>> Here, if you need something zero-extended (though I can't see
>> why you would), then you should use a new relocation type. As
>> pointed out before, there are valid possible uses of R_X86_64_64
>> that would require the semantics of x86-64.
>>
>
> When does x32 need the semantics of x86-64 for R_X86_64_64?
When referencing an assembler or linker defined constant that
exceeds 32-bit in width. Given that this is a 64-bit architecture
with 32-bit addresses, at least I would expect such to work.
>>>
>>> Yes, it should work just fine for x32 by zero-extending 32bit
>>> address to 64bit.
>>
>> For a constant that has more than 32 significant bits???
>>
>
> Can you give me an example in assembly code?
Something like
.equ sym, 0x1234567890
.global sym
>>>
>>> "sym" is truncated to 32bit:
>>
>> Yes, because of your tying of the ABI to ELF32.
>
> X32 uses ELF32 and won't change.
>
>>> Symbol table '.symtab' contains 5 entries:
>>> Num: Value Size Type Bind Vis Ndx Name
>>> 0: 0 NOTYPE LOCAL DEFAULT UND
>>> 1: 0 SECTION LOCAL DEFAULT 1
>>> 2: 0 SECTION LOCAL DEFAULT 2
>>> 3: 0 SECTION LOCAL DEFAULT 3
>>> 4: 34567890 0 NOTYPE GLOBAL DEFAULT ABS sym
>>>
>>> However, one can write
>>>
>>> .quad main + 0x800
>>
>> And I suppose that wouldn't work either with your R_X86_64_64
>> implied zero-extension...
>>
>
I will add R_X86_64_64 support to x32 dynamic linker. I will
also add R_X86_64_RELATIVE64 to x32 dynamic linker.
For R_X86_64_64 relocation, if addend is 0, linker will
turn it to R_X86_64_32 and zero-extends it to 64bit. Otherwise,
linker will generate R_X86_64_RELATIVE64 if it is a relocation
against a local symbol or keep R_X86_64_64 for relocations
against external symbols. We need R_X86_64_RELATIVE64
since R_X86_64_RELATIVE only updates 32bit destination.
--
H.J.
---
diff --git a/object-files.tex b/object-files.tex
index 7f0fd14..d2be264 100644
--- a/object-files.tex
+++ b/object-files.tex
@@ -483,10 +483,13 @@ or \texttt{Elf32_Rel} relocation.
\texttt{R_X86_64_TLSDESC_CALL} & 35 & none & \\
\texttt{R_X86_64_TLSDESC} & 36 & \textit{word64}$\times 2$ & \\
\texttt{R_X86_64_IRELATIVE} & 37 & \textit{wordclass} &
\texttt{indirect (B + A)}\\
+ \texttt{R_X86_64_RELATIVE64} $^{\dagger\dagger}$ & 38 &
\textit{word64} & \texttt{B + A} \\
% \texttt{R_X86_64_GOT64} & 16 & \textit{word64} & \texttt{G + A} \\
% \texttt{R_X86_64_PLT64} & 17 & \textit{word64} & \texttt{L + A - P} \\
\cline{1-4}
\multicolumn{3}{l}{\small $^\dagger$ This relocation is used only
for LP64.}\\
+\multicolumn{3}{l}{\small $^{\dagger\dagger}$ This relocation only
+appears in X32 executable files or shared objects.}\\
\end{tabular}
\end{center}
\Hrule
Re: [PATCH 2/2] document ISL requirement for GCC installation
On Fri, Aug 12, 2011 at 12:50, Jack Howarth wrote:
> On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
>> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
>> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
>> > > +@item Integer Set Library (ISL) version 0.08
>> > > +
>> > > +Necessary to build GCC with the Graphite loop optimizations.
>> > > +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.
>> >
>> > So have things changed relative to what was said in
>> > about ISL being
>> > included in CLooG-ISL?
>>
>> isl is still included in CLooG, but Sebastian now wants to use isl
>> itself in graphite.
>>
>> skimo
>
> Will graphite be totally converted to isl such that ppl can be deprecated
> in time for the gcc 4.7 release?
> Jack
Yes, having GCC only depend on ISL and CLooG-ISL (and not depend
anymore on PPL) is our plan for 4.7.
The rationale behind this is that with PPL it would be very difficult to fix
bugs due to wrap around unsigned types, like this one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47594
With ISL it is possible to represent the wrapping types and fix this bug.
Sebastian
Re: [x32] Allow R_X86_64_64
On Fri, Aug 12, 2011 at 10:53 AM, H.J. Lu wrote:
> On Fri, Aug 12, 2011 at 8:52 AM, H.J. Lu wrote:
>> On Fri, Aug 12, 2011 at 8:17 AM, Jan Beulich wrote:
>> On 12.08.11 at 16:47, "H.J. Lu" wrote:
On Fri, Aug 12, 2011 at 7:42 AM, Jan Beulich wrote:
On 12.08.11 at 16:02, "H.J. Lu" wrote:
>> On Fri, Aug 12, 2011 at 6:59 AM, Jan Beulich wrote:
>> On 12.08.11 at 15:22, "H.J. Lu" wrote:
On Fri, Aug 12, 2011 at 6:17 AM, Jan Beulich
wrote:
On 12.08.11 at 14:09, "H.J. Lu" wrote:
>> On Fri, Aug 12, 2011 at 12:30 AM, Jan Beulich
>> wrote:
>> On 12.08.11 at 06:37, "H.J. Lu" wrote:
On Mon, Aug 1, 2011 at 3:15 PM, H.J. Lu
wrote:
> Hi,
>
> It turns out that x32 needs R_X86_64_64. One major reason is
> the displacement range of x32 is -2G to +2G. It isn't a problem
> for compiler since only small model is required for x32.
>
> However, to address 0 to 4G directly in assembly code, we have
> to use R_X86_64_64 with movabs. I am checking the follow patch
> into x32 psABI to allow R_X86_64_64.
>
>
X32 Linker should treats R_X86_64_64 as R_X86_64_32
zero-extended to 64bit for output. I will update x32 psABI with
>>>
>>> I'm sorry to say that, but the situation about x32 seems to be
>>> getting worse with each change you do, every time again
>>> revolving around mixing up ABI specification and a particular
>>> implementation thereof.
>>>
>>> Here, if you need something zero-extended (though I can't see
>>> why you would), then you should use a new relocation type. As
>>> pointed out before, there are valid possible uses of R_X86_64_64
>>> that would require the semantics of x86-64.
>>>
>>
>> When does x32 need the semantics of x86-64 for R_X86_64_64?
>
> When referencing an assembler or linker defined constant that
> exceeds 32-bit in width. Given that this is a 64-bit architecture
> with 32-bit addresses, at least I would expect such to work.
>
Yes, it should work just fine for x32 by zero-extending 32bit
address to 64bit.
>>>
>>> For a constant that has more than 32 significant bits???
>>>
>>
>> Can you give me an example in assembly code?
>
> Something like
>
> .equ sym, 0x1234567890
> .global sym
>
"sym" is truncated to 32bit:
>>>
>>> Yes, because of your tying of the ABI to ELF32.
>>
>> X32 uses ELF32 and won't change.
>>
Symbol table '.symtab' contains 5 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0 NOTYPE LOCAL DEFAULT UND
1: 0 SECTION LOCAL DEFAULT 1
2: 0 SECTION LOCAL DEFAULT 2
3: 0 SECTION LOCAL DEFAULT 3
4: 34567890 0 NOTYPE GLOBAL DEFAULT ABS sym
However, one can write
.quad main + 0x800
>>>
>>> And I suppose that wouldn't work either with your R_X86_64_64
>>> implied zero-extension...
>>>
>>
>
> I will add R_X86_64_64 support to x32 dynamic linker. I will
> also add R_X86_64_RELATIVE64 to x32 dynamic linker.
>
> For R_X86_64_64 relocation, if addend is 0, linker will
> turn it to R_X86_64_32 and zero-extends it to 64bit. Otherwise,
> linker will generate R_X86_64_RELATIVE64 if it is a relocation
> against a local symbol or keep R_X86_64_64 for relocations
> against external symbols. We need R_X86_64_RELATIVE64
> since R_X86_64_RELATIVE only updates 32bit destination.
>
>
> --
> H.J.
> ---
> diff --git a/object-files.tex b/object-files.tex
> index 7f0fd14..d2be264 100644
> --- a/object-files.tex
> +++ b/object-files.tex
> @@ -483,10 +483,13 @@ or \texttt{Elf32_Rel} relocation.
> \texttt{R_X86_64_TLSDESC_CALL} & 35 & none & \\
> \texttt{R_X86_64_TLSDESC} & 36 & \textit{word64}$\times 2$ & \\
> \texttt{R_X86_64_IRELATIVE} & 37 & \textit{wordclass} &
> \texttt{indirect (B + A)}\\
> + \texttt{R_X86_64_RELATIVE64} $^{\dagger\dagger}$ & 38 &
> \textit{word64} & \texttt{B + A} \\
> % \texttt{R_X86_64_GOT64} & 16 & \textit{word64} & \texttt{G + A} \\
> % \texttt{R_X86_64_PLT64} & 17 & \textit{word64} & \texttt{L + A - P} \\
> \cline{1-4}
> \multicolumn{3}{l}{\small $^\dagger$ This relocation is used only
> for LP64.}\\
> + \multicolumn{3}{l}{\small $^{\dagger\dagger}$ This relocation only
> + appears in X32 executable files or shared objects.}\\
> \end{tabular}
> \end{center}
> \Hrule
>
I checked the enclosed linker change. I also enclosed the glibc change
to handle R_X86_64_RELATIVE64 and R_X86_64_64 for x32.
--
H.J.
bfd/
2011-08-12 H.J. Lu
Re: An unusual x86_64 code model
On Tue, Aug 09, 2011 at 04:58:01PM -0700, Andrew Pinski wrote:
> On Tue, Aug 9, 2011 at 4:26 PM, Jed Davis wrote:
> > The existing workaround, which predates my personal involvement, is to
> > use -fPIE together with a -include'd file that uses a #pragma to set the
> > default symbol visibility to hidden, which suppresses the PLTness.
> > That works on GCC 4.1, but with newer versions that no longer affects
> > implicitly declared functions (which turn up occasionally in third-party
> > drivers), or coverage instrumentation's calls to __gcov_init, or probably
> > other things that have not yet been discovered. Also, it was never an
> > ideal solution, except in that it didn't require modifying the compiler
> > (at the time).
>
> Have you tried -fvisibility=hidden option ?
Sadly, that doesn't work:
$ cat test.c
int baz();
int quux() { return baz(); }
int foo() { return bar() + quux(); }
$ gcc -fprofile-arcs -fvisibility=hidden -fPIE -S test.c
$ grep call test.s
callbaz@PLT
callbar@PLT
callquux
call__gcov_init@PLT
The fine manual states that "extern declarations are not affected by
-fvisibility", so that result is expected.
Adding "#pragma GCC visibility push(hidden)" also takes care of baz
(declared and extern), but not bar (implicit) or __gcov_init (very
implicit).
--Jed
gcc-4.6-20110812 is now available
Snapshot gcc-4.6-20110812 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110812/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 177722 You'll find: gcc-4.6-20110812.tar.bz2 Complete GCC MD5=06128c3332eb6db3ca29790c6ff28467 SHA1=f8c48070003f8b0f3984e3e027e219341c8a9207 Diffs from 4.6-20110805 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: clobber CC for arithmetic instructions
On Fri, 12 Aug 2011, Rohit Arul Raj wrote: > On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj > wrote: > > Hello All, > > > > I am working on 32-bit target with gcc 4.6.0. I need some help on the > > following: > > > > For my target, If my CCR register is set, all the arithmetic > > instructions update the CC register else the don't update. So you have a control register called CCR and a status register called CC? > > Setting the CCR register is done by a built-in function. Why is this user-controllable? My first thought is that this is misguided. Is this just a sketch or do you already have code using it? > > Can any one help how to proceed with this? or any other target where a > > similar case has been implemented? > > > > Thanks, > > Rohit > > > > Adding more info: > > Note: There is 2 cycle latency between compare and branch instructions. > > A) Without CCR register being set. > > cmp insn > branch insn > > Here i can insert any arithmetic instruction e.g. 'addsi' > in-between 'cmp' and 'branch' as the CC register doesn't get modified. Assuming that you can indeed emit reasonable code for compares and conditional branches without the "CCR register" set to the do-not-update state, I'd suggest you implement that. Forget about the builtin; don't implement it. Some time later, when you're sufficiently acquinted with gcc internals, maybe improve the generated code using the always-update state if you can indeed spot generated code that could be improved that way. Don't do this for at least a few months. If there is no such code, forget about the CCR=always-update state. In either case, never mention (cc0) in your .md file. brgds, H-P
Re: An unusual x86_64 code model
On Tue, Aug 09, 2011 at 04:26:06PM -0700, Jed Davis wrote: > Thus, I'm trying to find the right solution. My current attempt is to > add an -mno-plt flag in i386.opt, and add it to the list of reasons not > to print "@PLT" after symbol names. This seems to work, although I've > only done minimal testing so far. Emphasis on "minimal"; a reference to the address of an extern variable yields a @GOTPCREL. So that wasn't going to work in any case. The more of i386.c I read, the more I realize that the resemblance to CM_SMALL_PIC was mostly coincidental. --Jed
Re: clobber CC for arithmetic instructions
On Fri, 12 Aug 2011, Hans-Peter Nilsson wrote: > On Fri, 12 Aug 2011, Rohit Arul Raj wrote: > Assuming that you can indeed emit reasonable code for compares > and conditional branches without the "CCR register" set to the > do-not-update state, I'd suggest you implement that Sorry for the miswrite: I meant 'without the "CCR register" set to the always-update state' (with the "CCR register" constantly set to the do-not-update state). brgds, H-P
