[Bug target/92207] [10 Regression] pr36449.C fails on arm after r277179

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92207

--- Comment #8 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
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 <impure_data>, bytes=134217732)
    at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2353
2353    in
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c
(gdb) 
Continuing.

Breakpoint 1, 0x00018bc0 in _malloc_r (reent_ptr=0x49570 <impure_data>, 
    bytes=<optimized out>)
    at
/tmp/7992549.tmpdir/aci-gcc-fsf/sources/newlib/newlib/libc/stdlib/mallocr.c:2592
2592    in
/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:      0x00000000
(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:      0x00000000

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).