This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: bug(?) in ppc relocations
- To: velco at fadata dot bg
- Subject: Re: bug(?) in ppc relocations
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 21 Mar 2000 13:10:58 -0800
- CC: binutils at sourceware dot cygnus dot com
- References: <38D691DA.B0A3729A@fadata.bg>
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 ?
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.
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.
Ian