Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

[Nathan Chancellor]

Hi all,

Upstream binutils commit a87e1817a4 ("Have the linker fail if any attempt
to link in an executable is made.") causes the RISC-V vDSO to fail to
build properly (it is fixing this bug report:
https://sourceware.org/bugzilla/show_bug.cgi?id=26047):

$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig arch/riscv/kernel/vdso/
riscv64-linux-ld: cannot use executable file 'arch/riscv/kernel/vdso/vdso-dummy.o' as input to a link

I do not really understand what the whole point of the vDSO rule is but
it seems like it should be fixed due to this change. Additionally, the
kernel has generally been getting rid of using $(CC) as a linker,
instead preferring to use $(LD) directly; it would be nice if the RISC-V
vDSO's Makefile could be rewritten to do that.

See

fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")

for more examples of that. I would take a stab at it myself but this
does not seem like a straight conversion due to the way the VDSOLD rule
is set up.

Cheers,
Nathan

Re: Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

[Fāng-ruì Sòng]

I suggested that GNU ld from 2.35 onwards disallows accepting ET_EXEC
as input (https://sourceware.org/bugzilla/show_bug.cgi?id=26047 ). The
error message is from the patch.
Taking ET_EXEC files as input are usually errors.

If we do need to take ET_EXEC as input, we can change e_type in the
ELF header to make the file an ET_REL

printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
(See http://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584 )


On Fri, Jun 12, 2020 at 1:43 AM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Hi all,
>
> Upstream binutils commit a87e1817a4 ("Have the linker fail if any attempt
> to link in an executable is made.") causes the RISC-V vDSO to fail to
> build properly (it is fixing this bug report:
> https://sourceware.org/bugzilla/show_bug.cgi?id=26047):
>
> $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig arch/riscv/kernel/vdso/
> riscv64-linux-ld: cannot use executable file 'arch/riscv/kernel/vdso/vdso-dummy.o' as input to a link
>
> I do not really understand what the whole point of the vDSO rule is but
> it seems like it should be fixed due to this change. Additionally, the
> kernel has generally been getting rid of using $(CC) as a linker,
> instead preferring to use $(LD) directly; it would be nice if the RISC-V
> vDSO's Makefile could be rewritten to do that.
>
> See
>
> fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
> 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
> 2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
>
> for more examples of that. I would take a stab at it myself but this
> does not seem like a straight conversion due to the way the VDSOLD rule
> is set up.
>
> Cheers,
> Nathan



-- 
宋方睿

Re: Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

[Nathan Chancellor]

Hi Fangrui,

On Fri, Jun 12, 2020 at 08:41:56AM -0700, Fāng-ruì Sòng wrote:
> On Fri, Jun 12, 2020 at 1:43 AM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > Hi all,
> >
> > Upstream binutils commit a87e1817a4 ("Have the linker fail if any attempt
> > to link in an executable is made.") causes the RISC-V vDSO to fail to
> > build properly (it is fixing this bug report:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26047):
> >
> > $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig arch/riscv/kernel/vdso/
> > riscv64-linux-ld: cannot use executable file 'arch/riscv/kernel/vdso/vdso-dummy.o' as input to a link
> >
> > I do not really understand what the whole point of the vDSO rule is but
> > it seems like it should be fixed due to this change. Additionally, the
> > kernel has generally been getting rid of using $(CC) as a linker,
> > instead preferring to use $(LD) directly; it would be nice if the RISC-V
> > vDSO's Makefile could be rewritten to do that.
> >
> > See
> >
> > fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
> > 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
> > 2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
> >
> > for more examples of that. I would take a stab at it myself but this
> > does not seem like a straight conversion due to the way the VDSOLD rule
> > is set up.
> >
> > Cheers,
> > Nathan
> 
> I suggested that GNU ld from 2.35 onwards disallows accepting ET_EXEC
> as input (https://sourceware.org/bugzilla/show_bug.cgi?id=26047 ). The
> error message is from the patch.
> Taking ET_EXEC files as input are usually errors.
> 
> If we do need to take ET_EXEC as input, we can change e_type in the
> ELF header to make the file an ET_REL
> 
> printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> (See http://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584 )

Is there a convenient way to do this in a Makefile? The relevant rule
is:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/kernel/vdso/Makefile#n63

I am not sure if that is strictly necessary, hence the initial email.

Cheers,
Nathan

Re: Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

[Fāng-ruì Sòng]

On Tue, Jun 16, 2020 at 7:42 PM Nathan Chancellor
<natechancellor@gmail.com> wrote:
>
> Hi Fangrui,
>
> On Fri, Jun 12, 2020 at 08:41:56AM -0700, Fāng-ruì Sòng wrote:
> > On Fri, Jun 12, 2020 at 1:43 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > Upstream binutils commit a87e1817a4 ("Have the linker fail if any attempt
> > > to link in an executable is made.") causes the RISC-V vDSO to fail to
> > > build properly (it is fixing this bug report:
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=26047):
> > >
> > > $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig arch/riscv/kernel/vdso/
> > > riscv64-linux-ld: cannot use executable file 'arch/riscv/kernel/vdso/vdso-dummy.o' as input to a link
> > >
> > > I do not really understand what the whole point of the vDSO rule is but
> > > it seems like it should be fixed due to this change. Additionally, the
> > > kernel has generally been getting rid of using $(CC) as a linker,
> > > instead preferring to use $(LD) directly; it would be nice if the RISC-V
> > > vDSO's Makefile could be rewritten to do that.
> > >
> > > See
> > >
> > > fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
> > > 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
> > > 2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
> > >
> > > for more examples of that. I would take a stab at it myself but this
> > > does not seem like a straight conversion due to the way the VDSOLD rule
> > > is set up.
> > >
> > > Cheers,
> > > Nathan
> >
> > I suggested that GNU ld from 2.35 onwards disallows accepting ET_EXEC
> > as input (https://sourceware.org/bugzilla/show_bug.cgi?id=26047 ). The
> > error message is from the patch.
> > Taking ET_EXEC files as input are usually errors.
> >
> > If we do need to take ET_EXEC as input, we can change e_type in the
> > ELF header to make the file an ET_REL
> >
> > printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> > (See http://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584 )
>
> Is there a convenient way to do this in a Makefile? The relevant rule
> is:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/kernel/vdso/Makefile#n63
>
> I am not sure if that is strictly necessary, hence the initial email.
>
> Cheers,
> Nathan

If I understand correctly,

$(obj)/vdso-dummy.o:
...
        printf '\1' | dd of=$@ conv=notrunc bs=1 seek=16 status=none

should fix the issue. The change can be made along with the migration
from $(CC) to $(LD). Hope an arch/riscv maintainer can do this.

Re: Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

[Nathan Chancellor]

On Tue, Jun 16, 2020 at 08:34:04PM -0700, Fāng-ruì Sòng wrote:
> On Tue, Jun 16, 2020 at 7:42 PM Nathan Chancellor
> <natechancellor@gmail.com> wrote:
> >
> > Hi Fangrui,
> >
> > On Fri, Jun 12, 2020 at 08:41:56AM -0700, Fāng-ruì Sòng wrote:
> > > On Fri, Jun 12, 2020 at 1:43 AM Nathan Chancellor
> > > <natechancellor@gmail.com> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > Upstream binutils commit a87e1817a4 ("Have the linker fail if any attempt
> > > > to link in an executable is made.") causes the RISC-V vDSO to fail to
> > > > build properly (it is fixing this bug report:
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=26047):
> > > >
> > > > $ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig arch/riscv/kernel/vdso/
> > > > riscv64-linux-ld: cannot use executable file 'arch/riscv/kernel/vdso/vdso-dummy.o' as input to a link
> > > >
> > > > I do not really understand what the whole point of the vDSO rule is but
> > > > it seems like it should be fixed due to this change. Additionally, the
> > > > kernel has generally been getting rid of using $(CC) as a linker,
> > > > instead preferring to use $(LD) directly; it would be nice if the RISC-V
> > > > vDSO's Makefile could be rewritten to do that.
> > > >
> > > > See
> > > >
> > > > fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
> > > > 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
> > > > 2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
> > > >
> > > > for more examples of that. I would take a stab at it myself but this
> > > > does not seem like a straight conversion due to the way the VDSOLD rule
> > > > is set up.
> > > >
> > > > Cheers,
> > > > Nathan
> > >
> > > I suggested that GNU ld from 2.35 onwards disallows accepting ET_EXEC
> > > as input (https://sourceware.org/bugzilla/show_bug.cgi?id=26047 ). The
> > > error message is from the patch.
> > > Taking ET_EXEC files as input are usually errors.
> > >
> > > If we do need to take ET_EXEC as input, we can change e_type in the
> > > ELF header to make the file an ET_REL
> > >
> > > printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> > > (See http://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584 )
> >
> > Is there a convenient way to do this in a Makefile? The relevant rule
> > is:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/kernel/vdso/Makefile#n63
> >
> > I am not sure if that is strictly necessary, hence the initial email.
> >
> > Cheers,
> > Nathan
> 
> If I understand correctly,
> 
> $(obj)/vdso-dummy.o:
> ...
>         printf '\1' | dd of=$@ conv=notrunc bs=1 seek=16 status=none
> 
> should fix the issue. The change can be made along with the migration
> from $(CC) to $(LD). Hope an arch/riscv maintainer can do this.
> 

Sorry for taking so long to double back around to this... This does
indeed help the build complete. However, I see a kernel panic at boot as
soon as init runs. I am not sure why that is and I do not really have
time to debug this. Hopefully someone has the time/capacity to look into
this as binutils 2.35 has branched and will most likely be released
soon. Below are build commands and boot utils is our booting
infrastructure: https://github.com/ClangBuiltLinux/boot-utils

$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux- O=out/riscv distclean defconfig Image

$ ../../cbl/github/boot-utils/boot-qemu.sh -a riscv -k out/riscv -t 20s
...
+ timeout --foreground 20s unbuffer qemu-system-riscv64 -bios default -M virt -append '' -display none -initrd /home/nathan/cbl/github/boot-utils/images/riscv/rootfs.cpio -kernel /home/nathan/src/linux/out/riscv/arch/riscv/boot/Image -m 512m -nodefaults -serial mon:stdio

OpenSBI v0.5 (Oct  9 2019 12:03:04)
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|

Platform Name          : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs     : 8
Current Hart           : 0
Firmware Base          : 0x80000000
Firmware Size          : 116 KB
Runtime SBI Version    : 0.2

PMP0: 0x0000000080000000-0x000000008001ffff (A)
PMP1: 0x0000000000000000-0xffffffffffffffff (A,R,W,X)
[    0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[    0.000000] Linux version 5.8.0-rc5-00048-gf8456690ba8e-dirty (nathan@ubuntu-n2-xlarge-x86) (riscv64-linux-gcc (GCC) 10.1.0, GNU ld (GNU Binutils) 2.34.90.20200716) #1 SMP Wed Jul 15 21:03:47 MST 2020
[    0.000000] Initial ramdisk at: 0x(____ptrval____) (5446144 bytes)
[    0.000000] Zone ranges:
[    0.000000]   DMA32    [mem 0x0000000080200000-0x000000009fffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000080200000-0x000000009fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000009fffffff]
[    0.000000] software IO TLB: mapped [mem 0x9b8fb000-0x9f8fb000] (64MB)
[    0.000000] SBI specification v0.2 detected
[    0.000000] SBI implementation ID=0x1 Version=0x5
[    0.000000] riscv: ISA extensions acdfimsu
[    0.000000] riscv: ELF capabilities acdfim
[    0.000000] percpu: Embedded 17 pages/cpu s31976 r8192 d29464 u69632
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 128775
[    0.000000] Kernel command line: 
[    0.000000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    0.000000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.000000] Sorting __ex_table...
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 425824K/522240K available (6549K kernel code, 4129K rwdata, 4096K rodata, 235K init, 317K bss, 96416K reserved, 0K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]       fixmap : 0xffffffcefee00000 - 0xffffffceff000000   (2048 kB)
[    0.000000]       pci io : 0xffffffceff000000 - 0xffffffcf00000000   (  16 MB)
[    0.000000]      vmemmap : 0xffffffcf00000000 - 0xffffffcfffffffff   (4095 MB)
[    0.000000]      vmalloc : 0xffffffd000000000 - 0xffffffdfffffffff   (65535 MB)
[    0.000000]       lowmem : 0xffffffe000000000 - 0xffffffe01fe00000   ( 510 MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[    0.000000] rcu: 	RCU debug extended QS entry/exit.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] riscv-intc: 64 local interrupts mapped
[    0.000000] plic: interrupt-controller@c000000: mapped 53 interrupts with 1 handlers for 2 contexts.
[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [0]
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[    0.000135] sched_clock: 64 bits at 10MHz, resolution 100ns, wraps every 4398046511100ns
[    0.002830] Console: colour dummy device 80x25
[    0.004195] printk: console [tty0] enabled
[    0.005128] Calibrating delay loop (skipped), value calculated using timer frequency.. 20.00 BogoMIPS (lpj=40000)
[    0.007274] pid_max: default: 32768 minimum: 301
[    0.008384] Mount-cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
[    0.008473] Mountpoint-cache hash table entries: 1024 (order: 1, 8192 bytes, linear)
[    0.030542] rcu: Hierarchical SRCU implementation.
[    0.034569] smp: Bringing up secondary CPUs ...
[    0.034688] smp: Brought up 1 node, 1 CPU
[    0.042468] devtmpfs: initialized
[    0.046350] random: get_random_u32 called from bucket_table_alloc.isra.0+0x4e/0x154 with crng_init=0
[    0.048380] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.048608] futex hash table entries: 256 (order: 2, 16384 bytes, linear)
[    0.052998] NET: Registered protocol family 16
[    0.091600] vgaarb: loaded
[    0.092645] SCSI subsystem initialized
[    0.094241] usbcore: registered new interface driver usbfs
[    0.094542] usbcore: registered new interface driver hub
[    0.095001] usbcore: registered new device driver usb
[    0.102849] clocksource: Switched to clocksource riscv_clocksource
[    0.125133] NET: Registered protocol family 2
[    0.128450] tcp_listen_portaddr_hash hash table entries: 256 (order: 1, 10240 bytes, linear)
[    0.128603] TCP established hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.128844] TCP bind hash table entries: 4096 (order: 5, 131072 bytes, linear)
[    0.129105] TCP: Hash tables configured (established 4096 bind 4096)
[    0.129903] UDP hash table entries: 256 (order: 2, 24576 bytes, linear)
[    0.130166] UDP-Lite hash table entries: 256 (order: 2, 24576 bytes, linear)
[    0.132514] NET: Registered protocol family 1
[    0.135278] RPC: Registered named UNIX socket transport module.
[    0.135362] RPC: Registered udp transport module.
[    0.135412] RPC: Registered tcp transport module.
[    0.135460] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.135596] PCI: CLS 0 bytes, default 64
[    0.138668] Unpacking initramfs...
[    0.293130] Freeing initrd memory: 5316K
[    0.295114] workingset: timestamp_bits=62 max_order=17 bucket_order=0
[    0.305250] NFS: Registering the id_resolver key type
[    0.305923] Key type id_resolver registered
[    0.306002] Key type id_legacy registered
[    0.306136] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.306926] 9p: Installing v9fs 9p2000 file system support
[    0.308068] NET: Registered protocol family 38
[    0.308340] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    0.308489] io scheduler mq-deadline registered
[    0.308590] io scheduler kyber registered
[    0.316932] pci-host-generic 30000000.pci: host bridge /soc/pci@30000000 ranges:
[    0.317532] pci-host-generic 30000000.pci:       IO 0x0003000000..0x000300ffff -> 0x0000000000
[    0.317945] pci-host-generic 30000000.pci:      MEM 0x0040000000..0x007fffffff -> 0x0040000000
[    0.319707] pci-host-generic 30000000.pci: ECAM at [mem 0x30000000-0x3fffffff] for [bus 00-ff]
[    0.320462] pci-host-generic 30000000.pci: PCI host bridge to bus 0000:00
[    0.320672] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.320820] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
[    0.320881] pci_bus 0000:00: root bus resource [mem 0x40000000-0x7fffffff]
[    0.321578] pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
[    0.440679] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.447058] 10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 1, base_baud = 230400) is a 16550A
[    0.469298] printk: console [ttyS0] enabled
[    0.471380] [drm] radeon kernel modesetting enabled.
[    0.485925] loop: module loaded
[    0.488471] libphy: Fixed MDIO Bus: probed
[    0.489451] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    0.489685] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    0.490174] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.490643] ehci-pci: EHCI PCI platform driver
[    0.491028] ehci-platform: EHCI generic platform driver
[    0.491370] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.491692] ohci-pci: OHCI PCI platform driver
[    0.492034] ohci-platform: OHCI generic platform driver
[    0.493152] usbcore: registered new interface driver uas
[    0.493552] usbcore: registered new interface driver usb-storage
[    0.494733] mousedev: PS/2 mouse device common for all mice
[    0.496393] usbcore: registered new interface driver usbhid
[    0.496626] usbhid: USB HID core driver
[    0.498028] NET: Registered protocol family 10
[    0.504586] Segment Routing with IPv6
[    0.505050] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    0.507503] NET: Registered protocol family 17
[    0.509269] 9pnet: Installing 9P2000 support
[    0.509705] Key type dns_resolver registered
[    0.535001] Freeing unused kernel memory: 232K
[    0.539765] Run /init as init process
[    0.605611] init[1]: unhandled signal 11 code 0x2 at 0x0000003fe207a000
[    0.606050] CPU: 0 PID: 1 Comm: init Not tainted 5.8.0-rc5-00048-gf8456690ba8e-dirty #1
[    0.606598] epc: 0000003fe207a000 ra : 0000003fe207a000 sp : 0000003fffc86380
[    0.606860]  gp : 00000000000e8528 tp : 0000003fe20787d0 t0 : 0000003fe209a160
[    0.607159]  t1 : 0000003fe1fbde18 t2 : 00000000000e7910 s0 : 00000000000e92a0
[    0.607450]  s1 : 0000000000000000 a0 : 0000000000000011 a1 : 0000003fffc86380
[    0.607779]  a2 : 0000003fffc86400 a3 : 0000000000000000 a4 : 0000000000000000
[    0.608094]  a5 : 00000000000e92a0 a6 : 0000000000000000 a7 : 0000000000000104
[    0.608429]  s2 : 00000000000ea300 s3 : 0000000000000001 s4 : 00000000000e7e8c
[    0.608763]  s5 : 00000000000e92a0 s6 : 0000000000000000 s7 : ffffffffffffffff
[    0.609062]  s8 : 00000000000e96c8 s9 : 0000000000000000 s10: 00000000000c5f78
[    0.609360]  s11: 00000000000e1637 t3 : 00000000000a4e18 t4 : 0000000000000002
[    0.609663]  t5 : 0000000000000002 t6 : 0000000000003d38
[    0.609888] status: 0000000000004020 badaddr: 0000003fe207a000 cause: 000000000000000c
[    0.611295] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    0.611736] CPU: 0 PID: 1 Comm: init Not tainted 5.8.0-rc5-00048-gf8456690ba8e-dirty #1
[    0.612119] Call Trace:
[    0.612378] [<ffffffe000202712>] walk_stackframe+0x0/0xaa
[    0.612673] [<ffffffe0002029dc>] show_stack+0x2e/0x3a
[    0.612910] [<ffffffe000470166>] dump_stack+0x74/0x8e
[    0.613129] [<ffffffe0002087e2>] panic+0xf0/0x276
[    0.613337] [<ffffffe00020aab0>] do_exit+0x73c/0x776
[    0.613561] [<ffffffe00020b6b4>] do_group_exit+0x2a/0x7e
[    0.613793] [<ffffffe000213b74>] get_signal+0xcc/0x5a8
[    0.614016] [<ffffffe000201e10>] do_notify_resume+0x4a/0x340
[    0.614254] [<ffffffe00020130a>] ret_from_exception+0x0/0xc
[    0.615013] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
+ RET=124
+ set +x

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: Upstream binutils commit a87e1817a435dab6c6c042f9306497c9f13d4236 breaks building the RISC-V vDSO

[Maciej W. Rozycki]

On Tue, 16 Jun 2020, F?ng-ru? S?ng wrote:

> > > I suggested that GNU ld from 2.35 onwards disallows accepting ET_EXEC
> > > as input (https://sourceware.org/bugzilla/show_bug.cgi?id=26047 ). The
> > > error message is from the patch.
> > > Taking ET_EXEC files as input are usually errors.
> > >
> > > If we do need to take ET_EXEC as input, we can change e_type in the
> > > ELF header to make the file an ET_REL
> > >
> > > printf '\1' | dd of=${2} conv=notrunc bs=1 seek=16 status=none
> > > (See http://git.kernel.org/linus/90ceddcb495008ac8ba7a3dce297841efcd7d584 )
> >
> > Is there a convenient way to do this in a Makefile? The relevant rule
> > is:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/riscv/kernel/vdso/Makefile#n63
> >
> > I am not sure if that is strictly necessary, hence the initial email.
> >
> > Cheers,
> > Nathan
> 
> If I understand correctly,
> 
> $(obj)/vdso-dummy.o:
> ...
>         printf '\1' | dd of=$@ conv=notrunc bs=1 seek=16 status=none
> 
> should fix the issue. The change can be made along with the migration
> from $(CC) to $(LD). Hope an arch/riscv maintainer can do this.

 This is an LD bug in the fix for PR ld/26047, so let's not invent hacks 
to work it around.  I have filed PR ld/26288 and I'm currently verifying a 
fix along with a couple of test cases with the intent to have it all 
included with the upcoming binutils 2.35 release currently scheduled this 
coming Sat.

 Cf. <https://sourceware.org/bugzilla/show_bug.cgi?id=26288>.

  Maciej

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv