This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: PATCH: BZ/175: Fix dynamic string offset
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 21 May 2004 10:55:03 +0930
- Subject: Re: PATCH: BZ/175: Fix dynamic string offset
- References: <20040520225441.GA20406@lucon.org>
On Thu, May 20, 2004 at 03:54:41PM -0700, H. J. Lu wrote:
> For
> x = "1111" + (y - 0x1000) * 2;
>
> gcc can generate
>
> addl r14 = @ltoffx(.LC0-8192), r1
> ;;
> ld8.mov r14 = [r14], .LC0-8192
> ;;
>
> _bfd_merged_section_offset thinks offset + adddend is bad when it is
> not the real string position. I looked at _bfd_merged_section_offset.
> It is always passed with addend == 0. I changed addend to dynamic_offset
> so that we can tell _bfd_merged_section_offset to compute offset
> properly. If my patch is right, we may need to make similar change
> to elf32-ppc.c.
I think it quite possible that this patch will break other accesses
into merged sections. To properly fix the problem, you would need to
distinguish this particular access from others. Perhaps the reloc used
might give you enough information.
Consider the case where you have:
a: .string "abc"
b: .string "d"
and someone accesses b using a+4. In that case you want the addend, 4,
to be taken into account in the merge hash table. b can be moved away
from a. My example might be a poor one, but I recall Jakub ran into
something similar when implementing the merge code.
--
Alan Modra
IBM OzLabs - Linux Technology Centre