On 15.01.2025 19:02, Mikulas Patocka wrote: > On Tue, 14 Jan 2025, Sami Tolvanen wrote: >> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: >>> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when >>> a module is loaded. The warnings are caused by the fact that the >>> .gnu.linkonce.this_module section is not aligned to the appropriate >>> boundary. If I dump the module content with "objdump -h configs.ko", I get >>> this. Note that the .gnu.linkonce.this_module has "File off 000042d2" and >>> "Algn 2**4". >>> >>> On x86-64, the same misalignment can be seen, but it doesn't cause >>> warnings because unaligned pointers are handled in hardware. >>> >>> This seems to be a bug in the linker, because when I compile an old kernel >>> with a new linker, I also get the misalignment. Do you have an idea how to >>> work around this bug? >> >> Does explicitly specifying section alignment in the module linker >> script fix this by any chance? >> >>> kernel-6.12.9, binutils from Debian ports: >>> [...] >>> kernel 6.10, older binutils: >> >> Which exact versions of binutils were used here? I don't see the >> alignment issue with binutils 2.42 on either x86_64 or parisc64, so I >> assume you're testing with something newer? >> >> $ hppa64-linux-gnu-ld.bfd --version >> GNU ld (GNU Binutils for Debian) 2.42.50.20240625 >> >> $ hppa64-linux-gnu-objdump -h configs.ko | grep -E '(format|this_module)' >> configs.ko: file format elf64-hppa-linux >> 17 .gnu.linkonce.this_module 00000300 0000000000000000 >> 0000000000000000 00005c50 2**4 >> >> Sami > > Hi > > I use version "GNU ld (GNU Binutils for Debian) 2.43.50.20250108". > > It was broken in the commit 1f1b5e506bf0d9bffef8525eb9bee19646713eb6 in > the binutils-gdb git and partially fixed in the commit > d41df13ab36b224a622c0bdf28a96a0dee79db77 - the section is still not > aligned at their specified boundary (16), but at least it is aligned on 8 > bytes, which avoids the warnings. When you say "broken", can you please explain what it is that is _broken_? Things have changed, yes, but the produced ELF is - afaict - still within spec. The "partial fix" as you call it wasn't really a fix, but a band-aid for some broken consumers of ELF. Plus modpost, being one such example, was supposedly corrected already (Linux commit 8fe1a63d3d99). Said "partial fix" was also confirmed to help modpost [1] - are you saying that wasn't quite true? Jan [1] https://sourceware.org/bugzilla/show_bug.cgi?id=32435 > With binutils from git, I no longer see warnings when loading modules, but > there are warnings in modpost when compiling the kernel: > > 2025-01-15T17:09:29.408347+01:00 phoebe kernel: handle_unaligned: 2165 callbacks suppressed > 2025-01-15T17:09:29.408433+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd5 at ip 0x015d03 (iir 0xf381086) > 2025-01-15T17:09:29.602490+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd1 at ip 0x015d07 (iir 0xf301088) > 2025-01-15T17:09:29.700610+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096be9 at ip 0x015d0b (iir 0x4b3c0040) > 2025-01-15T17:09:29.700653+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bdd at ip 0x015d0f (iir 0x4b240028) > 2025-01-15T17:09:29.897081+01:00 phoebe kernel: modpost(9283): unaligned access to 0xf9096bd9 at ip 0x015d13 (iir 0x4b270020) > > The affected instructions are in the function do_pci_entry: > 15d00: 0f 38 10 86 ldw c(r25),r6 > 15d04: 0f 30 10 88 ldw 8(r25),r8 > 15d08: 4b 3c 00 40 ldw 20(r25),ret0 > 15d0c: 4b 24 00 28 ldw 14(r25),r4 > 15d10: 4b 27 00 20 ldw 10(r25),r7 > 15d14: 0f 28 10 89 ldw 4(r25),r9 > 15d18: 82 93 20 e0 cmpb,= r19,r20,15d90 <do_pci_entry+0xcc> > 15d1c: 0f 20 10 8a ldw 0(r25),r10 > they happen in the expansion of the macro DEF_FIELD. > > Mikulas
