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]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
