GDB shows fake short arguments (?????)

GDB shows fake short arguments (?????)

[Creep]

Hello. I was debugging a program and a weird thing occured.
I'm not actually sure if this is a bug or a normal behavior :S.
I just can't quite imagine such thing could be unnoticed.

I experienced it on:
FreeBSD mistress 4.7-STABLE FreeBSD 4.7-STABLE #0: Sun Jan 26 01:49:59 CET 2003
     root@mistress:/usr/obj/usr/src/sys/RED  i386
creep[~]$ sysctl hw |head -9
hw.machine: i386
hw.model: Intel Celeron
hw.ncpu: 1
hw.byteorder: 1234
hw.physmem: 128905216
hw.usermem: 95436800
hw.pagesize: 4096
hw.floatingpoint: 1
hw.machine_arch: i386
creep[~]$

and slackware 8.0 with 2.4.x kernel
[also a i386]

$ gdb --version
GNU gdb 4.18 (FreeBSD)
(...)
This GDB was configured as "i386-unknown-freebsd".
$ gcc --version
2.95.4

I guess this code is correct [-ansi -pedantic -Wall gives no output]
--------------------------
#include <stdio.h>
int f(short x)
{
	printf("x %d\n",x);
	return 0;
}
int main()
{
	f(5);
	return 0;
}
-------------------------
compiled with

creep[~]$ gcc -ggdb -o idiotyzm idiotyzm.c
creep[~]$ gdb ./idiotyzm
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called a
t /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dwarf2read.c lin
e 3049 in dwarf2_read_section
(gdb) break f
Breakpoint 1 at 0x80484b6: file idiotyzm.c, line 3.
(gdb) run
Starting program: /usr/home/creep/./idiotyzm
Breakpoint 1, f (x=10245) at idiotyzm.c:3
-------------------^^^^^- ?????

3       {
(gdb) bt
#0  f (x=10245) at idiotyzm.c:3
---------^^^^^ ?
#1  0x80484ec in main () at idiotyzm.c:9
(gdb) p x
$1 = 10245
(gdb) step
4               printf("x %d\n",x);
(gdb) p x
$2 = 5
(gdb) step
x 5
5               return 0;
(gdb) bt
#0  f (x=5) at idiotyzm.c:5
#1  0x80484ec in main () at idiotyzm.c:9
(gdb)
--------
When debugging program, such info can be a little bit confusing.
changing short to int fixes the issue.

What is interesting, when i launched gdb under script(1) program,
the x value printed in gdb was 0 instead of 10245.
Under virtual terminal from login shell it always gives 10245,
when i run bash from login shell it gives 10245, running zsh[my primary shell]
and then gdb from it gives 0 (just like script(1) does)

Some more info:
---
(gdb) break f
Breakpoint 1 at 0x80484b6: file idiotyzm.c, line 3.
(gdb) run
Starting program: /usr/home/creep/./idiotyzm
Breakpoint 1, f (x=10245) at idiotyzm.c:3
3       {
(gdb) x/2 &x
0xbfbffa4e:     0xfa702805      0x84ecbfbf
(gdb) step
4               printf("x %d\n",x);
(gdb) p x
$1 = 5
(gdb) x/2 &x
0xbfbffa4e:     0xfa700005      0x84ecbfbf
(gdb)
------

That was for FreeBSD mashine,
for linux it gives:
Breakpoint 1, f (x=-16385) at idiotyzm.c:3

Machine is:
creep@daedalus:~$ uname -a
Linux daedalus 2.2.24-rc2 #3 SMP Wed Dec 25 22:28:00 CET 2002 i686 unknown
creep@daedalus:~$ gcc --version
2.95.3
creep@daedalus:~$ gdb --version
GNU gdb 5.0
(...)
This GDB was configured as "i386-slackware-linux".
creep@daedalus:~$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 3
cpu MHz         : 735.000
cache size      : 256 KB
(....)

On SunOS it works fine.
# uname -a
SunOS lew 5.7 Generic_106541-22 sun4u sparc SUNW,Ultra-4
# gcc --version
egcs-2.91.66
# gdb --version
GNU gdb 4.18

Any ideas?

c.

Re: GDB shows fake short arguments (?????)

[Daniel Jacobowitz]

On Sun, Jan 26, 2003 at 10:45:13PM +0100, Creep wrote:
> 
> Hello. I was debugging a program and a weird thing occured.
> I'm not actually sure if this is a bug or a normal behavior :S.
> I just can't quite imagine such thing could be unnoticed.

> # gdb --version
> GNU gdb 4.18
> 
> Any ideas?

It's just a debug info problem with the compiler you're using; GDB
stops too early in the function.  If you use GCC 3.2 you'll probably
get better results.  If you're debugging unoptimized code and you don't
want to switch compilers, GDB 5.3 contains a workaround which may help.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer