Fixup entries
What is the fixup section used for ?
of the 274 cards that build on my MAKEALL not one has any entries into this section.
Quoted 4 lines · Kenneth Johansson
What is the fixup section used for ?
of the 274 cards that build on my MAKEALL not one has any entries into this section.
These are needed for relocation of function pointers(and possible some think more). There was an attempt by Grant Likely to enable this functionalty, but some toolchains had problems with so the function was disabled. If you undo commit 1c3dd43338a077165e7e0309cb3994e65d2bdbf8 you will enable it again for powerpc.
Jocke
Quoted 6 lines · Joakim Tjernlund
Quoted 4 lines · Kenneth Johansson
What is the fixup section used for ?
of the 274 cards that build on my MAKEALL not one has any entries into this section.
Quoted 8 lines
These are needed for relocation of function pointers(and possible some think more). There was an attempt by Grant Likely to enable this functionalty, but some toolchains had problems with so the function was disabled. If you undo commit
1c3dd43338a077165e7e0309cb3994e65d2bdbf8you will enable it again for powerpc.Jocke
aaahhaa so that is how it's working.
I remember having problem understanding this when I did the command section and ended up doing a manual relocation of the command table. But compiling with -mrelocatable and going over the .fixup section instead I can now remove that extra code and it works fine.
It's not easy to understand the ABI.
I removed the -fPIC and only used -mrelocatable and that works too.
Wonder if there is something else in u-boot that use function pointers and work by accident due to the fact that the old address in flash is still valid.
---
`-mrelocatable'
`-mno-relocatable'
On embedded PowerPC systems generate code that allows (does not allow) the program to be relocated to a different address at runtime. If you use -mrelocatable' on any module, all objects linked together must be compiled with -mrelocatable' or `-mrelocatable-lib'.
Quoted 33 lines
-----Original Message-----
From: Kenneth Johansson [mailto:kenneth at southpole.se]
Sent: den 9 april 2008 16:47
To: joakim.tjernlund at transmode.se
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] Fixup entriesQuoted 6 lines · Joakim Tjernlund
Quoted 4 lines · Kenneth Johansson
What is the fixup section used for ?
of the 274 cards that build on my MAKEALL not one has any entries into this section.
Quoted 8 lines
These are needed for relocation of function pointers(and possible some think more). There was an attempt by Grant Likely to enable this functionalty, but some toolchains had problems with so the function was disabled. If you undo commit
1c3dd43338a077165e7e0309cb3994e65d2bdbf8you will enable it again for powerpc.Jocke
aaahhaa so that is how it's working.
I remember having problem understanding this when I did the command section and ended up doing a manual relocation of the command table. But compiling with -mrelocatable and going over the .fixup section instead I can now remove that extra code and it works fine.
Quoted 7 lines
It's not easy to understand the ABI.
I removed the -fPIC and only used -mrelocatable and that works too.
Wonder if there is something else in u-boot that use function pointers and work by accident due to the fact that the old address in flash is still valid.
Oh yes, there are a few such pointers. And the conversion to using fixups instead is a bit lazy. Several manual relocations has only been nullified by setting gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel free to send patches :)
Jocke
Quoted 7 lines · Joakim Tjernlund
Quoted 6 lines
-----Original Message-----
From: Kenneth Johansson [mailto:kenneth at southpole.se] Wonder if there is something else in u-boot that use function pointers and work by accident due to the fact that the old address in flash is still valid.
Quoted 7 lines
Oh yes, there are a few such pointers. And the conversion to using fixups instead is a bit lazy. Several manual relocations has only been nullified by setting gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel free to send patches :)
Jocke
If by lazy you mean less error prone and obviously simpler :). clearly using -mrelocatable is the smarter thing to do.
I had this misconception that the GOT was all that was needed for relocation.
Could not find any useful information on what rules apply to gcc and binutils for handling stuff in this fixup section.
Anybody have any information on this?
Quoted 26 lines
-----Original Message-----
From: kenneth johansson [mailto:kenneth at southpole.se]
Sent: den 10 april 2008 01:00
To: Joakim Tjernlund
Cc: u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] Fixup entriesQuoted 7 lines · Joakim Tjernlund
Quoted 6 lines
-----Original Message-----
From: Kenneth Johansson [mailto:kenneth at southpole.se] Wonder if there is something else in u-boot that use function pointers and work by accident due to the fact that the old address in flash is still valid.Quoted 7 lines
Oh yes, there are a few such pointers. And the conversion to using fixups instead is a bit lazy. Several manual relocations has only been nullified by setting gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel free to send patches :)
Jocke
If by lazy you mean less error prone and obviously simpler :). clearly using -mrelocatable is the smarter thing to do.
Quoted 6 lines
I had this misconception that the GOT was all that was needed for relocation.
Could not find any useful information on what rules apply to gcc and binutils for handling stuff in this fixup section.Anybody have any information on this?
Nope, never found anything either. To see a working one in u-boot, look at mpc83xx start.S and its linker scripts.
Jocke
Quoted 31 lines · Joakim Tjernlund
Quoted 31 lines
-----Original Message-----
From: kenneth johansson [mailto:kenneth at southpole.se]
Sent: den 10 april 2008 01:00
To: Joakim Tjernlund
Cc: u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] Fixup entriesQuoted 7 lines · Joakim Tjernlund
Quoted 6 lines
-----Original Message-----
From: Kenneth Johansson [mailto:kenneth at southpole.se] Wonder if there is something else in u-boot that use function pointers and work by accident due to the fact that the old address in flash is still valid.Quoted 7 lines
Oh yes, there are a few such pointers. And the conversion to using fixups instead is a bit lazy. Several manual relocations has only been nullified by setting gd->reloc_off=0 instead of #ifdef:ing out the relevant code. Feel free to send patches :)
Jocke
If by lazy you mean less error prone and obviously simpler :). clearly using -mrelocatable is the smarter thing to do.
I had this misconception that the GOT was all that was needed for relocation.
Could not find any useful information on what rules apply to gcc and binutils for handling stuff in this fixup section.
Quoted 4 lines
Quoted 1 line
Anybody have any information on this?
Nope, never found anything either. To see a working one in u-boot, look at mpc83xx
start.Sand its linker scripts.
I have it working that is not the problem the problem is that I would like to know why it is :-)
Quoted 7 lines · Joakim Tjernlund
Quoted 7 lines
-----Original Message-----
From: kenneth johansson [mailto:kenneth at southpole.se] I had this misconception that the GOT was all that was needed for relocation.
Could not find any useful information on what rules apply to gcc and binutils for handling stuff in this fixup section.
Quoted 8 lines
Quoted 1 line
Anybody have any information on this?
Nope, never found anything either. To see a working one in u-boot, look at mpc83xx
start.Sand its linker scripts.Jocke
Found some code from gcc that do the relocation in the same way we want in u-boot.
http://gcc.gnu.org/viewcvs/trunk/gcc/config/rs6000/eabi.asm?revision=130805&view=markup
I tried to call __eabi and link with libgcc plus ecrti.o, ecrtn.o but in the end I had one silly undefined symbol(.Lfini) that I could not get past the linker.
But I think copying that code over into u-boot could not hurt. And considering the age of that code I can't imagine that anybody has a tool chain that can't handle using the -mrelocatable. It would be nice to remove the manual relocation done when it's not needed it is just confusing.