Bug 16016 - ptype incorrectly shows "record" (pascal/struct) as class (if accessed via pointer) (7.6.1 regression)
Summary: ptype incorrectly shows "record" (pascal/struct) as class (if accessed via po...
Status: REOPENED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.6
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-08 10:49 UTC by Martin
Modified: 2015-08-31 10:08 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin 2013-10-08 10:49:08 UTC
GDB up to and including 7.5.1 are NOT affected
GDB 7.6.0 was not tested
GDB 7.6.1 (from mingw / tested on w32 vista) has the below issue

Consider the following program (compiled with free pascal / dwarf2)

program Test_Record_var_param;
type
  TFoo = record    a,b: Integer;   end;
  PFoo = ^TFoo;
var
  r1, r2: TFoo;  p1, p2: PFoo;
begin
  P1 := @r1;  P2 := @r1;
end.
-----

"p1" and "p2" are both pointers to the record declaration. Except for the name, they point to the same dwarf information entry in .debug_info

Yet running 
gdb -i mi
-gdb-set language pascal

  
ptype p1^
&"ptype p1^\n"
~"type = TFOO = record \n"
~"    A : LONGINT;\n"
~"    B : LONGINT;\n"
~"end\n"
^done
(gdb) 

-data-evaluate-expression p1^
^done,value="{A = 0, B = 0}"
(gdb) 

ptype p2^
&"ptype p2^\n"
~"type = TFOO = class \n"
~"  public\n""
~"    A : LONGINT;\n"
~"    B : LONGINT;\n"
~"end\n"
^done
(gdb) 

-data-evaluate-expression p2^
^done,value="{A = 0, B = 0}"
(gdb) 


ptype p2^ claims p2 points to a class, which is incorrect. 
This only happens if "ptype p1^" wal run first.

Running 
ptype p2^
ptype p1^

and ptype p1^ will claim to be a class.


-data-evaluate-expression correctly returns a record in all cases (a rlass would include the class name)


---
Extract from objdump

 <1><9d>: Abbrev Number: 2 (DW_TAG_variable)
    <9e>   DW_AT_name        : P1	
    <a1>   DW_AT_location    : 5 byte block: 3 10 e0 40 0 	(DW_OP_addr: 40e010)
    <a7>   DW_AT_type        : <0xf6>	
 <1><ab>: Abbrev Number: 2 (DW_TAG_variable)
    <ac>   DW_AT_name        : P2	
    <af>   DW_AT_location    : 5 byte block: 3 20 e0 40 0 	(DW_OP_addr: 40e020)
    <b5>   DW_AT_type        : <0xf6>	

Both DW_AT_type point to the same entry

 <1><cb>: Abbrev Number: 4 (DW_TAG_typedef)
    <cc>   DW_AT_name        : TFOO	
    <d1>   DW_AT_type        : <0xd5>	
 <1><d5>: Abbrev Number: 5 (DW_TAG_structure_type)
    <d6>   DW_AT_name        : TFOO	
    <db>   DW_AT_byte_size   : 8	
 <2><dc>: Abbrev Number: 6 (DW_TAG_member)
    <dd>   DW_AT_name        : A	
    <df>   DW_AT_data_member_location: 2 byte block: 23 0 	(DW_OP_plus_uconst: 0)
    <e2>   DW_AT_type        : <0x10a>	
 <2><e6>: Abbrev Number: 6 (DW_TAG_member)
    <e7>   DW_AT_name        : B	
    <e9>   DW_AT_data_member_location: 2 byte block: 23 4 	(DW_OP_plus_uconst: 4)
    <ec>   DW_AT_type        : <0x10a>	


 <1><f6>: Abbrev Number: 4 (DW_TAG_typedef)
    <f7>   DW_AT_name        : PFOO	
    <fc>   DW_AT_type        : <0x100>	
 <1><100>: Abbrev Number: 8 (DW_TAG_pointer_type)
    <101>   DW_AT_type        : <0xcb>	

 <1><10a>: Abbrev Number: 4 (DW_TAG_typedef)
    <10b>   DW_AT_name        : LONGINT	
    <113>   DW_AT_type        : <0x117>	
 <1><117>: Abbrev Number: 9 (DW_TAG_base_type)
    <118>   DW_AT_name        : LONGINT	
    <120>   DW_AT_encoding    : 5	(signed)
    <121>   DW_AT_byte_size   : 4
Comment 1 Sergio Durigan Junior 2013-10-17 20:10:24 UTC
FWIW, I have tested this using CVS HEAD on Fedora 17 x86_64 with FPC version 2.6.0, and could not reproduce the bug.

(gdb) 
-gdb-set language pascal
^done
(gdb) 
ptype p1^
&"ptype p1^\n"
~"type = TFOO = record \n"
~"    A : SMALLINT;\n"
~"    B : SMALLINT;\n"
~"end\n"
^done
(gdb) 
ptype p2^
&"ptype p2^\n"
~"type = TFOO = record \n"
~"    A : SMALLINT;\n"
~"    B : SMALLINT;\n"
~"end\n"
^done

Would it be possible to give it a try using CVS HEAD?  Thanks.
Comment 2 Sergio Durigan Junior 2014-09-12 23:12:11 UTC
Closing as OBSOLETE due to inactivity.  Feel free to reopen if still valid.
Comment 3 Martin 2015-01-06 01:35:35 UTC
I finally got to build 7.8.1 under mingw 32 bit windows. The issue still exists.

I only tested on Windows.


Compile the program.
gdb_781.exe -i mi project1.exe
b project1.lpr:10
r
ptype p1^
-data-evaluate-expression p1^
ptype p2^

The last ptype shows "class", but it should be record
Comment 4 Martin 2015-08-31 10:08:04 UTC
Just reconfirming, still present in gdb 7.10