On 04 Mar 2010, at 15:45, Seth Grover wrote:
I believe this is a bug that was introduced with GDB 7.0
...
I don't know whether anyone already reported this bug to the GDB
developers.
http://sourceware.org/bugzilla/show_bug.cgi?id=11349
I just reported it as a bug to GDB.
To ensure that it's as easy as possible to reproduce and fix by the
gdb people, you should preferably include a compiled version of the
program, and the result of "readelf -gw", and optionally if possible a
version of a program that demonstrates the problem compiled to
assembler code with any dependencies on the FPC RTL removed (so they
can add it to the gdb test suite). E.g., maybe the problem is also
reproducible with a pchar that's passed as "var" parameter (since
ansistring is currently just an alias for pchar in the DWARF debug
info) and the string concatenation is also unnecessary to reproduce
the problem.
It's similar to how people reporting a bug in FPC shouldn't include a
test program that depends on Qt, KDE or even Lazarus, because that
a) makes it harder to test (because you have to install all
dependencies, and then figure out whether the problem is in these
extra libraries, how they are used, or in the compiler/rtl)
b) harder to reduce to a test case that can included in the test suite
I.e., I think this program will also demonstrate the problem:
procedure doit (var s : pchar);
begin
end;
var
s : pchar;
begin
s := 'test';
doit(s);
end.
If you compile this to assembler code and strip out all the
unnecessary references to threadvars, RTL init code etc, it should
become a nice, self-contained example that the GDB developers can
easily use without having to install FPC first.
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
