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.
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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:
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
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,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.0
Summary|pr36449.C
