This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Question on PowerPC relocation error
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.