This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: elfxx-ia64.c question
On Thu, Jan 23, 2003 at 11:13:38PM -0800, David Mosberger wrote:
> Yes, here is why I ran into it: I would like to use @secrel() in the
> linux kernel to build the exception tables. We used to use @gprel()
> entries for this purpose, but that doesn't work with the latest kernel
> setup anymore (and wasn't a good idea anyhow). Alpha Linux uses the
> "label-." construct to build pc-relative entries that fit in 32 bits;
> in principle, this would work on ia64, too, except that there seems to
> be a gas bug that prevents this from working. With @secrel() I can
> make it work, modulo the silent truncate-to-zero problem.
> Specifically, with @secrel() an exception-entry might look like this:
>
> .section "__ex_table", "a"
>
> .text
> [1:] INSTRUCTION_THAT MIGHT_FAULT
> .xdata4 "__ex_table", @secrel(1b), @secrel(1f)
> [1:] CONTINUATION_POINT
>
> The Linux kernel linker script normally places the __ex_table section
> after the .text section, such that the @secrel() entries are negative
> and the above "bug" kicks in and silently puts all zeroes in the
> exception table. Not very useful. I was able to fix it by moving
> __ex_table in front of .text, but that's not a very clean solution.
>
> It sounds to me like the linker doesn't expect @secrel() to go across
> sections, but from my reading of the ps-ABI this is legal.
I don't think secrel really does what you want here.
The only reason to move away from gp-relative is to avoid having some
magic constant that needs looking up to resolve the complete address.
You don't get that from either secrel or segrel -- you'd still need to
track the base address against which these are relative.
Best just fix whatever pcrel gas problem you're having.
r~