[fpc-devel] fp IDE with libgdb

[Mark Morgan Lloyd]

Late last year I raised a perplexing issue where fp (the character-mode 
IDE) bombed when calling libgdb on SPARC, a backtrace appeared to show 
that garbage was being passed as parameters. I've been trying to get to 
grips with this problem and while I can demonstrate that the original 
issue was a red herring (it exists, but not where we were looking) I'm 
left with a couple of issues: help would be very much appreciated.

I've now got four development systems: x86 (32-bit), SPARC, PowerPC 
(32-bit) and ARM (armel). All are running Debian "Lenny".

On each of these I am able to build various versions of libgdb from 
scratch, I'm generally using 6.3 and 6.7.1 as being the earliest and 
latest supported by FPC, except in the case of ARM where I can only use 
6.7.1.

On each system I've built variants of FPC 2.2.4, except for ARM (armel) 
where I've bootstrapped 2.3.1. To help track what's happening I've 
knocked together a Perl script which can strip the -vt output and 
generate a complete list of referenced files- anybody who wants a copy 
is obviously welcome to it.

I notice that when building the fp IDE the build process on x86 looks 
for libgdb.a in fpcsrc/libgdb/linux while on other platforms it looks 
for fpcsrc/libgdb/linux/$CPU (assuming CPU is defined appropriately). As 
an interim measure I've worked around this using hard links.

The fp IDE can drive libgdb to do straightforward debugging on x86 and 
ARM, there might be failures with complex stuff that I've not been able 
to test. Those two platforms are no problem, the problems are on PowerPC 
and SPARC.

=====

On PowerPC, the build process appears to complete successfully, libgdb 
is integrated with fp and there's no indication that fp has failed to 
build. However, trying to start fp fails deep inside initlibgdb.

I've found testgdb.pp, on the other three platforms it compiles and runs 
OK but on PowerPC compiling gives me

Free Pascal Compiler version 2.2.4 [2009/10/02] for powerpc
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for PowerPC
Compiling testgdb.pp
Assembling testgdb
Linking testgdb
/usr/local/lib/fpc/2.2.4/units/powerpc-linux/gdbint/gdbint.o: In 
function `GDBINT_INITLIBGDB':
gdbint.pp:(.text+0x1a60): undefined reference to `error_init'
libgdb.a(xml-support.o): In function `gdb_xml_use_dtd':
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/xml-support.c:522: undefined 
reference to `XML_SetParamEntityParsing'
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/xml-support.c:524: undefined 
reference to `XML_SetExternalEntityRefHandler'
/usr/local/src/fpc/libgdb/gdb-6.7.1/gdb/xml-support.c:528: undefined 
reference to `XML_UseForeignDTD'
..

I believe that this has been reported as a Debian bug before, so far 
I've not found a workaround and while it might not strictly be an FPC 
problem it would be interesting to know whether the build process is at 
fault- can testgdb be added to the build so that it fails if there is a 
problem?

Apart from this fp (compiled without libgdb) works and I can use 
standalone gdb to get a backtrace from a failed program.

=====

On SPARC, build completes and manual compilation of testgdb works OK. fp 
works until you attempt to use the debugger for something, at which 
point the backtrace shows garbage as parameters. Jonas, you might 
remember scratching your head over this one.

In this case fp + libgdb might actually be OK. The problem is that any 
attempt to get a backtrace from SPARC on Linux shows garbage, which I 
suspect means that the debugging information in the binary is corrupt.

Using this test program (please excuse my Modula-2 case conventions :-):

-----8<-----
PROGRAM Test;


   PROCEDURE WriteLn2(str: STRING);

   VAR   ptr: ^INTEGER;

   BEGIN
     WriteLn(str);
     ptr:= NIL;
     IF ptr^ = 0 THEN
       HALT;
     WriteLn(str)
   END;


BEGIN
   WriteLn2('Hello, World!')
END.
----->8-----

I've tried this with various combinations of optimisation on/off during 
compiler build and during application build, and I appear to have a 
robust situation where I can get a good backtrace on all platforms 
except SPARC where this happens:

-----8<-----
$ gdb testC1A1
GNU gdb 6.8-debian
..
(gdb) dir ..
Source directories searched: /home/markMLl/sparc-2.2.4-6.3/..:$cdir:$cwd
(gdb) run
Starting program: /home/markMLl/sparc-2.2.4-6.3/testC1A1
Hello, World!

Program received signal SIGSEGV, Segmentation fault.
0x00010138 in WRITELN2 (STR=Cannot access memory at address 0xd48656c
) at test.pas:11
11          IF ptr^ = 0 THEN
(gdb) bt
#0  0x00010138 in WRITELN2 (STR=Cannot access memory at address 0xd48656c
) at test.pas:11
#1  0x000101bc in main () at test.pas:18
(gdb)
----->8-----

Note that the code is correct: it's output the Hello World message even 
though subsequently the debugger is confused.

=====

I've got about as far as I can on these two problems, and any help would 
be very much appreciated.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]