Re: elfxx-ia64.c question

[Richard Henderson <rth at redhat dot com>]

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~