https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #107 from C. Heide <cameron.heide at betasystems dot com> --- Thanks for the tips; I don't do a lot of assembly-level debugging in GDB. It looks like it fails almost immediately upon entering the remove function: > Breakpoint 1, variable_hasher::remove (var=0x0) at > /build_area_local/ntmake/gcc-8.3.0.ia64/gcc/var-tracking.c:507 > 507 variable_htab_free (var); > (gdb) disass $pc-32,$pc+32 > Dump of assembler code from 0x6d777a1 to 0x6d777e1: > 0x0000000006d777a1 <variable_hasher::remove(variable*)+1>: > mov r35=r12 > 0x0000000006d777a2 <variable_hasher::remove(variable*)+2>: > adds r12=-16,r12 > 0x0000000006d777b0 <variable_hasher::remove(variable*)+16>: [MII] > nop.m 0x0 > 0x0000000006d777b1 <variable_hasher::remove(variable*)+17>: > mov r33=b0 > 0x0000000006d777b2 <variable_hasher::remove(variable*)+18>: > mov r36=r1;; > 0x0000000006d777c0 <variable_hasher::remove(variable*)+32>: [MMB] > st4 [r35]=r32 > => 0x0000000006d777c1 <variable_hasher::remove(variable*)+33>: > ld4 r37=[r35] > 0x0000000006d777c2 <variable_hasher::remove(variable*)+34>: > br.call.sptk.many b0=0x7a70e90 > 0x0000000006d777d0 <variable_hasher::remove(variable*)+48>: [MII] > mov r1=r36 > 0x0000000006d777d1 <variable_hasher::remove(variable*)+49>: > nop.i 0x0;; > 0x0000000006d777d2 <variable_hasher::remove(variable*)+50>: > mov.i ar.pfs=r34 > 0x0000000006d777e0 <variable_hasher::remove(variable*)+64>: [MII] > nop.m 0x0 > End of assembler dump. > (gdb) stepi > 0x0000000006d777c2 507 variable_htab_free (var); > (gdb) stepi > warning: error while checking for dld breakpoint: Cannot access memory at > address 0x7a70e90 > 0x0000000007a70e90 in ?? () > (gdb) stepi > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000007a70e90 in ?? () where that address in the br.call.sptk.many opcode doesn't correspond to anything valid. If I disassemble the var-tracking.o file used in the build, this block looks like: > 00000000 <_ZN15variable_hasher6removeEP8variable>: > 0: 00 10 19 0a 80 05 [MII] alloc r34=ar.pfs,6,5,0 > 6: 30 02 30 00 42 80 mov r35=r12 > c: 01 67 fc 8c adds r12=-16,r12 > 10: 01 00 00 00 01 00 [MII] nop.m 0x0 > 16: 10 02 00 62 00 80 mov r33=b0 > 1c: 04 08 00 84 mov r36=r1;; > 20: 18 00 80 46 90 11 [MMB] st4 [r35]=r32 > 26: 50 02 8c 20 20 00 ld4 r37=[r35] > 2c: 08 00 00 50 br.call.sptk.many b0=20 > <_ZN15variable_hasher6removeEP8variable+0x20> which feels valid? (I know near-zilch about ia64 assembly.) And for comparison this is the raw bytecode for this bundle as seen in the debugger: > (gdb) x/16xb 0x0000000006d777c0 > 0x6d777c0 <variable_hasher::remove(variable*)+32>: 0x18 0x00 0x80 > 0x46 0x90 0x11 0x50 0x02 > 0x6d777c8 <variable_hasher::remove(variable*)+40>: 0x8c 0x20 0x20 > 0x00 0xd8 0x96 0xcf 0x50 Is it back to being some kind of linker problem with relocations or such?
