Re: [PATCH] i386_stab_reg_to_regnum (4 <-> 5, ebp <-> esp)

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Fri, 2 Apr 2004 17:15:51 -0600 (CST)
> From: Brian Ford <ford@vss.fsi.com>
> 
> Ok, I'm trying to find a simple step-by-step.

Thank you.

> As a quick test, does a simple "bt" for a DWARF 2 compiled program stop at
> main, or run off infinately?

It stops at main.  Here's a session transcript, using the test
program from the message you referred to:

> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00025.html

and using a GDB snapshot from about a month ago:

D:\usr\djgpp\tmp>\gnu\gdb-0221\gdb\gdb ./fpregs
GNU gdb 20040221
Copyright 2004 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 "--host=i386-pc-msdosdjgpp --target=djgpp"...
(gdb) b fpregs.c:14
Breakpoint 2 at 0x16f4: file fpregs.c, line 14.
(gdb) r 10

Starting program: d:/usr/djgpp/tmp/./fpregs 10

Breakpoint 2, foo (n=10) at fpregs.c:14
14        for (i = 0; i < n; i++)
(gdb) bt
#0  foo (n=10) at fpregs.c:14
#1  0x000017c5 in main (argc=2, argv=0xa) at fpregs.c:31
(gdb)

> What about for stabs?

In the same program compiled with -gstabs+, `bt' works correctly as
well:

D:\usr\djgpp\tmp>\gnu\gdb-0221\gdb\gdb ./fpregs_s
GNU gdb 20040221
Copyright 2004 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 "--host=i386-pc-msdosdjgpp --target=djgpp"...
(gdb) b foo
Breakpoint 1 at 0x1616: file fpregs.c, line 8.
(gdb) r 10
Starting program: d:/usr/djgpp/tmp/./fpregs_s 10

Breakpoint 1, foo (n=10) at fpregs.c:8
8         register double a = n * 1.5;
(gdb) b 14
Breakpoint 2 at 0x1654: file fpregs.c, line 14.
(gdb) c
Continuing.

Breakpoint 2, foo (n=10) at fpregs.c:14
14        for (i = 0; i < n; i++)
(gdb) bt
#0  foo (n=10) at fpregs.c:14
#1  0x00001725 in main (argc=2, argv=0x20550) at fpregs.c:31
(gdb)

> Can you try Jim's example program here compiled for DWARF 2?
> 
> http://sources.redhat.com/ml/gdb-patches/2004-04/msg00025.html
> 
> Try an info address a in foo and see what you get.

I get the following, no matter whether I compile with "-gstabs+" or
"-gdwarf-2":

(gdb) info address a
Symbol "a" is a variable in register st4.
(gdb) info address b
Symbol "b" is a variable in register st0.
(gdb) info address c
Symbol "c" is a variable in register st3.
(gdb) info address d
Symbol "d" is a variable in register st2.
(gdb) info address e
Symbol "e" is a variable in register st1.
(gdb)
(gdb) info address i
Symbol "i" is a variable in register eax.
(gdb) info address n
Symbol "n" is a variable in register edx.

> Also, can you confirm the dumped DWARF info has a DW_AT_frame_base of
> DW_OP_reg4, not 5?

I cannot use readelf here, since DJGPP binaries are COFF files, not
ELF files.  Is there a way to do this using objdump?

FWIW, in the program compiled with -gstabs+, the register allocation
I see is the same as Jim cited in his message:

63     RSYM   0      5      00000002 1564   n:r(0,1)
64     RSYM   0      7      00000000 1573   i:r(0,1)
65     RSYM   0      8      00000010 1582   a:r(0,13)
66     RSYM   0      9      0000000c 1592   b:r(0,13)
67     RSYM   0      10     0000000f 1602   c:r(0,13)
68     RSYM   0      11     0000000e 1612   d:r(0,13)
69     RSYM   0      12     0000000d 1622   e:r(0,13)

> How often does DJGPP use sdb, stabs, dwarf 2?

I don't have statistics (but see below).  I myself use all of them
roughly the same.

> I just realized that DWARF 2 is not the default.

Well, it is in DJGPP: GCC 3.2 and later use DWARF-2 by default.  So I
guess, for the random DJGPP user, DWARF-2 is much more frequent these
days that either -gstabs+ or -gcoff.

> I've got to go out-of-town now for the weekend, but I'll work on an exact
> step by step when I get back on Monday.

Thanks.

> I'm interested in fixing Cygwin.  I may need to change generic i386 code
> to do that.  So, I guess I have to be interested ;-).

I thought so, but given the fact that I wasn't following this thread
closely, I didn't want to make an impression that I'm tryion to twist
your hand to do something that is only tangentially related to your
patch.