This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, Le 05/12/2019 à 03:52, Alan Modra a écrit : > On Tue, Dec 03, 2019 at 09:59:48PM +0100, Romain Naour wrote: >> Hi, >> >> Le lun. 2 déc. 2019 à 05:17, Alan Modra <amodra@gmail.com> a écrit : >> >>> On Sat, Nov 30, 2019 at 12:05:55PM +0100, Romain Naour wrote: >>>> The system doesn't boot but if It I revert the commit [1], the system >>> boot. >>>> >>>> Since it's a commit not related to sh4, it's weird that is the only >>> affected >>>> architecture. >>>> >>>> [1] >>>> >>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e >>> >>> Difference in vmlinux linker map file (I added -Map vmlinux.map to ld >>> flags) between 2.33.1 and 2.33.1 with [1] reverted is: >>> >>> 0x000000008c3ff5b0 0x11 lib/timerqueue.o >>> *fill* 0x000000008c3ff5c1 0x3 >>> .rodata.str1.4 >>> - 0x000000008c3ff5c4 0x13f lib/vsprintf.o >>> + 0x000000008c3ff5c4 0x140 lib/vsprintf.o >>> 0x1bf (size before relaxing) >>> - 0x000000008c3ff703 __start_ro_after_init = >>> . >>> + 0x000000008c3ff704 __start_ro_after_init = >>> . >>> *(.data..ro_after_init) >>> - *fill* 0x000000008c3ff703 0x1 >>> .data..ro_after_init >>> 0x000000008c3ff704 0x1c kernel/ksysfs.o >>> .data..ro_after_init >>> >>> I believe there is a kernel bug in handling of __start_ro_after_init. >>> If you take a look at kmemleak.c:scan_block you'll see that the start >>> address is aligned up to a pointer sized boundary. That's fine, but >>> scan_large_block calls scan_block repeatedly without first aligning >>> the start address, with the result that one word is missed from the >>> scan every MAX_SCAN_SIZE bytes when __start_ro_after_init is not >>> aligned. The following untested patch should fix this. >>> Alternatively, align __start_ro_after_init in the script. >>> >>> --- mm/kmemleak.c~ 2019-01-17 07:34:38.000000000 +1030 >>> +++ mm/kmemleak.c 2019-12-02 14:33:20.997174278 +1030 >>> @@ -1377,6 +1377,7 @@ static void scan_large_block(void *start >>> { >>> void *next; >>> >>> + start = PTR_ALIGN(start, BYTES_PER_POINTER); >>> >> >> scan_large_block is only user when CONFIG_SMP is enabled but it is not in >> the kernel config I'm using >> >> I tested with this patch but the kernel doesn't boot. >> > > I built a kernel using your buildroot and binutils-2.33.1 with and > without patch [1]. cmp -l shows 41 bytes different in vmlinux. These > are in the .notes section (build id), .rodata (date and time string), > .data (date and time string again), and .symtab (the value of > __start_ro_after_init).> > Yet you claim that a kernel built with binutils-2.33.1 with patch > [1] reverted works. Which very likely means your description of how > to reproduce the problem is missing some critical detail. Have you > compared vmlinux binaries for differences? Yes, but I can't explain the difference. Here is the diff between the output of readelf on two vmlinux (the result is slightly different, only sections comment, symtab, strtab and shstrtab are changed). Here is the defconfig I used for both build, using the same Buildroot version. The only change is the Binutils patch reverting [1]. BR2_sh=y BR2_GLOBAL_PATCH_DIR="board/qemu/sh4-r2d/patches" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_19=y BR2_BINUTILS_VERSION_2_33_X=y BR2_GCC_VERSION_9_X=y BR2_TARGET_GENERIC_GETTY_PORT="ttySC1" BR2_SYSTEM_DHCP="eth0" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.19.16" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/sh4-r2d/linux.config" BR2_LINUX_KERNEL_ZIMAGE=y BR2_TARGET_ROOTFS_EXT2=y # BR2_TARGET_ROOTFS_TAR is not set Can you compare with your defconfig (use make savedefconfig). Check if binutils 2.33.1 has been used to build the toolchain. Have you tried to run the system using Qemu and the command line provided previously? Otherwise, I don't understand why you can't reproduce the issue. Best regards, Romain > >> >> while (start < end) { >>> next = min(start + MAX_SCAN_SIZE, end); >>> scan_block(start, next, NULL); >>> >
Attachment:
sh4-diff.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |