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 <baggett.patr...@gmail.com > 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 < > baggett.patr...@gmail.com> 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 < >> emeric.masch...@gmail.com> 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 <i...@fs-driver.org>: >>> > 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 debian-ia64-requ...@lists.debian.org >>> > with a subject of "unsubscribe". Trouble? Contact >>> > listmas...@lists.debian.org >>> > Archive: >>> > >>> http://lists.debian.org/20121027131939.horde.yxy-asl8999qi8nlg4tx...@webmail.df.eu >>> > >>> >>> >>> -- >>> To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org >>> with a subject of "unsubscribe". Trouble? Contact >>> listmas...@lists.debian.org >>> Archive: >>> http://lists.debian.org/caa9xbm6l6fu114t6tkmzgfcivuxum8bion9v2aktvdmciud...@mail.gmail.com >>> >>> >> >