Re: bug(?) in ppc relocations

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Mon, 20 Mar 2000 23:32:07 +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 ?
   > 
   > You are incorrect.  It should be affected by output_offset.  Any time
   > you look at section->output_section->vma, you need to look at
   > output_offset.
   Yep, for ordinary symbols, but _SDA_BASE_ is not quite normal, is it ?

_SDA_BASE_ is not quite normal, correct.

Nevertheless, any time you look at section->output_section->vma, you
need to look at output_offset.  That doesn't have anything to do with
_SDA_BASE_.  If it is correct to use output_section->vma, then it is
correct to use output_offset.  If output_offset is not correct, then
output_section->vma is not correct.

   >    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.
   > 
   > I don't understand your analysis.
   > 
   > Are you assuming that output_offset changes during the final linking
   > phase?  It doesn't.
   Nope, I don't assume that. I see the output offset of the linker .sdata
   secton being greater than zero, so the value of _SDA_BASE_ in the
   output file is == (the address of .sdata + something greater than
   32768), thus
   the data items near the beginning of .sdata cannot be addressed with
   signed 16-bit offset from _SDA_BASE_.

In that case, it sounds to me like _SDA_BASE_ was set to an
inappropriate value.  _SDA_BASE_ should be set to something like the
address where the first .sdata section is stored plus 32768.  The
address where the first .sdata section is stored may have a non-zero
output_offset.

Personally, I think something like _SDA_BASE_ should be set in the
linker script.  That is what linker scripts are for.  However, I see
that the PowerPC backend appears to be trying to set it directly.
Perhaps that is the problem.  How does the PowerPC backend set
_SDA_BASE_?

Ian