This patch http://sourceware.org/ml/binutils/2005-09/msg00234.html causes the RHEL 4 U2 kernel, 2.6.9-22.EL, failed to boot.
Created attachment 686 [details] A testcase "new-as" is the bad as and "old-as" is the good one without the patch. I got [hjl@gnu-4 dwarf2-2]$ make ./new-as -x -mconstant-gp -o new.o foo.s ./old-as -x -mconstant-gp -o old.o foo.s readelf -a new.o > new readelf -a old.o > old diff -up old new --- old 2005-10-06 16:03:52.000000000 -0700 +++ new 2005-10-06 16:03:52.000000000 -0700 @@ -73,11 +73,11 @@ Relocation section '.rela.data.patch.mck Relocation section '.rela.data.patch.fsyscall_table' at offset 0xc88 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend -000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + 32 +000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + 31 Relocation section '.rela.data.patch.brl_fsys_bubble_down' at offset 0xca0 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend -000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + a2 +000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + a1 Relocation section '.rela.IA_64.unwind' at offset 0xcb8 contains 9 entries: Offset Info Type Sym. Value Sym. Name + Addend make: *** [all] Error 1
It seems that the new assembler doesn't handle tag correctly.
Created attachment 687 [details] A simpler testcase The problem is in tag handling: [hjl@gnu-4 dwarf2-2]$ make ./new-as -x -mconstant-gp -o new.o foo.s ./old-as -x -mconstant-gp -o old.o foo.s readelf -a new.o > new readelf -a old.o > old diff -up old new --- old 2005-10-06 16:23:32.000000000 -0700 +++ new 2005-10-06 16:23:32.000000000 -0700 @@ -51,7 +51,7 @@ There are no program headers in this fil Relocation section '.rela.data.patch.fsyscall_table' at offset 0x360 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend -000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + 2 +000000000000 00010000004d R_IA64_PCREL32LSB 0000000000000000 .text + 1 There are no unwind sections in this file. make: *** [all] Error 1
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.
Subject: Re: IA64 assembler generates bad 2.6.9 Linux kernel. On Fri, Oct 07, 2005 at 01:18:37AM -0000, wilson at specifix dot com wrote: > 1) Why did Richard move the code? Did he run into some problem with the > debug info not matching the tags? The feature implemented in the patch referenced at the start of the bug required that we scan and update labels before emitting the instructions that follow them. It merely seemed convenient to process tags at the same time; there was no hard requirement to move that bit of code as far as I can recall. r~
Subject: Re: IA64 assembler generates bad 2.6.9 Linux kernel. > 2) Why does the kernel care whether we use slot 1 or slot 2 here? It's got some runtime code patching code that assumes it. > Maybe the kernel can be fixed? Yep. ia64_patch_imm64 and ia64_patch_imm60 can use (insn_addr & -16) + {1,2} instead of insn_addr - {1,0} when calling ia64_patch. r~
Will this kernel change fix the kernel? Will this kernel change work with the old assembler?
Subject: Re: IA64 assembler generates bad 2.6.9 Linux kernel. On Fri, 2005-10-07 at 04:32 +0000, hjl at lucon dot org wrote: > ------- Additional Comments From hjl at lucon dot org 2005-10-07 04:32 ------- > Will this kernel change fix the kernel? Will this kernel change work with > the old assembler? The patch will work regardless of what slot the assembler uses for the tag, so yes it will work for both the old and new assemblers. I don't know if it will fix the kernel. You will have to try it. It looks like it will fix the one problem you identified. There could be other problems, though it seems unlikely.
*** Bug 1434 has been marked as a duplicate of this bug. ***
Created attachment 690 [details] A 2.6 kernel patch This patch for 2.6 kernel works for me.
I will submit the kernel patch.