http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835

Thorsten Glaser <tg at mirbsd dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|m68k-linux                  |

--- Comment #3 from Thorsten Glaser <tg at mirbsd dot org> 2011-04-30 22:16:10 
UTC ---
Actually, the backtrace is bogus. The problem lies here:

hostparm___elabs:
.LFB0:
        .file 1 "../../src/gcc/ada/hostparm.ads"
[…]
        move.l %d0,hostparm__Tnormalized_cwdS___SIZE_A_UNIT
        move.l %d0,-(%sp)   
        .cfi_escape 0x2e,0x4
        jsr __gnat_malloc
        move.l %a0,%d2
        move.l hostparm__Tnormalized_cwdS___SIZE_A_UNIT,-(%sp)
        move.l hostparm__R6s,-(%sp)
0x8013707c  move.l %a0,-(%sp)   
        .cfi_escape 0x2e,0xc
0x8013707e  jsr memcpy
0x80137084  move.l %d2,hostparm__normalized_cwd
        lea (16,%sp),%sp
        .loc 1 38 0
        movem.l -24(%fp),#252
        unlk %fp
        rts
        .cfi_endproc

The call to memcpy above SIGSEGVs. Upon entering memcpy@plt, the
stack looks as follows:

0xefcdaab0:     0x80137084      0x8018668a      0x80a2688e      0x00000002
                ret addr        dst             src             len

(gdb) x 0x80a2688e
0x80a2688e <system__secondary_stack__chunk+24>: 0x2e2f0000
(gdb) x 0x8018668a
0x8018668a <system__soft_links__abort_undefer_nt>:      0x4e560000

tg@zigo:~/Xg/gcc-4.4-4.4.6/b68k $ nm gcc/gnat1 | fgrep -we
system__secondary_stack__chunk -e system__soft_links>
80a26876 b system__secondary_stack__chunk
8018668a T system__soft_links__abort_undefer_nt

So basically, this tries to overwrite space at T (.text segment).
__gnat_malloc is apparently assumed to return in a0…

… grepping gives:

ada/socket.c:extern void *__gnat_malloc32 (__SIZE_TYPE__);
ada/raise.h:extern void *__gnat_malloc          (__SIZE_TYPE__);
ada/i-cstrin.adb:   pragma Import (C, Memory_Alloc, "__gnat_malloc");
ada/s-memory.ads:   pragma Export (C, Alloc,   "__gnat_malloc");

I believe we may have our culprit, considering m68k return value locations.
Phew!

Reply via email to