Re: GDB problem on Debian ia64
Patrick,
I'm currently running stock Debian Testing kernel on my system.
accept4 syscall has been reported upstream, at least in 3.0 and 3.2
branches [1].
Émeric
[1] http://marc.info/?l=linux-ia64&m=133720558502738&w=2
2012/10/30 Patrick Baggett <baggett.patrick@gmail.com>:
> 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
Reply to: