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]

Re: GNU Binutils 2.33.1 has been released.


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]