Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2009-10

gdb shows wrong type info

5 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Paul Ishenin

Hello, FPC developers' list.

This was reported few days ago on the Lazarus mail list and probably was not noticed by FPC developers:

Compile any application with stabs debug info (I did not check with dwarf), run it in gdb:

(gdb) ptype Exception
type = EXCEPTION = class : public TOBJECT
   private
     FMESSAGE : ANSISTRING;
     FHELPCONTEXT : LONGINT;
   public
     constructor CREATE (EXCEPTION, POINTER, ANSISTRING) : ^EXCEPTION;
     constructor CREATEFMT (EXCEPTION, POINTER, ANSISTRING, unnamedtype,
ONGINT) : ^EXCEPTION;
     constructor CREATERES (EXCEPTION, POINTER, PSTRING) : ^EXCEPTION;
     constructor CREATERESFMT (EXCEPTION, POINTER, PSTRING, unnamedtype,
ONGINT, ) : ^EXCEPTION;
     constructor CREATEHELP (EXCEPTION, POINTER, ANSISTRING, ONGINT) :
^EXCEPTION;
     constructor CREATEFMTHELP (EXCEPTION, POINTER, ANSISTRING,
unnamedtype, ONGINT7, ) : ^EXCEPTION;
     constructor CREATERESHELP (EXCEPTION, POINTER, PSTRING, LONGINT) :
^EXCEPTION;
     constructor CREATERESFMTHELP (EXCEPTION, POINTER, PSTRING,
unnamedtype, ONGINT7, ) : ^EXCEPTION;
end

If you look carefully at the gdb output you can notice the next types:
1. ONGINT
2. ONGINT7

Same if you check gdb output for TObject (and even more - "OINTER" type is there).

Is this known? Is this a bug?

Best regards, Paul Ishenin.

Reply by email

Jonas Maebe
to Paul Ishenin
Paul Ishenin wrote
Compile any application with stabs debug info (I did not check with dwarf), run it in gdb:

Which FPC version (does it happen both with 2.2.4 and with 2.3.1 or trunk), which gdb version and which platform?

Jonas

Reply by email

Paul Ishenin
to Jonas Maebe
Jonas Maebe wrote 5 lines
> Compile any application with stabs debug info (I did not check with > dwarf), run it in gdb: Which FPC version (does it happen both with 2.2.4 and with 2.3.1 or trunk), which gdb version and which platform?

1. fpc 2.5.1 built today from the trunk
2. did not check with 2.3.1 / 2.2.4
3. gdb 6.8 and gdb 7.0
4. windows xp 32bit

Best regards,
Paul Ishenin.

Reply by email

Jonas Maebe
to Paul Ishenin: Hello, FPC developers' list. This was reported few days ago on the Lazarus mail list and…
Paul Ishenin wrote
constructor CREATEFMT (EXCEPTION, POINTER, ANSISTRING, unnamedtype, ONGINT) : ^EXCEPTION;

It also happens with gdb 6.5 and fpc 2.2.4. I don't know the details of the conventions for defining method type information in stabs, but at least the string contains all type names correctly: CREATEFMT:: 312=##39;:__ct__9EXCEPTION7POINTER10ANSISTRING11unnamedtype7LONGINT;

Jonas

Reply by email

JoshyFun
to Paul Ishenin: Hello, FPC developers' list. This was reported few days ago on the Lazarus mail list and…

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

Reply by email