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

Re: GDB problem on Debian ia64



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 <baggett.patrick@gmail.com> 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 <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: