Re: %pc relative addressing of string literals/const data
Alan Modra wrote on 2010/10/06 00:19:26: > > On Tue, Oct 05, 2010 at 11:40:11PM +0200, Joakim Tjernlund wrote: > > yes, but this could be a new PIC mode that uses a new better > > PIC mode for everything. Especially one that doesn't require each function > > to calculate the GOT address in the function prologue(why is that so?) > > The new ppc64 -mcmodel=medium support does give you pic access to > locals. > > -fPIC -O2 without hidden > .LC0: >.tc x[TC],x <-- compiler managed GOT entries > .LC1: >.tc y[TC],y > [snip] > .L.foo: >addis 11,2,@toc@ha >addis 9,2,@toc@ha >ld 11,@toc@l(11) >ld 9,@toc@l(9) >lwz 3,0(11) >lwz 0,0(9) >add 3,3,0 >extsw 3,3 >blr > > -fPIC -O2 with hidden pragma > .L.foo: >addis 11,2,x...@toc@ha >addis 9,2,y...@toc@ha >lwz 3,x...@toc@l(11) <-- TOC/GOT pointer relative >lwz 0,y...@toc@l(9) >add 3,3,0 >extsw 3,3 >blr > > x...@toc is equivalent to @GOTOFF on other processors. Don't have nor know much about ppc64 as I use ppc32 :( Would it be possible to have this for ppc32 too? Perhaps small patch is needed(I am on gcc 4.4.4)? Just to make sure, this works for an executable even when link address != run address and the GOT hasn't been adjusted to the running address? This would be very good news for u-boot as there is a need for link once, burn to flash anywhere and just run. Oh, one thing more, would it be possible to have -mrelocatable work -fpic too? We need the fixups, but as -fpic produces smaller code it would be nice if the -fpic -mrelocatable combo works. Jocke
Re: %pc relative addressing of string literals/const data
On Tue, Oct 05, 2010 at 10:55:36PM +0200, Joakim Tjernlund wrote:
> Richard Henderson wrote on 2010/10/05 20:56:55:
> >
> > On 10/05/2010 06:54 AM, Joakim Tjernlund wrote:
> > > Ian Lance Taylor wrote on 2010/10/05 15:47:38:
> > >> Joakim Tjernlund writes:
> > >>> While doing relocation work on u-boot I often whish for strings/const
> > >>> data
> > >>> to be accessible through %pc relative address rather than and ABS
> > >>> address
> > >>> or through GOT. Has this feature ever been considered by gcc?
> > >>
> > >> The feature can only be supported on processors which are reasonably
> > >> able to support it. So, what target are you asking about?
> > >
> > > In my case PowerPC but I think most arch's would want this feature.
> > > Is there arch's where this cannot be support at all or just within
> > > some limits? I think within limits could work for small apps
> > > like u-boot.
> >
> > PowerPC doesn't really have the relocations for pc-relative offsets
> > within code -- primarily because it doesn't have pc-relative insns
> > to match. Nor, unfortunately, does it have got-relative relocations,
> > like some other targets. These are normally how we get around not
> > having pc-relative relocations and avoiding tables in memory. C.f.
> >
> > #pragma GCC visibility push(hidden)
> > extern int x, y;
> > int foo(void) { return x + y; }
> >
> > Without pragma (-O2 -fpic):
> > i386:
> > movly...@got(%ecx), %eax
> > movlx...@got(%ecx), %edx
> > movl(%eax), %eax
> > addl(%edx), %eax
> >
> > alpha:
> > ldq $1,y($29) !literal
> > ldl $0,0($1)
> > ldq $1,x($29) !literal
> > ldl $1,0($1)
> > addl $0,$1,$0
> >
> > In both cases here, we have load the address from memory, from
> > the GOT table, then load the data (X or Y) from memory and
> > perform the addition.
> >
> >
> > With pragma:
> > i386:
> > movly...@gotoff(%ecx), %eax
> > addlx...@gotoff(%ecx), %eax
> >
> > alpha (-fpic):
> > ldl $1,x($29) !gprel
> > ldl $0,y($29) !gprel
> > addl $0,$1,$0
> >
> > alpha (-fPIC):
> > ldah $1,y($29) !gprelhigh
> > ldl $0,y($1)!gprellow
> > ldah $1,x($29) !gprelhigh
> > ldl $1,x($1)!gprellow
> > addl $0,$1,$0
> >
> > In all cases here, we've replaced the load from the GOT table
> > with arithmetic. In the case of i386 this gets folded into the
> > memory reference. The alpha cases are essentially the same as
> > what ppc could generate if it had the appropriate relocations.
>
> I don't do x86 or alpha so let me ask: If you run the code on an address
> != link address, will it do the right thing?
>
> I tested the #pragma/no #pragma on PPC and the resulting code
> was the same:
> /* with #pragma, -fpic -O2 -mregnames
> foo:
> stwu %r1,-16(%r1)
> mflr %r12
> bcl 20,31,.LCF0
> .LCF0:
> stw %r30,8(%r1)
> mflr %r30
> addis %r30,%r30,_global_offset_table_-.l...@ha
> addi %r30,%r30,_global_offset_table_-.l...@l
> mtlr %r12
> lwz %r9,y...@got(%r30)
> lwz %r3,0(%r9)
> lwz %r9,x...@got(%r30)
> lwz %r30,8(%r1)
> addi %r1,%r1,16
> lwz %r0,0(%r9)
> add %r3,%r3,%r0
> blr
> */
>
>
> You can get at the GOT table using PC relative addressing so why not
> strings or data in a similar fashion?
Because you access the got with a single (16 bit offset) instructions.
If you add .rodata, .data and .bss, you will likely overflow it
quite rapidly.
Did you look at -mrelocatable?
I don't know whether it can solve all your problems (probably not),
and there are regular threats of removing it, or at least there
were, since I see that the documentation was much improved in August.
Anyway, I used it a decade ago to write a bootloader that:
a) was loaded at an unpredictable and unconfigurable address
depending on the mood of the firmware (really, it depended at
least on the media from which you booted, even exactly the
same binary image)
b) the first thing the bootloader did was to run the relocation code
for the adress at which it had been loaded by the firmware and
find the free memory areas from tables provided by the firmware.
The code in this part could not use any global pointer variable,
AFAIR, but it was short.
c) the bootloader than moved itself where it could, re ran
the relocation code, and then could finally interact a bit with
the user to change kernel options, uncompress the kernel
and give it control.
I have not touched the code in 8 or 9 years, but it is still
the bootloader used here by ~20 MVME machines.
Regards,
Gabriel
Re: %pc relative addressing of string literals/const data
Gabriel Paubert wrote on 2010/10/06 10:15:26: > > On Tue, Oct 05, 2010 at 10:55:36PM +0200, Joakim Tjernlund wrote: > > Richard Henderson wrote on 2010/10/05 20:56:55: > > > > > > On 10/05/2010 06:54 AM, Joakim Tjernlund wrote: > > > > Ian Lance Taylor wrote on 2010/10/05 15:47:38: > > > >> Joakim Tjernlund writes: > > You can get at the GOT table using PC relative addressing so why not > > strings or data in a similar fashion? > > Because you access the got with a single (16 bit offset) instructions. > If you add .rodata, .data and .bss, you will likely overflow it > quite rapidly. > > Did you look at -mrelocatable? Yes, u-boot currently uses -mrelocatable. > > I don't know whether it can solve all your problems (probably not), > and there are regular threats of removing it, or at least there > were, since I see that the documentation was much improved in August. I really wish mrelocatable is added to all archs. The normal ELF relocs are too big to fit well in u-boot. > > Anyway, I used it a decade ago to write a bootloader that: > > a) was loaded at an unpredictable and unconfigurable address > depending on the mood of the firmware (really, it depended at > least on the media from which you booted, even exactly the > same binary image) That is pretty much what I am trying to do. > > b) the first thing the bootloader did was to run the relocation code > for the adress at which it had been loaded by the firmware and > find the free memory areas from tables provided by the firmware. > The code in this part could not use any global pointer variable, > AFAIR, but it was short. Right, but here u-boot is still in flash and cannot write/relocate the GOT. Later, when RAM is setup, it moves to RAM and relocates the GOT. I have managed to do this but this required each access to global data(including string literals) to be wrapped by a LINK_OFF(ptr) function that calculated the offset between link and run address and adjusted the ptr accordinly. This is unmaintainable though so the patch wasn't accepted by u-boot. Jocke
Re: %pc relative addressing of string literals/const data
Joakim Tjernlund writes: > I really wish mrelocatable is added to all archs. The normal ELF relocs > are too big to fit well in u-boot. Every architecture is different and requires a thoughtful approach to determine the best way to handle these issues for that architecture. Also, since every architecture is different, somebody has to do the work for each architecture separately, and it has to be done by somebody familiar with the architecture and with a way to test the results. There may be some common code that could be shared, but not much. For this kind of thing GCC is driven largely by volunteers. It is not the case that there are GCC developers sitting around trying to come up with an idea for what to work on. There are far more good ideas than there are people willing and able to work on them. So if this interests you, I encourage you to work on it yourself. The gcc developers will be happy to support you in this. Ian
constant string changed
Dear all,
When porting GCC on xc16x, I met a problem with a constant string. The
following is the C code:
#include "stdio.h"
int main () {
printf ("c\n");
}
And the following is the generated assembly:
.xc16x
.section .rodata
.LC0:
.ascii "c\0"
.section .text
.align 1
.global _main
_main:
mov [-r0],r1
mov r1,r0
mov r8,#SOF:.LC0
calla cc_UC,_puts
mov r1,[r0+]
ret
where there is no '\n' in the constant string .LC0 any more. However,
when I change the string into "%c\n" (with a character passed), the
constant string .LC0 becomes .ascii "c\12\0"
Is there any idea about this kind of problem? Where did I got the mistake?
Best regards,
Phung
Re: constant string changed
On Wed, Oct 06, 2010 at 09:59:29PM +0700, Phung Nguyen wrote:
> When porting GCC on xc16x, I met a problem with a constant string. The
> following is the C code:
> #include "stdio.h"
>
> int main () {
>
> printf ("c\n");
> }
> And the following is the generated assembly:
> .xc16x
>
> .section .rodata
>
> .LC0:
> .ascii "c\0"
> .section .text
> .align 1
> .global _main
> _main:
>mov [-r0],r1
>mov r1,r0
>
> mov r8,#SOF:.LC0
> calla cc_UC,_puts
>mov r1,[r0+]
> ret
>
> where there is no '\n' in the constant string .LC0 any more. However,
> when I change the string into "%c\n" (with a character passed), the
> constant string .LC0 becomes .ascii "c\12\0"
>
> Is there any idea about this kind of problem? Where did I got the mistake?
Why do you think there is any problem? printf ("c\n") is quivalent
to cheaper puts ("c"), so when optimizing gcc uses the latter instead of
former.
Jakub
Re: %pc relative addressing of string literals/const data
On Oct 6, 2010, at 6:52 AM, Ian Lance Taylor wrote: > Joakim Tjernlund writes: > >> I really wish mrelocatable is added to all archs. The normal ELF relocs >> are too big to fit well in u-boot. > > Every architecture is different and requires a thoughtful approach to > determine the best way to handle these issues for that architecture. > > Also, since every architecture is different, somebody has to do the work > for each architecture separately, and it has to be done by somebody > familiar with the architecture and with a way to test the results. > There may be some common code that could be shared, but not much. Not that it really matter in this discussion, but the VAX backend produces references that are pc-relative by default (producing PIC code is the default). (-O2 -fpic) foo: .word 0x0 subl2 $4,%sp addl3 x,y,%r0 Note that ld does the heavy lifting to convert the x and y relocations to indirect GOT references if needed so no explicit references to the GOT are needed.
Re: constant string changed
How can I turn this optimization off?
Phung
On Wed, Oct 6, 2010 at 10:04 PM, Jakub Jelinek wrote:
> On Wed, Oct 06, 2010 at 09:59:29PM +0700, Phung Nguyen wrote:
>> When porting GCC on xc16x, I met a problem with a constant string. The
>> following is the C code:
>> #include "stdio.h"
>>
>> int main () {
>>
>> printf ("c\n");
>> }
>> And the following is the generated assembly:
>> .xc16x
>>
>> .section .rodata
>>
>> .LC0:
>> .ascii "c\0"
>> .section .text
>> .align 1
>> .global _main
>> _main:
>> mov [-r0],r1
>> mov r1,r0
>>
>> mov r8,#SOF:.LC0
>> calla cc_UC,_puts
>> mov r1,[r0+]
>> ret
>>
>> where there is no '\n' in the constant string .LC0 any more. However,
>> when I change the string into "%c\n" (with a character passed), the
>> constant string .LC0 becomes .ascii "c\12\0"
>>
>> Is there any idea about this kind of problem? Where did I got the mistake?
>
> Why do you think there is any problem? printf ("c\n") is quivalent
> to cheaper puts ("c"), so when optimizing gcc uses the latter instead of
> former.
>
> Jakub
>
Re: constant string changed
On Wed, Oct 6, 2010 at 11:34 PM, Phung Nguyen wrote:
> How can I turn this optimization off?
Use -fno-builtin-printf.
Richard.
> Phung
>
> On Wed, Oct 6, 2010 at 10:04 PM, Jakub Jelinek wrote:
>> On Wed, Oct 06, 2010 at 09:59:29PM +0700, Phung Nguyen wrote:
>>> When porting GCC on xc16x, I met a problem with a constant string. The
>>> following is the C code:
>>> #include "stdio.h"
>>>
>>> int main () {
>>>
>>> printf ("c\n");
>>> }
>>> And the following is the generated assembly:
>>> .xc16x
>>>
>>> .section .rodata
>>>
>>> .LC0:
>>> .ascii "c\0"
>>> .section .text
>>> .align 1
>>> .global _main
>>> _main:
>>> mov [-r0],r1
>>> mov r1,r0
>>>
>>> mov r8,#SOF:.LC0
>>> calla cc_UC,_puts
>>> mov r1,[r0+]
>>> ret
>>>
>>> where there is no '\n' in the constant string .LC0 any more. However,
>>> when I change the string into "%c\n" (with a character passed), the
>>> constant string .LC0 becomes .ascii "c\12\0"
>>>
>>> Is there any idea about this kind of problem? Where did I got the mistake?
>>
>> Why do you think there is any problem? printf ("c\n") is quivalent
>> to cheaper puts ("c"), so when optimizing gcc uses the latter instead of
>> former.
>>
>> Jakub
>>
>
Re: constant string changed
On 10/6/2010 5:43 PM, Richard Guenther wrote: On Wed, Oct 6, 2010 at 11:34 PM, Phung Nguyen wrote: How can I turn this optimization off? Use -fno-builtin-printf. I'm curious, it's obviously a correct optimization, so why would you want to turn if off?
Re: constant string changed
On Oct 6, 2010, at 3:02 PM, Robert Dewar wrote: > On 10/6/2010 5:43 PM, Richard Guenther wrote: >> On Wed, Oct 6, 2010 at 11:34 PM, Phung Nguyen wrote: >>> How can I turn this optimization off? >> >> Use -fno-builtin-printf. > > I'm curious, it's obviously a correct optimization, so why > would you want to turn if off? You can also use -ffreestanding to disable it (and other similar ones). If you are working in an environment which only has printf, the conversion to puts is not helpful.
Re: constant string changed
On 10/6/2010 6:54 PM, Matt Thomas wrote: On Oct 6, 2010, at 3:02 PM, Robert Dewar wrote: On 10/6/2010 5:43 PM, Richard Guenther wrote: On Wed, Oct 6, 2010 at 11:34 PM, Phung Nguyen wrote: How can I turn this optimization off? Use -fno-builtin-printf. I'm curious, it's obviously a correct optimization, so why would you want to turn if off? You can also use -ffreestanding to disable it (and other similar ones). If you are working in an environment which only has printf, the conversion to puts is not helpful. I would have thought that configure would automatically know there was no puts, and not do the optimization if no puts is available???
Re: Regarding the GCC Binaries and Build status pages
On Wed, 11 Aug 2010, Richard Guenther wrote: > On Wed, Aug 11, 2010 at 9:32 AM, Dennis Clarke wrote: >> This is just a friendly letter. There probably will not be another GCC >> update from the Sunfreeware site ( which is still showing 3.4.6 ) for a >> long time now that Oracle has pulled finances. The same sad state of >> affairs affects the OpenSolaris project as a whole. >> >> I do expect that the Blastwave site will release formal 4.5.1 packages to >> the world sometime in the next week and there should be at least some >> mention on this page given that we have released packages for GCC ver 4.x >> ( 4.0.1 and 4.3.4 etc ) for four years now : >> >> http://gcc.gnu.org/install/binaries.html > If you provide a patch for the binaries page I am sure that Gerald will > have a look. Absolutely! Dennis, we have updated this page now, would you mind having a look whether this better meets what you would suggest? If not, a patch (note this is gcc/doc/install.texi) would be great, or you can let us know and we'll cough something up. Gerald
Bootstrap broken on Cygwin, fix on the way.
FYI, in case anyone else runs into this and comes here looking for information: a fix is on the way for the "multiple definitions of various include-path-related things" problem currently breaking bootstrap on Cygwin. Hope to have it working again within the next few hours. cheers, DaveK
