Re: Question on PowerPC relocation error

[Sergei Organov <osv at topconrd dot ru>]

Joel Sherrill <joel.sherrill@oarcorp.com> writes:
> Momchil Velikov wrote:
> 
> >>>>>>"Joel" == Joel Sherrill <joel.sherrill@oarcorp.com> writes:
> >>>>>>
> 
> >
> >    Joel> .../ld: ../../../../../mvme2307/lib/librtemsbsp.a(vectors.rel): the
> >    Joel> target (globalExceptHdl) of a R_PPC_EMB_SDA21 relocation is in the
> >    Joel> wrong output section (.bss)
> >    Joel>  What does this error mean and what am I looking for as a
> >    Joel> mistake?
> >
> >Unfortunately, binutils maintainers insist on this broken behaviour.
> >
> >http://sources.redhat.com/ml/binutils/2001-02/msg00442.html
> >
> >~velco
> >
> 
> At least I now understand that the variable in question is ended up in a
> short section.

No, I think it ended up in .bss while it should end up in .sbss. I guess it's
linker command file is broken -- it somehow forces this variable that compiler
puts in .sbss to end up in .bss. Relevant part of the linker map file would be
appropriate to see what happened.

> The compiler is doing it automatically. Whether this is
> broken or not, I need a fix to apply to the code in question.
> 
> Is there a recommended solution?

I believe you need to fix linker command file in order the globalExceptHdl
variable to end up in the .sbss output section instead of .bss. This way all
the C code will access it correctly and efficiently, and asm code will still
access it correctly while not as efficiently.

Alternatively,

>   + declare the variable with an attribute attribute but I don't know what
>     section to force it into.

The .bss seems to be appropriate.

I didn't try to do it using __attribute__. Whenever I need C to think a
variable is in .bss, I declare it as array:

extern int variable[];

that prevents C from putting 'variable' into small sections. This method
doesn't seem to be convenient it your case though.

> 
>   + declare it in assembly but I still don't know the right section.

This won't help as C will assume it's in .sbss anyway given current
declarations.

> 
> So what section does it have to be in?

Checking the linker map file to see what is the exact cause of the problem is
the way to go, I believe.

> 
> --joel

-- 
Sergei.