Re: [fpc-devel] fp IDE with libgdb
Mark Morgan Lloyd wrote: Jonas Maebe wrote: On 01 Mar 2010, at 15:10, Mark Morgan Lloyd wrote: I'm still getting a bus or alignment error in the fp IDE when driving gdb but I'm reasonably optimistic that I'll be able to find that now. PowerPC is fine so it's probably not something like an endianness issue. A bus error generally means an alignment issue. Most PowerPC processors don't require data to be aligned, but SPARC cpu's do. Thanks for that Jonas, noted. The other possibility is some peculiarity when parsing gdb output back into the IDE. I'll be back :-) I found myself wondering whether the problem was related to the change from NPTL to pthreads, and couldn't decide from my notes exactly when I last had the IDE debugger working successfully on SPARC. At that point I decided that trying a version of libgdb later than 6.7 would be a good idea, since this could be a libgdb rather than an fp problem. Since I see related discussion on Mantis as 15272 I hope this will be useful to somebody. I've got 2.5.1 installed as the standard fpc on the system I'm working on, so there's no significant difference between the installed compiler and the one I'm trying to build. I was not able to get libgdb 6.8 working due to duplicate symbols so I moved straight to 7.0.1. libgdb configure/make runs without problems. I note here that --without-python is inoperative and --with-python=no little better: libpython is still required even if Python scripting is not built into the debugger. The result of this is that there must be (a symlink to) libpython.so or possibly libpython.a on the target system, on Debian Lenny I added libpython.so - libpython2.5.so. These are the libgdb files that are needed for the fp IDE: libgdb/linux/libgdb.a libgdb/linux/libbfd.a libgdb/linux/libopcodes.a libgdb/linux/libiberty.a libgdb/linux/libreadline.a libgdb/linux/libhistory.a libgdb/linux/libdecnumber.a libgdb/linux/libgnu.a Note the last two which are new. On a SPARC target they need to be in ../libgdb/linux/sparc, otherwise as above; a (Linux) PowerPC system also needs libsim.a. With the files available as above a complete build (i.e. make all) will still fail. Referring to instructions given in bug #15272, cd fpcsrc/ide, run make 'FPCOPT=-s' and then edit link.res to add a couple more libraries: INPUT( -ldecnumber -lgnu -lz -lexpat Finally, run ./ppas.sh which should result in a usable 2.5.1 fp IDE with libgdb 7.0.1. Unfortunately I still get problems on SPARC even with 7.0.1, I can't shed any light on those yet but wanted to get the above written up while it was still fresh in my mind. -- 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
Re: [fpc-devel] fp IDE with libgdb
Mark Morgan Lloyd wrote: Note that the code is correct: it's output the Hello World message even though subsequently the debugger is confused. d48656c = #13'Hel'. gdb on SPARC is trying to dereference the string itself. I've fixed this in r13813 in trunk. 0d48. Well spotted :-) OK, I'll get back onto that as soon as I've got a couple more live jobs off my desk. Apologies that once again I've taken months getting back onto this. I checked the code but there was still a problem, however I think that there's a possibility that I somehow screwed up getting the most up-to-date version (I don't claim great experience with SVN etc.). I took a bit of a look at the generated code using -al but I really need to get getting 2.4.0 onto the various development machines and re-test. One question if I may: am I correct in believing that I need to generate the compiler with EXTDEBUG before -an works? Are there any undesirable side effects to doing this? I'm very sorry, I'd made the usual silly mistake of not checking the /usr/local/bin/ppc* symlink so was still using the unfixed compiler. The code as currently in trunk (2.5.1) works fine on SPARC if built without optimisation, I'll check the optimised version presently. I'm still getting a bus or alignment error in the fp IDE when driving gdb but I'm reasonably optimistic that I'll be able to find that now. PowerPC is fine so it's probably not something like an endianness issue. -- 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
Re: [fpc-devel] fp IDE with libgdb
Jonas Maebe wrote: On 01 Mar 2010, at 15:10, Mark Morgan Lloyd wrote: I'm still getting a bus or alignment error in the fp IDE when driving gdb but I'm reasonably optimistic that I'll be able to find that now. PowerPC is fine so it's probably not something like an endianness issue. A bus error generally means an alignment issue. Most PowerPC processors don't require data to be aligned, but SPARC cpu's do. Thanks for that Jonas, noted. The other possibility is some peculiarity when parsing gdb output back into the IDE. I'll be back :-) -- 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
Re: [fpc-devel] fp IDE with libgdb
Pierre Muller wrote:
True in principle,
but XML library used for GDb
is expat, so you should
add {$linklib expat.a}
in gdbint.pp
Thanks, that certainly improves things. There's still a runtime error
but I'll see if I can work out what's going on myself. I might be some time.
It is generally easier to
first try to compile
testgdb executable
in packages/gdbint directory.
Noted :-)
Once this executable links without errors,
with the same libraries, it should
also work for the IDE.
In actual fact I think the IDE code might be more up to date than
testgdb. However I'm very wary since the problems still seem to be
specific to either PPC or Debian.
--
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
Re: [fpc-devel] fp IDE with libgdb
On Mon, Oct 5, 2009 at 10:27 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
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'
If libgdb wants more functions then just link more libraries to get
the necessary functions until it is happy.
Find out which library offers the routines it wants and link them to
your application too. I would guess it wants libxml, so something like
{$linklib xml} or {$linklib libxml)
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE with libgdb
Felipe Monteiro de Carvalho wrote:
On Mon, Oct 5, 2009 at 10:27 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
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'
If libgdb wants more functions then just link more libraries to get
the necessary functions until it is happy.
Find out which library offers the routines it wants and link them to
your application too. I would guess it wants libxml, so something like
{$linklib xml} or {$linklib libxml)
I tried that and didn't get anywhere. I'll try again presently but am
currently focusing on SPARC.
--
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
RE: [fpc-devel] fp IDE with libgdb
True in principle,
but XML library used for GDb
is expat, so you should
add {$linklib expat.a}
in gdbint.pp
It is generally easier to
first try to compile
testgdb executable
in packages/gdbint directory.
Once this executable links without errors,
with the same libraries, it should
also work for the IDE.
Pierre Muller
-Message d'origine-
De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel-
boun...@lists.freepascal.org] De la part de Felipe Monteiro de Carvalho
Envoyé : Wednesday, October 07, 2009 1:28 PM
À : FPC developers' list
Objet : Re: [fpc-devel] fp IDE with libgdb
On Mon, Oct 5, 2009 at 10:27 AM, Mark Morgan Lloyd
markmll.fpc-de...@telemetry.co.uk wrote:
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'
If libgdb wants more functions then just link more libraries to get
the necessary functions until it is happy.
Find out which library offers the routines it wants and link them to
your application too. I would guess it wants libxml, so something like
{$linklib xml} or {$linklib libxml)
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE with libgdb
On 05 Oct 2009, at 15:27, Mark Morgan Lloyd wrote: 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. You're really picking your fights, aren't you? :) The textmode IDE is probably the least maintained part of FPC currently, and Linux/SPARC is not exactly the most used release either :) -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. d48656c = #13'Hel'. gdb on SPARC is trying to dereference the string itself. I've fixed this in r13813 in trunk. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE with libgdb
Jonas Maebe wrote: On 05 Oct 2009, at 15:27, Mark Morgan Lloyd wrote: 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. You're really picking your fights, aren't you? :) The textmode IDE is probably the least maintained part of FPC currently, and Linux/SPARC is not exactly the most used release either :) [GRIN] Yes, and I'm the one trying to get to grips with the IDE for the common good starting with finding out exactly what files are being built into it on the different platforms- hence the Perl filter. If SPARC is of any continuing relevance it's because it's possible to get fairly large systems dirt-cheap right now, I've been very quiet on this over the last few months specifically because I was trying to get to grips with the IDE issue... I didn't want to say anything until I was confident of my facts. Note that the code is correct: it's output the Hello World message even though subsequently the debugger is confused. d48656c = #13'Hel'. gdb on SPARC is trying to dereference the string itself. I've fixed this in r13813 in trunk. 0d48. Well spotted :-) OK, I'll get back onto that as soon as I've got a couple more live jobs off my desk. Do you agree that the PowerPC problem is probably a broken Debian library somewhere? It's not as though we actually need XML for anything... -- 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
Re: [fpc-devel] fp IDE with libgdb
On 06 Oct 2009, at 16:38, Mark Morgan Lloyd wrote: Do you agree that the PowerPC problem is probably a broken Debian library somewhere? It's not as though we actually need XML for anything... Sorry, I really don't know. I'm not involved in the IDE at all, let alone in its GDB integration. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE with libgdb
Jonas Maebe wrote: On 06 Oct 2009, at 16:38, Mark Morgan Lloyd wrote: Do you agree that the PowerPC problem is probably a broken Debian library somewhere? It's not as though we actually need XML for anything... Sorry, I really don't know. I'm not involved in the IDE at all, let alone in its GDB integration. In that case I'll assume that it's a Debian problem and drop it, or maybe see if I can patch it out of libgdb for the moment. I suppose that one thing I should look at is bumping the supported libgdb 6.7.1 - 6.8 (current). I might need to ask for help if that involves the fpc makefiles etc. -- 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
[fpc-devel] fp IDE with libgdb
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,
