[U-Boot-Users] Fixup entries

[U-Boot-Users] Fixup entries

[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.

[U-Boot-Users] Fixup entries

[Joakim Tjernlund]

On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote:
> 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

[U-Boot-Users] Fixup entries

[Kenneth Johansson]

On Wed, 2008-04-09 at 13:23 +0200, Joakim Tjernlund wrote:
> On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote:
> > 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

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'.

[U-Boot-Users] Fixup entries

[Joakim Tjernlund]

> -----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 entries
> 
> 
> On Wed, 2008-04-09 at 13:23 +0200, Joakim Tjernlund wrote:
> > On Wed, 2008-04-09 at 11:32 +0200, Kenneth Johansson wrote:
> > > 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
> 
> 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.

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

[U-Boot-Users] Fixup entries

[kenneth johansson]

On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote:
> 
> > -----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.
> 
> 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?

[U-Boot-Users] Fixup entries

[Joakim Tjernlund]

> -----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 entries
> 
> On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote:
> >
> > > -----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.
> >
> > 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?

Nope, never found anything either. To see a working one in u-boot, look at
mpc83xx start.S and its linker scripts.

 Jocke

[U-Boot-Users] Fixup entries

[kenneth johansson]

On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote:
> > -----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 entries
> > 
> > On Wed, 2008-04-09 at 18:19 +0200, Joakim Tjernlund wrote:
> > >
> > > > -----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.
> > >
> > > 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?
> 
> Nope, never found anything either. To see a working one in u-boot, look at
> mpc83xx start.S and its linker scripts.

I have it working that is not the problem the problem is that I would
like to know why it is :-)

[U-Boot-Users] Fixup entries

[Kenneth Johansson]

On Thu, 2008-04-10 at 01:03 +0200, Joakim Tjernlund wrote:
> > -----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.
> > 
> > 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
> 
> 

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.