[fpc-pascal] Re: gdb, dwarf, and ansistring

[Jonas Maebe]

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