Hi Jakub,
The following instruction:
addl r36 = @ltoff(@fptr(__entry#)), gp
gets linked as either (ld 2.20):
28806: 40 02 04 00 48 20 addl r36=0,r1
or (ld 2.21):
24846: 40 02 07 8c 48 20 addl r36=9056,r1
Have you verified that the object files produced by the 2.20 and 2.21
assemblers are the same ? (Including the relocs). If not then this
could be a gas bug rather than an ld bug...
I would be grateful for any hint that would explain the sudden runaway
gp offset.
It sounds like the evaluation of the relocation that computes the gp
offset is going wrong. Without more context it is hard to theorize any
further. Things that you could try include:
* Submit a bug report to http://sourceware.org/bugzilla/
If you include a small testcase to reproduce the problem that would
really help.
* Try a binary chop search to find out which patch caused the
problem. This assumes that you have a lot of bandwidth and/or a local
copy of the binutils CVS archive...
* Look at the source code in bfd/elfxx-ia64.c and see if you can find
the problem. As a first guess I would suggest looking at how the
LTOFF_FPTR22, LTOFF_FPTR64I, LTOFF_FPTR32MSB, LTOFF_FPTR32LSB,
LTOFF_FPTR64MSB and LTOFF_FPTR64LSB relocations are processed in the
...check_relocs() and ...relocate_section() functions.
Cheers
Nick
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
