Re: bug(?) in ppc relocations

[Momchil Velikov <velco at fadata dot bg>]

Geoff Keating wrote:
> 
> > Date: Mon, 20 Mar 2000 23:02:18 +0200
> > From: Momchil Velikov <velco@fadata.bg>
> 
> >           addend -= (sdata->sym_hash->root.u.def.value
> >                      + sdata->sym_hash->root.u.def.section->output_section->vma
> >                      + sdata->sym_hash->root.u.def.section->output_offset);
> >
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >         }                                   |
> >         break;                              |
> >                               This looks somewhat suspicious.
> > sdata->sym_hash is the _SDA_BASE_ symbol and its value,
> > as far as I can understand, should not be affected by output_offset,
> > right ?
> 
> Why not?  The value of all other symbols are affected by their
> output_offset.
> 
> > Consider the following scenario:
> >  1. The linker creates a linker section .sdata and _SDA_BASE_ with
> > offset 32768
> >  2. The linker outputs to the output .sdata some input .sdata
> >  3. The linker appends the linker .sdata to output .sdata
> > Now data items in the first .sdata are at offset < -32768 relative to
> > _SDA_BASE_ and the linker exits with relocation overflow error.
> >
> > If the above analisys is correct one can think of (at least) two
> > options:
> >   (a) make sure the linker section is output first, or
> >   (b) remove the underlined line above.
> 
> You want (a).  I'm not sure how you managed to get the scenario above
> to happen; I suspect your linker script.

I didn't use a linker script. And the scenario is somewhat hypothetical,
I mean it explains the observations, but I didn't actually traced such
a sequence of events with gdb. Yep, (a) looks better. Case (b) alone
is not enough, one have to modify the code, which outputs the ELF symbol
table, too, introducing bogus special cases and disturbing the uniform
handling of symbol values.

Regards,
-velco