This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gas relocations for .uleb128
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: M R Swami Reddy <MR dot Swami dot Reddy at nsc dot com>
- Cc: "yvan dot roux at st dot com" <yvan dot roux at st dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 10 Aug 2009 16:38:56 +0930
- Subject: Re: gas relocations for .uleb128
- References: <4A7A91CB.5030606@nsc.com> <4A7BBB45.4050008@nsc.com> <4A7C1EF5.9080901@nsc.com> <4A7C2C5D.5020607@st.com> <4A7FA876.4090406@nsc.com>
On Mon, Aug 10, 2009 at 10:26:22AM +0530, M R Swami Reddy wrote:
> Hi Yvan,
>
>>> Is the ".uleb128" directive expression generate relocation?
>>>
>>
>> As far as I know, the answer is No, and it's a problem if
>> you want to support c++ exceptions and relaxation (for instance ;-)).
>>
> Yes, I am also facing the same issue as you mentioned above for cr16 target.
>
>> What we've done in the SH backend, is to disable the leb128
>> encoding (in the compiler) when relaxation is enable (a patch
>> for the SH relaxation is under construction). However, I think that
>> it would be better to add the "leb128 support" in the linker, to
>> take benefits from both sides.
> What I am thinking is: in gas, add .leb128 processing (ie target specific)
> and include the relocs if needed (ie similar to .long directive processing).
> Is this ok?
The expression you showed calculated the difference of two symbols in
another section. That means your new reloc would need to reference
two symbols. How are you going to do that?
You need to use debug and eh_frame encoding that is friendly towards
relaxation. If you want to emit more efficiently encoded dwarf, add
support in the linker to rewrite dwarf. This isn't a trivial
exercise.
--
Alan Modra
Australia Development Lab, IBM