Re: elfxx-ia64.c question

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

Hi Jim,

Thanks for tracking down the source of the change!  Since Richard made
it, I assume there was a good reason for it, which is a bit
unfortunate, since the obvious fix might break something else.

>>>>> On 23 Jan 2003 23:47:05 -0500, Jim Wilson <wilson@redhat.com> said:

  Jim> Do you have an example that shows a problem with the current
  Jim> behaviour?  I don't see how you can get negative values unless
  Jim> something funny is going on, and if something funny is going
  Jim> on, then ignoring the relocation seems like a reasonable thing
  Jim> to do.

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.

	--david