Hi, all

i'm trying to use gdb to debug FPC compiled file with DWARF debug information. fpc -gw3 test.pas

here's test.pas listing
---codestart--
procedure TestUp;
begin
  writeln(5);
end;

begin

  Testup;
  writeln('hello world');

end.
---codeend--
the sample compiles, ok,
but then i'm trying to setup a breakpoint, the breakpoint is set at the proper place, but gives two identical warnings : warning: (Internal error: pc 0x40144e in read in psymtab, but not in symtab.)

If code is modified, just by adding a parameter to Testup function,
gdb can no longer set a breakpoint
---codestart--
procedure TestUp(i: integer);
begin
  writeln(i);
end;
begin
  Testup(5);
  writeln('hello world');
end.
---codeend--

(gdb) b test.pas:7
invalid dwarf2 offset 4247672

there's an issue at bug report about dwarf line information http://bugs.freepascal.org/view.php?id=9671
i wonder if it's the same. or may be there're some switches that i'm missing?

Thanks
Dmitry

dmitry boyarintsev wrote

i'm trying to use gdb to debug FPC compiled file with DWARF debug information. fpc -gw3 test.pas

Dwarf3 is not yet supported by current released versions of gdb. Use dwarf2 (-gw2) instead.

Jonas

-gw2 does not work either, it gives out identical error message. is it possible that fpc does not generates dwarf2?

btw, i'm using latest fpc trunk, and gdb v6.7.50 win32

dmitry boyarintsev wrote

-gw2 does not work either, it gives out identical error message. is it possible that fpc does not generates dwarf2? btw, i'm using latest fpc trunk, and gdb v6.7.50 win32

It works fine on at least Mac OS X and Linux. I don't know if anyone ever tested it on Windows. If it doesn't work there, it should probably be disabled for that target until someone fixes it (to avoid situations like yours from happening).

Jonas

It works fine on at least Mac OS X and Linux. I don't know if anyone ever tested it on Windows. If it doesn't work there, it should probably be disabled for that target until someone fixes it (to avoid situations like yours from happening).

this odd, i thought debug info (both dwarf and stabs) is expected to be platform independant.
thanks for the comments then.

The information itself is platform-independent, but how you have to encode it in the binary isn't (at least not completely). Please file a bug report about dwarf2 being broken for win32.

Thanks,

Jonas

the bug's been reported (#12872).

if i try to fix the bug, should i first to look at PE file writting units?

dmitry boyarintsev wrote

the bug's been reported (#12872). if i try to fix the bug, should i first to look at PE file writting units?

You could first try compiling with -Aas. If that solves the problem, then the bug is indeed in the internal assembler. If that does not solve the problem, you can try -Xe to also use the external linker.

Another things that you could try is to add
"tf_dwarf_relative_addresses" and/or "tf_dwarf_only_local_labels" to the "flags" field of the "system_i386_win32_info" typed constant in compiler/systems/i_win.pas

Jonas

all these command lines did not work
fpc -Xe -gw2 test.pas
fpc -Aas -gw2 test.pas
fpc -Xe -Aas -gw2 test.pas

in all three cases gdb returnes "invalid dwarf2 offset "

Did you try with adding tf_dwarf_relative_addresses to the win32 target flags? The binutils for Linux do not follow the dwarf standard (expecting absolute addresses in some places where the dwarf standard says that you should use relative offsets), but since Linux support was implemented first that's also the default in FPC.

Putting absolute addresses in places where relative offsets are expected certainly will result in invalid offsets.

Jonas

Jonas,
I've added tf_dwarf_relative_addresses to system information for win32 target and have recompiled the compiler.
so now whenether i'm using 'gw2' or 'gw3' compiler options i'm getting test.pas(9,1) Fatal: Internal error 200404124

test.pas(9,1) line 'end.' (see source is the at the first mail of this thread')

should 'tf_dwarf_relative_addresses' be used with some other flag?

Please compile with -Aas for testing purposes.

thanks Florian and Jonas

i've just did it, right before receiving your email. and it made it work. exe is compiled succesfully.
gdb is able to set up break points, though warnings are still present.

i've also tried using external linker -Aas -Xe and it works too.

dmitry boyarintsev wrote

gdb is able to set up break points, though warnings are still present.

What kind of warnings?

Jonas

compile line
fpc -Aas -gw2 test.pas
gdb test.exe
...
(gdb) b test.pas:7
warning: (Internal error: pc 0x40144e in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x40144e in read in psymtab, but not in symtab.)

Breakpoint 1 at 0x40144e: file test.pas, line 7.

...
break point works ok.

I got these warnings also on Mac OS X when I was initially on dwarf support there. Unfortunately, I don't remember anymore which fix exactly solved them, or what the root cause was.

Could you execute the following gdb commands to to see which code this address corresponds to?

info line *0x40144e
x/10i 0x40144e

Jonas

here you go (i've accidently deleted test.pas, and created new one, naming main.pas, but the code is the same) :

(gdb) info line *0x40144e
warning: (Internal error: pc 0x40144e in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x40144e in read in psymtab, but not in symtab.)

Line 7 of "main.pas" starts at address 0x40144ewarning: (Internal error: pc 0x40 144e in read in psymtab, but not in symtab.)

<main+14> and ends at 0x401457warning: (Internal error: pc 0x401457 in read in psymtab, but not in symtab.)
<main+23>.

(gdb) x/10i 0x40144e
0x40144ewarning: (Internal error: pc 0x40144e in read in psymtab, but not in symtab.)
<main+14>: mov $0x5,%ax
0x401452warning: (Internal error: pc 0x401452 in read in psymtab, but not in symtab.)
<main+18>: call 0x401400warning: (Internal error: pc 0x401400 in read inpsymtab, but not in symtab.)
<TESTUP>
0x401457warning: (Internal error: pc 0x401457 in read in psymtab, but not in symtab.)
<main+23>: call 0x406ec0 <fpc_get_output>
0x40145cwarning: (Internal error: pc 0x40145c in read in psymtab, but not in symtab.)
<main+28>: mov %eax,%ebx
0x40145ewarning: (Internal error: pc 0x40145e in read in psymtab, but not in symtab.)
<main+30>: mov %ebx,%edx
0x401460warning: (Internal error: pc 0x401460 in read in psymtab, but not in symtab.)
<main+32>: mov $0x40a000,%ecx
0x401465warning: (Internal error: pc 0x401465 in read in psymtab, but not in symtab.)
<main+37>: mov $0x0,%eax
0x40146awarning: (Internal error: pc 0x40146a in read in psymtab, but not in symtab.)
<main+42>: call 0x407110 <fpc_write_text_shortstr> 0x40146fwarning: (Internal error: pc 0x40146f in read in psymtab, but not in symtab.)
<main+47>: call 0x403b00 <fpc_iocheck>
0x401474warning: (Internal error: pc 0x401474 in read in psymtab, but not in symtab.)
<main+52>: mov %ebx,%eax

Maybe using tf_dwarf_only_local_labels in target flags?

will try it tonight

That's something completely different. It only makes sure that all dwarf information for the current unit is written in the object file of the current unit, rather than that the compiler tries to reuse dwarf information written in object files of other units (e.g. if you use the longint type, then the compiler will write the dwarf info for the longint type to the current unit, rather than referring to the information written in the system unit's object file).

The reason is that Mac OS X' linker requires that all labels used in dwarf sections are local to the current object file, as it does not relocate dwarf sections (to speed up linking large debug builds).

Jonas

I believe it has something to do with a mismatch between the debug information and the regular symbol table of the application.

Jonas