Message ID | 20180619192633.21846-1-ard.biesheuvel@linaro.org |
---|---|
Headers | show |
Series | Make badr macro compatible with newer GAS versions | expand |
On Tue, Jun 19, 2018 at 09:26:31PM +0200, Ard Biesheuvel wrote: > Work around the mindless and backward incompatible change in GAS that > prevents us from using a simple addition to set the Thumb bit in local > symbol references taken using 'adr' instructions (#2) > > As a preparatory step, remove badr occurrences in ARM code sequences > contained in Thumb2 kernels. > > Ard Biesheuvel (2): > ARM: avoid badr macro for switching to Thumb-2 mode > ARM: assembler: prevent ADR from setting the Thumb bit twice > This doesn't work for images built with a toolchain based on gcc 7.3.0 and binutils 2.28.1. It _does_ work for images built with gcc 7.3.0/ binutils 2.30. Guenter
On 19 June 2018 at 22:32, Guenter Roeck <linux@roeck-us.net> wrote: > On Tue, Jun 19, 2018 at 09:26:31PM +0200, Ard Biesheuvel wrote: >> Work around the mindless and backward incompatible change in GAS that >> prevents us from using a simple addition to set the Thumb bit in local >> symbol references taken using 'adr' instructions (#2) >> >> As a preparatory step, remove badr occurrences in ARM code sequences >> contained in Thumb2 kernels. >> >> Ard Biesheuvel (2): >> ARM: avoid badr macro for switching to Thumb-2 mode >> ARM: assembler: prevent ADR from setting the Thumb bit twice >> > > This doesn't work for images built with a toolchain based on gcc 7.3.0 > and binutils 2.28.1. It _does_ work for images built with gcc 7.3.0/ > binutils 2.30. > Sigh. So does it fail? Or is the resulting binary broken?
On Tue, Jun 19, 2018 at 10:34:38PM +0200, Ard Biesheuvel wrote: > On 19 June 2018 at 22:32, Guenter Roeck <linux@roeck-us.net> wrote: > > On Tue, Jun 19, 2018 at 09:26:31PM +0200, Ard Biesheuvel wrote: > >> Work around the mindless and backward incompatible change in GAS that > >> prevents us from using a simple addition to set the Thumb bit in local > >> symbol references taken using 'adr' instructions (#2) > >> > >> As a preparatory step, remove badr occurrences in ARM code sequences > >> contained in Thumb2 kernels. > >> > >> Ard Biesheuvel (2): > >> ARM: avoid badr macro for switching to Thumb-2 mode > >> ARM: assembler: prevent ADR from setting the Thumb bit twice > >> > > > > This doesn't work for images built with a toolchain based on gcc 7.3.0 > > and binutils 2.28.1. It _does_ work for images built with gcc 7.3.0/ > > binutils 2.30. > > > > Sigh. > > So does it fail? Or is the resulting binary broken? Hard to say. It crashes early in boot, even before earlycon can say anything. Qemu exec trace, broken: race 0: 0x7fffcf92c0c0 [00000000/00000008/0x11080001] Trace 0: 0x7fffcf92c300 [00000000/21008000/0x11080001] stext Trace 0: 0x7fffcf92c480 [00000000/210099ce/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c480 [210099ce] index 1 -> 0x7fffcf92c780 [210099ea] Trace 0: 0x7fffcf92c780 [00000000/210099ea/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c780 [210099ea] index 0 -> 0x7fffcf92c8c0 [210099dc] Trace 0: 0x7fffcf92c8c0 [00000000/210099dc/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c8c0 [210099dc] index 1 -> 0x7fffcf92c780 [210099ea] Trace 0: 0x7fffcf92c780 [00000000/210099ea/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c8c0 [210099dc] index 0 -> 0x7fffcf92ca80 [210099f6] Trace 0: 0x7fffcf92ca80 [00000000/210099f6/0x11080001] __lookup_processor_type Trace 0: 0x7fffcf92cb80 [00000000/2100800c/0x11080001] stext Linking TBs 0x7fffcf92cb80 [2100800c] index 1 -> 0x7fffcf92cc80 [21008014] Trace 0: 0x7fffcf92cc80 [00000000/21008014/0x11080001] stext Trace 0: 0x7fffcf92cdc0 [00000000/2120477e/0x11080001] __v7m_setup Trace 0: 0x7fffcf92d400 [00000000/212047bc/0x11080001] __v7m_setup Trace 0: 0x7fffcf92d500 [00000000/212047be/0x11280000] __v7m_setup ^^^^^^^^^^ Trace 0: 0x7fffcf92d600 [00000000/2100b830/0x11280001] __invalid_entry Trace 0: 0x7fffcf92d880 [00000000/2100b842/0x11280001] __invalid_entry Trace 0: 0x7fffcf92e100 [00000000/21025780/0x11280001] printk Trace 0: 0x7fffcf92e640 [00000000/21025a7c/0x11280001] vprintk_func Qemu exec trace, ok: Trace 0: 0x7fffcf92c0c0 [00000000/00000008/0x11080001] Trace 0: 0x7fffcf92c300 [00000000/21008000/0x11080001] stext Trace 0: 0x7fffcf92c480 [00000000/210099ce/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c480 [210099ce] index 1 -> 0x7fffcf92c780 [210099ea] Trace 0: 0x7fffcf92c780 [00000000/210099ea/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c780 [210099ea] index 0 -> 0x7fffcf92c8c0 [210099dc] Trace 0: 0x7fffcf92c8c0 [00000000/210099dc/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c8c0 [210099dc] index 1 -> 0x7fffcf92c780 [210099ea] Trace 0: 0x7fffcf92c780 [00000000/210099ea/0x11080001] __lookup_processor_type Linking TBs 0x7fffcf92c8c0 [210099dc] index 0 -> 0x7fffcf92ca80 [210099f6] Trace 0: 0x7fffcf92ca80 [00000000/210099f6/0x11080001] __lookup_processor_type Trace 0: 0x7fffcf92cb80 [00000000/2100800c/0x11080001] stext Linking TBs 0x7fffcf92cb80 [2100800c] index 1 -> 0x7fffcf92cc80 [21008014] Trace 0: 0x7fffcf92cc80 [00000000/21008014/0x11080001] stext Trace 0: 0x7fffcf92cdc0 [00000000/2120477e/0x11080001] __v7m_setup Trace 0: 0x7fffcf92d400 [00000000/212047bc/0x11080001] __v7m_setup Trace 0: 0x7fffcf92d500 [00000000/212047be/0x11280001] __v7m_setup Trace 0: 0x7fffcf92d600 [00000000/212047c0/0x11280001] __v7m_setup Trace 0: 0x7fffcf92d900 [00000000/212047d2/0x11280001] __v7m_setup Linking TBs 0x7fffcf92d900 [212047d2] index 1 -> 0x7fffcf92dcc0 [212047e0] Trace 0: 0x7fffcf92dcc0 [00000000/212047e0/0x11280001] __v7m_setup Trace 0: 0x7fffcf92e0c0 [00000000/21008020/0x11280001] stext Trace 0: 0x7fffcf92e200 [00000000/210099c8/0x11280001] __after_proc_init Guenter
On 19 June 2018 at 22:45, Guenter Roeck <linux@roeck-us.net> wrote: > On Tue, Jun 19, 2018 at 10:34:38PM +0200, Ard Biesheuvel wrote: >> On 19 June 2018 at 22:32, Guenter Roeck <linux@roeck-us.net> wrote: >> > On Tue, Jun 19, 2018 at 09:26:31PM +0200, Ard Biesheuvel wrote: >> >> Work around the mindless and backward incompatible change in GAS that >> >> prevents us from using a simple addition to set the Thumb bit in local >> >> symbol references taken using 'adr' instructions (#2) >> >> >> >> As a preparatory step, remove badr occurrences in ARM code sequences >> >> contained in Thumb2 kernels. >> >> >> >> Ard Biesheuvel (2): >> >> ARM: avoid badr macro for switching to Thumb-2 mode >> >> ARM: assembler: prevent ADR from setting the Thumb bit twice >> >> >> > >> > This doesn't work for images built with a toolchain based on gcc 7.3.0 >> > and binutils 2.28.1. It _does_ work for images built with gcc 7.3.0/ >> > binutils 2.30. >> > >> >> Sigh. >> >> So does it fail? Or is the resulting binary broken? > > Hard to say. It crashes early in boot, even before earlycon can say > anything. > OK, so even the linker handling is inconsistent. Working (binutils 2.30) c0301164 <local_restart>: c0301164: f8d9 a000 ldr.w sl, [r9] c0301168: e92d 0030 stmdb sp!, {r4, r5} c030116c: f01a 0ff0 tst.w sl, #240 ; 0xf0 c0301170: d117 bne.n c03011a2 <__sys_trace> c0301172: 46ba mov sl, r7 c0301174: f5ba 7fc8 cmp.w sl, #400 ; 0x190 c0301178: bf28 it cs c030117a: f04f 0a00 movcs.w sl, #0 c030117e: f3af 8014 csdb c0301182: f2af 1e83 subw lr, pc, #387 ; 0x183 c0301182: R_ARM_THM_ALU_PREL_11_0 .Lsym28 Broken (binutils 2.26) c0301184 <local_restart>: c0301184: f8d9 a000 ldr.w sl, [r9] c0301188: e92d 0030 stmdb sp!, {r4, r5} c030118c: f01a 0ff0 tst.w sl, #240 ; 0xf0 c0301190: d117 bne.n c03011c2 <__sys_trace> c0301192: 46ba mov sl, r7 c0301194: f5ba 7fc8 cmp.w sl, #400 ; 0x190 c0301198: bf28 it cs c030119a: f04f 0a00 movcs.w sl, #0 c030119e: f3af 8014 csdb c03011a2: f2af 1ea2 subw lr, pc, #418 ; 0x1a2 c03011a2: R_ARM_THM_ALU_PREL_11_0 .Lsym30 Note the even immediate in the subw instruction. So this is another dead end, unfortunately. Thanks for testing.
On Wed, Jun 20, 2018 at 12:23:56AM +0200, Ard Biesheuvel wrote: > > OK, so even the linker handling is inconsistent. > > Working (binutils 2.30) > > c0301164 <local_restart>: > c0301164: f8d9 a000 ldr.w sl, [r9] > c0301168: e92d 0030 stmdb sp!, {r4, r5} > c030116c: f01a 0ff0 tst.w sl, #240 ; 0xf0 > c0301170: d117 bne.n c03011a2 <__sys_trace> > c0301172: 46ba mov sl, r7 > c0301174: f5ba 7fc8 cmp.w sl, #400 ; 0x190 > c0301178: bf28 it cs > c030117a: f04f 0a00 movcs.w sl, #0 > c030117e: f3af 8014 csdb > c0301182: f2af 1e83 subw lr, pc, #387 ; 0x183 > c0301182: R_ARM_THM_ALU_PREL_11_0 .Lsym28 > > > Broken (binutils 2.26) > > c0301184 <local_restart>: > c0301184: f8d9 a000 ldr.w sl, [r9] > c0301188: e92d 0030 stmdb sp!, {r4, r5} > c030118c: f01a 0ff0 tst.w sl, #240 ; 0xf0 > c0301190: d117 bne.n c03011c2 <__sys_trace> > c0301192: 46ba mov sl, r7 > c0301194: f5ba 7fc8 cmp.w sl, #400 ; 0x190 > c0301198: bf28 it cs > c030119a: f04f 0a00 movcs.w sl, #0 > c030119e: f3af 8014 csdb > c03011a2: f2af 1ea2 subw lr, pc, #418 ; 0x1a2 > c03011a2: R_ARM_THM_ALU_PREL_11_0 .Lsym30 > > > Note the even immediate in the subw instruction. So this is another > dead end, unfortunately. > Looks like someone is trying to make things really difficunt :-(. I think I'll just stick with binutils 2.28.1. Not optimal, but at least it works. Something else: I can boot Cortex-M under qemu (-M mps2-an385). The only problem I have is this: / # kill -1 1 [ 3.806568] [ 3.806568] Unhandled exception: IPSR = 00000006 LR = fffffffd [ 3.807221] CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00043-gba4dbdedd3ed #42 [ 3.807590] Hardware name: MPS2 (Device Tree Support) [ 3.808162] PC is at (null) [ 3.808374] LR is at 0x2170fc37 [ 3.808549] pc : [<00000000>] lr : [<2170fc37>] psr: 60000000 [ 3.808841] sp : 21761b90 ip : 21761f00 fp : 21758c04 [ 3.809118] r10: 00000000 r9 : 00000000 r8 : 00000000 [ 3.809329] r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 2175452c [ 3.809565] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000001 [ 3.809791] xPSR: 60000000 [ 3.809926] CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00043-gba4dbdedd3ed #42 [ 3.810179] Hardware name: MPS2 (Device Tree Support) [ 3.811246] [<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc) [ 3.811656] [<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c) Everything else seems to work, just sending a signal to init causes it to blow up. Any idea what might cause this ? Thanks, Guenter