[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #11 from Richard Earnshaw --- BTW, it looks like the libgloss implementation of the syscall API and startup code has had this change since 2015.
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #10 from Richard Earnshaw --- A bit more trace from the gdb session as evidence. (gdb) p HeapLimit 'HeapLimit' has unknown type; cast it to its declared type (gdb) p $1 = ( *) 0x48f78 (gdb) x/x $1 0x48f78:0x0804a000 (gdb) p __heap_limit No symbol "__heap_limit" in current context.
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Earnshaw --- This is a bug in newlib-3.1.0 that should have been fixed in trunk with https://sourceware.org/ml/newlib/2019/msg00413.html So closing as invalid.
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
--- Comment #8 from Richard Earnshaw ---
I'm 95%+ sure that this is a problem with qemu+newlib with the latter not
handling out-of-memory correctly. If I run the good program to the same
instruction that faults in the bad program, I see:
Breakpoint 2, _malloc_r (reent_ptr=0x49570 , bytes=134217732)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2353
2353in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb)
Continuing.
Breakpoint 1, 0x00018bc0 in _malloc_r (reent_ptr=0x49570 ,
bytes=)
at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2592
2592in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb) x/i $pc
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
(gdb) info reg r2
r2 0x804aa40 134523456
(gdb) x/x $r2
0x804aa40: 0x
(gdb) x/x 0x805b000
0x805b000: Cannot access memory at address 0x805b000
So the location to be written exists and is the last mapped page of memory.
In the 'bad' program, I see
(gdb) x/i $pc
=> 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4]
(gdb) p $r2
$14 = 134522216
(gdb) p *$4
$15 = {prev_size = 0, size = 0, fd = 0x804a568, bk = 0x494c0 <__malloc_av_>}
(gdb) p/x $r2
$16 = 0x804a568
(gdb) x/i $r2
0x804a568: Cannot access memory at address 0x804a568
(gdb) info reg pc
pc 0x18bc0 0x18bc0 <_malloc_r+1092>
(gdb) x/x 0x8049ffc
0x8049ffc: 0x
that is the location being written is not mapped (but the page before is), this
is despite the address being lower than in the 'good' version.
Note that the difference between the two addresses being written in the two
programs is exactly the same as the difference between the VMAs of the .bss
segment in the executable files.
Consequently, I don't think this is a bug that has been introduced by this
patch, but is most likely a latent issue in either qemu or newlib (or perhaps a
combination of the two).
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #7 from Christophe Lyon --- When single-stepping in the r277178 executable, the final => 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4] succeeds and (gdb) p /x $r2 $2 = 0x804aa40
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #6 from Christophe Lyon --- In particular, the execution continues after the last block dumped by qemu: 0x00018e40: e5974008 ldr r4, [r7, #8] 0x00018e44: e0898008 add r8, sb, r8 0x00018e48: e3888001 orr r8, r8, #1 0x00018e4c: e5848004 str r8, [r4, #4] 0x00018e50: ea14 b#0x18aa8 I set a breakpoint at 0x00018e40, then single-step until the crash: => 0x18e40 <_malloc_r+1732>:ldr r4, [r7, #8] => 0x18e44 <_malloc_r+1736>:add r8, r9, r8 => 0x18e48 <_malloc_r+1740>:orr r8, r8, #1 => 0x18e4c <_malloc_r+1744>:str r8, [r4, #4] => 0x18e50 <_malloc_r+1748>:b 0x18aa8 <_malloc_r+812> => 0x18aa8 <_malloc_r+812>: ldr r3, [r10, #44] ; 0x2c => 0x18aac <_malloc_r+816>: cmp r3, r1 => 0x18ab0 <_malloc_r+820>: ldr r3, [r10, #48] ; 0x30 => 0x18ab4 <_malloc_r+824>: strcc r1, [r10, #44] ; 0x2c => 0x18ab8 <_malloc_r+828>: cmp r3, r1 => 0x18abc <_malloc_r+832>: strcc r1, [r10, #48] ; 0x30 => 0x18ac0 <_malloc_r+836>: bic r8, r8, #3 => 0x18ac4 <_malloc_r+840>: sub r3, r8, r5 => 0x18ac8 <_malloc_r+844>: cmp r3, #15 => 0x18acc <_malloc_r+848>: movgt r2, #0 => 0x18ad0 <_malloc_r+852>: movle r2, #1 => 0x18ad4 <_malloc_r+856>: cmp r5, r8 => 0x18ad8 <_malloc_r+860>: orrhi r2, r2, #1 => 0x18adc <_malloc_r+864>: cmp r2, #0 => 0x18ae0 <_malloc_r+868>: beq 0x18ba4 <_malloc_r+1064> => 0x18ba4 <_malloc_r+1064>:add r2, r4, r5 => 0x18ba8 <_malloc_r+1068>:orr r3, r3, #1 => 0x18bac <_malloc_r+1072>:orr r5, r5, #1 => 0x18bb0 <_malloc_r+1076>:str r5, [r4, #4] => 0x18bb4 <_malloc_r+1080>:mov r0, r6 => 0x18bb8 <_malloc_r+1084>:str r2, [r7, #8] => 0x18bbc <_malloc_r+1088>:add r4, r4, #8 => 0x18bc0 <_malloc_r+1092>:str r3, [r2, #4] (gdb) p /x $r2 $1 = 0x804a568 (gdb) si Program received signal SIGSEGV, Segmentation fault. 0x00018bc0 in _malloc_r (reent_ptr=0x49098 , bytes=) at /tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2592 2592in /tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 --- Comment #5 from Richard Earnshaw --- Apart from the addresses used, the traces are identical right up until the latter version crashes. The testcase tries to allocate 128Mb+4bytes of memory, so my suspicion is that this is a test that needs more memory in the simulation. Why this patch triggers this failure I'm not sure.
[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0 Summary|pr36449.C fails on arm |[10 Regression] pr36449.C |after r277179 |fails on arm after r277179
