And finally, I just built GDB 7.5 from source and I get the same issue: figgles@itanic:~/src/build-gdb/gdb$ ./gdb /usr/bin/man GNU gdb (GDB) 7.5 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "ia64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/man...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/man
Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000000000 in ?? () (gdb) ----- Dang. Patrick On Tue, Oct 30, 2012 at 10:12 AM, Patrick Baggett <[email protected] > wrote: > Also odd -- when I use strace on a "Hello World" program, I get this: > > figgles@itanic:~$ strace ./test > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > restart_syscall(<... resuming interrupted call ...>) = 0 > test > restart_syscall(<... resuming interrupted call ...>) = 0 > > --- > > Same program on a Raspberry Pi (ARMv6 CPU running Debian derivative): > > figgles@raspbian:~$ strace ./test > execve("./test", ["./test"], [/* 15 vars */]) = 0 > brk(0) = 0xdad000 > uname({sys="Linux", node="raspbian", ...}) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x4006f000 > access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=23745, ...}) = 0 > mmap2(NULL, 23745, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40084000 > close(3) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY) = 3 > read(3, > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210y\1\0004\0\0\0"..., 512) > = 512 > lseek(3, 1186592, SEEK_SET) = 1186592 > read(3, > "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., > 1360) = 1360 > lseek(3, 1186156, SEEK_SET) = 1186156 > read(3, > "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 47) = 47 > fstat64(3, {st_mode=S_IFREG|0755, st_size=1187952, ...}) = 0 > mmap2(NULL, 1230120, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) > = 0x400ed000 > mprotect(0x4020c000, 32768, PROT_NONE) = 0 > mmap2(0x40214000, 12288, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x11f) = 0x40214000 > mmap2(0x40217000, 9512, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40217000 > close(3) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x40071000 > set_tls(0x40070c00, 0x400712d8, 0x40078048, 0x40070c00, 0x40078048) = 0 > mprotect(0x40214000, 8192, PROT_READ) = 0 > mprotect(0x40077000, 4096, PROT_READ) = 0 > munmap(0x40084000, 23745) = 0 > fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x40080000 > write(1, "test\n", 5test > ) = 5 > exit_group(5) = ? > > > --- > OK, so looking a bit more like a kernel issue... > > Émeric, > > Are there any other kernel patches you applied to your machine that aren't > upstream? > > Patrick > > On Tue, Oct 30, 2012 at 10:02 AM, Patrick Baggett < > [email protected]> wrote: > >> Also, in arch/ia64/kernel/entry.S, I see >> >> data8 sys_setns // 1330 >> data8 sys_sendmmsg >> data8 sys_process_vm_readv >> data8 sys_process_vm_writev >> data8 sys_accept4 >> >> So it appears that the accept4() system call is definitely present in >> upstream -- but it still doesn't work. :( >> >> Patrick >> >> On Tue, Oct 30, 2012 at 9:21 AM, Patrick Baggett < >> [email protected]> wrote: >> >>> Stephan / Émeric, >>> >>> I compiled Linux 3.7.0-rc3 and installed GDB 7.4.1-3 (sid) -- doing "gdb >>> man" hits a breakpoint at 0x0000000000000000 just like he described. I'm >>> not sure if it is a kernel thing -- I just compiled mine from Linus's git >>> repository last night. I don't mind doing a little spelunking into the >>> kernel code though -- you think it might have to do with the accept4() >>> syscall? Any other hints? (For a second, I was about to write, "let's just >>> run GDB in GDB and then we can..." -- doh). >>> >>> Patrick >>> >>> >>> On Mon, Oct 29, 2012 at 3:11 PM, Émeric Maschino < >>> [email protected]> wrote: >>> >>>> Hi Stephan, >>>> >>>> This vaguely reminds me something... Yes, back in February, while I >>>> was still chasing what in the end was missing accept4 syscall, I >>>> experienced a similar issue >>>> (http://lists.debian.org/debian-ia64/2012/01/msg00016.html). From this >>>> post, this was with linux-image-3.1.0-1-mckinley_3.1.8-2_ia64.deb >>>> Debian kernel. I don't remember the GDB version though (probably the >>>> one in Testing repository at this time) and I no more have the GDB >>>> core dump I'm talking about in this post :-( >>>> >>>> Kernel image and GDB currently in Testing repository >>>> (linux-image-mckinley-3.2+45 and gdb-7.4.1-3) work fine as I've just >>>> updated bug #642750 >>>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750) using such a >>>> configuration. Looking at my aptitude logs, gdb-7.4.1-1.1 was working >>>> fine too. >>>> >>>> Hope this helps, >>>> >>>> Émeric >>>> >>>> >>>> 2012/10/27 Stephan Schreiber <[email protected]>: >>>> > Hello to all, >>>> > >>>> > I just issued the Debian bugreport 691576 >>>> > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576). >>>> > >>>> > Did you also experience the problem? Do you know more about that, for >>>> > example, working or failing combinations of GDB versions/Debian >>>> Kernels on >>>> > ia64? >>>> > >>>> > Thanks in advance. >>>> > >>>> > Stephan Schreiber >>>> > >>>> > >>>> > >>>> > -- >>>> > To UNSUBSCRIBE, email to [email protected] >>>> > with a subject of "unsubscribe". Trouble? Contact >>>> > [email protected] >>>> > Archive: >>>> > >>>> http://lists.debian.org/[email protected] >>>> > >>>> >>>> >>>> -- >>>> To UNSUBSCRIBE, email to [email protected] >>>> with a subject of "unsubscribe". Trouble? Contact >>>> [email protected] >>>> Archive: >>>> http://lists.debian.org/caa9xbm6l6fu114t6tkmzgfcivuxum8bion9v2aktvdmciud...@mail.gmail.com >>>> >>>> >>> >> >
