[fpc-devel] gdb shows wrong type info

JoshyFun joshyfun at gmail.com
Fri Oct 9 14:21:27 CEST 2009


Hello Paul,

Friday, October 9, 2009, 3:13:14 AM, you wrote:

PI> This was reported few days ago on the Lazarus mail list and probably was
PI> not noticed by FPC developers:
PI> Compile any application with stabs debug info (I did not check with
PI> dwarf), run it in gdb:

PI>      constructor CREATEFMT (EXCEPTION, POINTER, ANSISTRING, unnamedtype,
PI> ONGINT) : ^EXCEPTION;
PI> If you look carefully at the gdb output you can notice the next types:
PI> 1. ONGINT
PI> 2. ONGINT7
PI> Same if you check gdb output for TObject (and even more - "OINTER" type
PI> is there).
PI> Is this known? Is this a bug?

I had done a little investigation and found the reason, but not an
explain for it. If parameter type name is larger than 9 chars (not
tested with 9 chars exactly by now) the parsing is wrong. I had
replaced, using a hexeditor, the ANSISTRING and unnamedtype in debug
information as:

CREATEFMT::???=##????;:__ct__9EXCEPTION7POINTER10ANSISTRING11unnamedtype7LONGINT;
CREATEFMT::???=##????;:__ct__9EXCEPTION7POINTER5const5const4CHAR7LONGINT7LONGINT;

And now the type names appear well (except that they are faked of
course), so for some reason long type names are wrongly displayed.

Another related fact is that if I load a program and set a break point
at the beginning (without altered parameters):

(gdb) b PASCALMAIN
Breakpoint 1 at 0x402788: file bug.lpr, line 18.
(gdb) ptype EXCEPTION
type = class EXCEPTION : public TOBJECT {
  private:
    ANSISTRING FMESSAGE;
    LONGINT FHELPCONTEXT;

  public:
    __ct(POINTER, ANSISTRING);
    __ct(POINTER, ANSISTRING, unnamedtype, LONGINT);
    __ct(POINTER, PSTRING);
    __ct(POINTER, PSTRING, unnamedtype, LONGINT);
    __ct(POINTER, ANSISTRING, LONGINT);
    __ct(POINTER, ANSISTRING, unnamedtype, LONGINT, LONGINT);
    __ct(POINTER, PSTRING, LONGINT);
    __ct(POINTER, PSTRING, unnamedtype, LONGINT, LONGINT);
}

The exception parameters are well, but there are missing "__ct"
resolves which I think it is expected at that point.

Maybe this can help somebody to catch the problem.

-- 
Best regards,
 JoshyFun




More information about the fpc-devel mailing list