Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

[Kurt Roeckx]

found 691576 3.2.46-1+deb7u1
thanks

On Sat, Mar 09, 2013 at 03:35:33PM +0100, Stephan Schreiber wrote:
> 
> 
> The problem with GDB does no longer occur with Kernel 3.2.35-2. I
> don't have a clue why.
> A user has confimred that on the debian-i...@lists.debian.org list.

I'm seeing this on merulo:
$ uname -a
Linux merulo 3.2.0-4-mckinley #1 SMP Debian 3.2.46-1+deb7u1 ia64 GNU/Linux

ii  linux-image-3.2.0-4-mckinley 3.2.46-1+deb7u1   ia64 
Linux 3.2 for Itanium II


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

[Stephan Schreiber]

notfound 691576 src:linux/3.5.5-1~experimental.1
notfixed 691576 linux-image-3.0.0-2-mckinley/3.0.0-5
notfixed 691576 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
fixed 691576 3.2.35-2
thanks


The problem with GDB does no longer occur with Kernel 3.2.35-2. I  
don't have a clue why.

A user has confimred that on the debian-i...@lists.debian.org list.

I filed a new bug#702641 for the asm register contraints problem above.

Please could you simply close this bug?

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Processed (with 2 errors): Re: Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:linux
Bug #691576 [gdb] GDB stops with sigtrap at 0 address on ia64 wheezy
Bug reassigned from package 'gdb' to 'src:linux'.
No longer marked as found in versions 7.4.1.
Ignoring request to alter fixed versions of bug #691576 to the same values 
previously set
> affects -1 + gdb
Bug #691576 [src:linux] GDB stops with sigtrap at 0 address on ia64 wheezy
Added indication that 691576 affects gdb
> found -1 src:linux/3.2.23-1
Unknown command or malformed arguments to command.

> found -1 src:linux/3.5.5-1~experimental.1
Unknown command or malformed arguments to command.

> fixed -1 linux-image-3.0.0-2-mckinley/3.0.0-5
Bug #691576 [src:linux] GDB stops with sigtrap at 0 address on ia64 wheezy
The source linux-image-3.0.0-2-mckinley and version 3.0.0-5 do not appear to 
match any binary packages
Marked as fixed in versions linux-image-3.0.0-2-mckinley/3.0.0-5.
> fixed -1 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
Bug #691576 [src:linux] GDB stops with sigtrap at 0 address on ia64 wheezy
The source linux-image-3.1.0-rc7-mckinley and version 
3.1.0~rc7-1~experimental.1 do not appear to match any binary packages
Marked as fixed in versions 
linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1.
> found -1 linux-image-3.1.0-1-mckinley/3.1.1-1
Bug #691576 [src:linux] GDB stops with sigtrap at 0 address on ia64 wheezy
The source linux-image-3.1.0-1-mckinley and version 3.1.1-1 do not appear to 
match any binary packages
Marked as found in versions linux-image-3.1.0-1-mckinley/3.1.1-1.
> found -1 linux-image-3.1.0-1-mckinley/3.1.4-1
Bug #691576 [src:linux] GDB stops with sigtrap at 0 address on ia64 wheezy
The source linux-image-3.1.0-1-mckinley and version 3.1.4-1 do not appear to 
match any binary packages
Marked as found in versions linux-image-3.1.0-1-mckinley/3.1.4-1.

-- 
691576: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

[Samuel Bronson]

Control: reassign -1 src:linux
Control: affects -1 + gdb
Control: found -1 src:linux/3.2.23-1
Control: found -1 src:linux/3.5.5-1~experimental.1
Control: fixed -1 linux-image-3.0.0-2-mckinley/3.0.0-5
Control: fixed -1 linux-image-3.1.0-rc7-mckinley/3.1.0~rc7-1~experimental.1
Control: found -1 linux-image-3.1.0-1-mckinley/3.1.1-1
Control: found -1 linux-image-3.1.0-1-mckinley/3.1.4-1

Since this seems to actually be a bug in the kernel, I'm reassigning it
there.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

[Stephan Schreiber]

I tried some older Kernel versions in order to get more information  
about the regression.


Udeb and libudeb0 have been downgraded to version 161 in order to run  
older Kernels.



Kernel 3.0.0-2 (linux-image-3.0.0-2-mckinley_3.0.0-5_ia64.deb)
GDB 7.4.1 works

Kernel 3.1.0-rc7  
(linux-image-3.1.0-rc7-mckinley_3.1.0~rc7-1~experimental.1_ia64.deb)

GDB 7.4.1 works

Kernel 3.1.0-1 (linux-image-3.1.0-1-mckinley_3.1.1-1_ia64.deb)
GDB 7.4.1 doesn't work

Kernel 3.1.0-1 (linux-image-3.1.0-1-mckinley_3.1.4-1_ia64.deb)
GDB 7.4.1 doesn't work


If you read the changelog of linux-2.6, you realize that one  
difference between 3.1.0~rc7-1 and 3.1.1-1 is the used the GCC  
version: a change from 4.5 to 4.6.


This also explains the working Gentoo Kernel 3.3.8; it has been  
compiles with GCC 4.5.3.


I focused the Kernel 3.2.23 for the subsequent tests because it is the  
one in Wheezy. (Udev and libudev upgraded to the most recent versions  
in Wheezy.)


As you remember GDB 7.4.1 doesn't work on Kernel 3.2.23 - compiled  
with GCC 4.6.


I build Kernel 3.2.23 with GCC4.4. GDB 7.4.1 works on that Kernel! But  
don't be too excited, the bad news is coming soon.


That's quite interesting. Either a problem in some GCC versions or we  
have some source code in the Kernel which isn't portable in some way.


Emeric Maschine gave me the valuable hint on the Debian ia64 list that  
he have already seen some GDB trouble after a particular upstream  
patch in Kernel:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=37a9d912b24f

The result was Debian bug#659485  
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659485) and an  
upstream patch (https://bugzilla.kernel.org/show_bug.cgi?id=42757):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c76f39bddb84f93f70a5520d9253ec0317bec216


The source code which was modified by these patches attracted my  
attention immediately.
Here is the source code of Kernel 3.2.23; the register operand  
constraints of the assembly block are *wrong*.


File arch/ia64/include/asm/futex.h:

static inline int
futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
  u32 oldval, u32 newval)
{
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;

{
register unsigned long r8 __asm ("r8");
unsigned long prev;
__asm__ __volatile__(
"  mf;;\n"
"  mov %0=r0   \n"
"  mov ar.ccv=%4;; \n"
"[1:]  cmpxchg4.acq %1=[%2],%3,ar.ccv  \n"
"  .xdata4 \"__ex_table\", 1b-., 2f-.\n"
"[2:]"
: "=r" (r8), "=r" (prev)
: "r" (uaddr), "r" (newval),
  "rO" ((long) (unsigned) oldval)
: "memory");
*uval = prev;
return r8;
}
}



The list of output registers is
: "=r" (r8), "=r" (prev)
The constraint "=r" means that the GCC has to maintain that these vars  
are in registers and contain valid info when the program flow leaves  
the assembly block (output registers).
But "=r" also means that GCC can put them in registers that are used  
as input registers. Input registers are uaddr, newval, oldval on the  
example.

The second assembly instruction
"  mov %0=r0   \n"
is the first one which writes to a register; it sets %0 to 0. %0 means  
the first register operand; it is r8 here. (The r0 is read-only and  
always 0 on the Itanium; it can be used if an immediate zero value is  
needed.)
This instruction might overwrite one of the other registers which are  
still needed.
Whether it really happens depends on how GCC decides what registers it  
uses and how it optimizes the code.


The objdump utility can give us disassembly.
The futex_atomic_cmpxchg_inatomic() function is inline, so we have to  
look for a module that uses the funtion. This is the  
cmpxchg_futex_value_locked() function in

kernel/futex.c:

static int cmpxchg_futex_value_locked(u32 *curval, u32 __user *uaddr,
  u32 uval, u32 newval)
{
int ret;

pagefault_disable();
ret = futex_atomic_cmpxchg_inatomic(curval, uaddr, uval, newval);
pagefault_enable();

return ret;
}


Now the dissembly. At first from the Kernel package 3.2.23 which has  
been compiled with GCC 4.4, remeber this Kernel seemed to work:

objdump -d linux-3.2.23/debian/build/build_ia64_none_mckinley/kernel/futex.o

0230 :
 230:   0b 18 80 1b 18 21   [MMI]   adds r3=3168,r13;;
 236:   80 40 0d 00 42 00   adds r8=40,r3
 23c:   00 00 04 00  

Bug#691576: GDB stops with sigtrap at 0 address on ia64 wheezy

[Stephan Schreiber]

Package: gdb
Version: 7.4.1
Severity: serious


Dell PowerEdge 3250
2x Itanium Madison 1.5GHz 6M
4GB RAM


I realized that GDB doesn't work as it should.
When GDB should run *any* target application, it always stops with  
SIGTRAP 0x.

Example:


stephan@itanic:~$ gdb man
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
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-linux-gnu".
For bug reporting instructions, please see:
...
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.
0x in ?? ()
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x in ?? ()
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x in ?? ()
(gdb)



Debian Wheezy: Kernel 3.2.23, GDB 7.4.1 doesn't work
Debian Wheezy: Kernel 3.2.23, GDB 7.3 doesn't work
Debian Wheezy: with Kernel 3.5.5 (experimental), GDB 7.4.1 doesn't work
Debian Wheezy: with Kernel 3.5.5 (experimental), GDB 7.3 doesn't work
Debian Lenny:  Kernel 2.6.26, a 'debootstrapped' Wheezy userland, GDB  
7.4.1 *works*

Gentoo:Kernel 3.3.8,  GDB 7.3.1 works

I'm surprised that GDB 7.4.1 works on Lenny in the chroot'd Wheezy  
environment.

Please also note that the problem doesn't occur on Gentoo ia64.

In my opinion, it points to the Debian Kernel somehow...

Stephan


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org