Hi,

On my Win64 machine, gdb kept crashing whenever I tried to step into fpc_raiseexception with an error saying that the reg '-1' wasn't defined. And yes, stabs info showed:

4943 FUN 0 187 0000000000408710 66408 fpc_raiseexception:F129 4944 RSYM 0 625 0000000000000001 66432 OBJ:R129 4945 RSYM 0 625 0000000000000002 66441 ANADDR:R4 4946 RSYM 0 625 00000000ffffffff 66451 AFRAME:R4

(AFRAME should be 8, since it's passed in R8...)

So in the end I looked into x86reg.dat and was quite amazed that stabs index for all 'new' AMD64 regs is set to -1, which is wrong of course. Hacking along I changed the stabs-reg indices to match the dwarf64 index (see also here:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/amd64-tdep.h?rev=1.18&content-type=text/x-cvsweb-markup&cvsroot=src) and after bootstrapping the compiler, I can now step into raise as expected. (That said, I did not double-check whether dwarf64 index always matches stabs index...)

Notice: This fix is absolutely necessary if you are working with Lazarus on Win64, as Lazarus automatically sets a breakpoint in fpc_raise... which then crashes gdb, which in turn crashes any running debugging session - in case an exception is raised. Of course it affects also all methods/funs that take e.g. three params that can be passed in regs...

Perhaps someone with more knowledge of stabs and the x86reg.dat can do a proper fix? TIA!

Cheers,
Willi

Afaik, stabs does not support x86-64 that's why it's probably never fixed/noticed.

Florian Klaempfl wrote

Afaik, stabs does not support x86-64 that's why it's probably never fixed/noticed.

The problem is that for some reason, it's nevertheless the default for Win64.

Jonas

This is not true:
I src/gdb/amd64-tdep.c you can see this (line 2419 on current CVS): /* The "default" register numbering scheme for AMD64 is referred to as the "DWARF Register Number Mapping" in the System V psABI. The preferred debugging format for all known AMD64 targets is actually DWARF2, and GCC doesn't seem to support DWARF (that is DWARF-1), but we provide the same mapping just in case. This mapping is also used for stabs, which GCC does support. */ set_gdbarch_stab_reg_to_regnum (gdbarch, amd64_dwarf_reg_to_regnum); set_gdbarch_dwarf2_reg_to_regnum (gdbarch, amd64_dwarf_reg_to_regnum);

This means that indeed stabs and dwarf register number are equal, at least for GDB.

The problem is that this means that we probably also need to distinguish between stabs32 and stabs64, as we already do for dwarf32 and dwarf64... unless we change the code that reads x86reg.dat to use dwarf64 indexes for amd64 stabs registers.

Pierre

There is no stabs64 format, afaik. See http://sourceware.org/bugzilla/show_bug.cgi?id=9327

Jonas

Jonas Maebe wrote

There is no stabs64 format, afaik. See http://sourceware.org/bugzilla/show_bug.cgi?id=9327

Just checked, this example is working fine on Win64:

PS C:\source\bugs\lokals> gdb test.exe
GNU gdb (GDB) 7.2
Copyright (C) 2010 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 "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\source\bugs\lokals/test.exe...done. (gdb) break MAINPROC
Breakpoint 1 at 0x40140c: file test.pp, line 5.
(gdb) run
Starting program: C:\source\bugs\lokals/test.exe
[New Thread 8148.0x9a8]

Breakpoint 1, MAINPROC () at test.pp:5
5 x := 5;
(gdb) step
6 writeln('x=',x);
(gdb) print x
$1 = 5
(gdb)

In any case, register indices and offsets are different matters and as it seems that DWARF indices are fine for stabs, I'd strongly vote for fixing x86_64 stabs info.

Cheers,
Willi

I think that dwarf32 and dwarf64 here only refers to i386 32-bit registers
versus
amd64 64-bit registers.

It is in that meaning that I said that we should use the dwarf64 column of x86reg.dat to implement
the stabs register number for x86_64 CPU.

Pierre

It currently is because dwarf debug information generation for x86_64 is still much more buggy than stabs generation.

Pierre

Is it? I use it all the time on Mac OS X/x86-64 and Linux/x86-64, and it works fine.

Jonas

It might be specific to win64, especially the internal linker. I only tested win64 target, the others might be OK. Note that a recent fix by Willibald Krenn might have improved things a lot, but I didn't have much time to check it out yet.

Pierre

This is also not totally true:
I heard recently that Apple has a 64-bit extension of the stabs debug format in
bfd/mach-o.c:bfd_mach_o_read_symtab_symbol
and
gdb/machoread.c:macho_symtab_read (this doesn't use dbxread.c)

Pierre

That's true, but
a) afaik it's only supported on Mac OS X
b) our Stabs writer does not support those extensions (I initially tried using Stabs on Mac OS X 64 bit because back then DWARF support in FPC was not very good, but changing the Stabs writer seemed more work than improving the DWARF support)

Jonas

DWARF does not work on Win64: while dwarf3 produces an internal error (2010092801, sounds familiar ;-)), dwarf2 debug information seems to be broken too. At least gdb 7.2 reports invalid offsets. Hence for the time being, stabs is the only option and better than nothing. Therefore I'd really love to see the register indices changed.

Thanks,
Willi

DWARF3 is not yet really tested.

dwarf2 debug information seems to be broken too.

Keep this in mind: http://bugs.freepascal.org/view.php?id=15692

You may also want to try with the external linker (-Xe).

Jonas

Jonas Maebe wrote

> dwarf2 debug information seems to be broken too. Keep this in mind: http://bugs.freepascal.org/view.php?id=15692

I don't know exactly what to conclude from this discussion. Are 32 bit pointers enough for WinPE? Then stabs would be fine anyways.

You may also want to try with the external linker (-Xe).

Hmm, -Xe does not seem to work on my system. So, stabs remains the only thing that is working. (Even if it has limitations it is better than 0.)

Cheers,
Willi

Try using the -WB0040000 command line option.

Are 32 bit pointers enough for WinPE? Then stabs would be fine anyways.

The problem is that GDB (at least in the past) zero-extends all offsets in the stabs debug information. That means that a local variable at location ebp-16 is interpreted as being at location ebp+4294967280. There are probably more such small problems, because Stabs was never designed nor implemented to be used for 64 bit platforms within the GNU tool chain.

> You may also want to try with the external linker (-Xe). Hmm, -Xe does not seem to work on my system.

What does "not work" mean?

So, stabs remains the only thing that is working. (Even if it has limitations it is better than 0.)

I'm not opposed to committing that change, it's just that Stabs is a dead end and since no compiler I know of uses it for generating 64 bit debug information (other than a few older Mac OS X compilers, but Mac OS X uses its own fork of GDB), it's probably also very badly tested within GDB itself.

Jonas

Jonas Maebe wrote

> I don't know exactly what to conclude from this discussion. Try using the -WB0040000 command line option.

PS C:\source\bugs\exception> del *.o
PS C:\source\bugs\exception> del *.exe
PS C:\source\bugs\exception> fpc -gw -WB0040000 .\project1.lpr PS C:\source\bugs\exception> gdb .\project1.exe
(gdb) list
invalid dwarf2 offset 504164
(gdb)

At least on my system, having stabs info like the following

58 FUN 0 18 0000000000401540 3216 RAISEEXCEPTION:F1 59 PSYM 0 20 00000000fffffff8 3234 A:5 60 PSYM 0 21 00000000fffffff0 3238 B:5 61 PSYM 0 22 00000000ffffffe8 3242 C:5 62 PSYM 0 23 00000000ffffff90 3246 D:6 63 PSYM 0 24 00000000ffffff88 3250 E:7 64 SOL 0 0 0000000000401540 3254 project1.lpr

yields

Breakpoint 2, RAISEEXCEPTION () at project1.lpr:44 44 raise EAbort.Create('test');
(gdb) info locals
A = 20
B = 1
C = 2
D = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20}
E = 0x42c150 'Hello World!'

which is quite ok ;-).

Sorry, I meant to say that it does not improve the situation.

PS C:\source\bugs\exception> del *.o
PS C:\source\bugs\exception> del *.exe
PS C:\source\bugs\exception> fpc -gw -Xe .\project1.lpr [0.578] Using util C:\source\mingw64\bin\ld.exe
PS C:\source\bugs\exception> gdb .\project1.exe
(gdb) list
invalid dwarf2 offset 6439543

Yes, I understand that stabs is a dead-end. But it's also very useful if you want to work with the compiler on Win64 :)

Cheers,
Willi

That seems like this bug report: http://bugs.freepascal.org/view.php?id=16297

I can't help any further with that since I don't develop for/under Windows though.

Jonas