[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel.
From: |
wilson at specifix dot com |
Subject: |
[Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel. |
Date: |
7 Oct 2005 01:18:36 -0000 |
------- Additional Comments From wilson at specifix dot com 2005-10-07 01:18
-------
Subject: Re: IA64 assembler generates bad 2.6.9 Linux kernel.
On Thu, 2005-10-06 at 16:24, hjl at lucon dot org wrote:
> -000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + 2
> +000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + 1
This seems to be an old debate reborn. When we have relocs, tags, debug
info, whatever that applies to a long (2-slot) instruction, do we point
at slot 1 or slot 2?
old-as is pointing at slot 2. new-as is pointing at slot 1. One could
argue that new-as is actually more correct in this case, because the tag
should be pointing before the long instruction, and hence must be
pointing at slot 1.
Richard's patch broke this because he moved the tag_fixups code in
emit_one_bundle before the code that increments i when required_unit ==
IA64_UNIT_L.
So in the old code, we are setting debug info and unwind info to point
to slot 1 (before we increment i), and tags and relocs to point to slot
2 (after we increment i).
In the new code, we are setting debug info, unwind info, and tags to
point to slot 1 (before we increment i), and relocs to point to slot 2
(after we increment i).
At least we are consistently inconsistent.
Questions to ask at this point are:
1) Why did Richard move the code? Did he run into some problem with the
debug info not matching the tags?
2) Why does the kernel care whether we use slot 1 or slot 2 here? Maybe
the kernel can be fixed? It seems wrong for the kernel to insist that a
tag must point into the middle of a long instruction.
3) Will this change affect gdb?
4) What does IAS do in this case?
5) Maybe we should fix relocs to point at slot 1 and then be completely
consistent? This is an ABI change unfortunately, though perhaps we can
hide it by making the linker accept either one for a while.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=1433
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
- [Bug gas/1433] New: IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/06
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/06
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/06
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/06
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel.,
wilson at specifix dot com <=
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., rth at redhat dot com, 2005/10/06
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., rth at redhat dot com, 2005/10/06
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/07
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., wilson at specifix dot com, 2005/10/07
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., rth at gcc dot gnu dot org, 2005/10/07
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/07
- [Bug gas/1433] IA64 assembler generates bad 2.6.9 Linux kernel., hjl at lucon dot org, 2005/10/07