[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GDB problem on Debian ia64



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.patrick@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.patrick@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.maschino@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 <info@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> Archive:
> [🔎] 20121027131939.Horde.YXy-AsL8999Qi8NLG4TXsMA@webmail.df.eu" target="_blank">http://lists.debian.org/[🔎] 20121027131939.Horde.YXy-AsL8999Qi8NLG4TXsMA@webmail.df.eu
>


--
To UNSUBSCRIBE, email to debian-ia64-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] CAA9xbM6L6FU114t6tkMZgFciVUxUm8biOn9V2aKtvdMciuDQBA@mail.gmail.com" target="_blank">http://lists.debian.org/[🔎] CAA9xbM6L6FU114t6tkMZgFciVUxUm8biOn9V2aKtvdMciuDQBA@mail.gmail.com





Reply to: