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
>>>
>>>
>>
>
