search for: xgdb

I've been investigating a case with the XCore target (which doesn't use FastISel) where the DWARF line number emitted at -O0 results in the xgdb visiting source lines in an unexpected order. I've tracked down the problem to the handling of DebugLocs in the selection DAG, in the getNode method shown bellow. It first tries to find if a similar node already exists in order to use that one otherwise it creates a new one. The problem of t...

On Sep 13, 2011, at 4:01 AM, Kyriakos Georgiou wrote: > I've been investigating a case with the XCore target (which doesn't use > FastISel) where the DWARF line number emitted at -O0 results in the xgdb > visiting source lines in an unexpected order. I've tracked down the > problem to the handling of DebugLocs in the selection DAG, in the getNode > method shown bellow. > > It first tries to find if a similar node already exists in order to use that one > otherwise it creat...

On 13/09/11 17:40, Devang Patel wrote: > On Sep 13, 2011, at 4:01 AM, Kyriakos Georgiou wrote: >> I've been investigating a case with the XCore target (which doesn't use >> FastISel) where the DWARF line number emitted at -O0 results in the xgdb >> visiting source lines in an unexpected order. I've tracked down the >> problem to the handling of DebugLocs in the selection DAG, in the getNode >> method shown bellow. >> >> It first tries to find if a similar node already exists in order to use that one >&g...

...from /lib/libnss_nisplus.so.2...done. Reading symbols from /lib/libnss_nis.so.2...done. 0x400cb8e9 in __wait4 () from /lib/libc.so.6 (gdb) bt #0 0x400cb8e9 in __wait4 () from /lib/libc.so.6 #1 0x4012a1ec in ?? () from /lib/libc.so.6 #2 0x4007acec in __libc_system ( line=0x81cc8e8 "/tmp/xgdb /usr/sbin/smbd 20416") at ../sysdeps/posix/system.c:136 #3 0x8110677 in chroot () #4 0x80ffd0e in chroot () #5 0x80ffd5c in chroot () #6 0x40058c68 in __restore () at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127 #7 0x810ba90 in chroot () #8 0x8087521 in chroot () #9 0x8122db8...