paweld/fpc
1
0
Fork 0
mirror of https://gitlab.com/freepascal.org/fpc/source.git synced 2025-08-31 22:10:51 +02:00
Code Issues Packages Projects Releases Wiki Activity

* always generate a DW_TAG_typedef entry when usng a type (not only for

Browse Source 
Darwin anymore), because otherwise if unit A is compiled without debug
    info and unit B uses one of its types, the debug info will contain no
    DW_TAG_typedef for that type and hence gdb will not recognise it as
    a type definition that's part of the program.

git-svn-id: trunk@13424 -
This commit is contained in:
Jonas Maebe 2009-07-22 19:44:29 +00:00
parent c8c3262815
commit 8103a3b39c
1 changed files with 49 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

106
compiler/dbgdwarf.pas
View File

@ -1611,50 +1611,53 @@ implementation
else
current_asmdata.asmlists[al_dwarf_info].concat(tai_symbol.create(labsym,0));
if (target_info.system in systems_darwin) then
{ On Darwin, dwarf info is not linked in the final binary,
but kept in the individual object files. This allows for
faster linking, but means that you have to keep the object
files for debugging and also that gdb only loads in the
debug info of a particular object file once you step into
or over a procedure in it.
To solve this, there is a tool called dsymutil which can
extract all the dwarf info from a program's object files.
This utility however performs "smart linking" on the dwarf
info and throws away all unreferenced dwarf entries. Since
variables' types always point to the dwarfino for a tdef
and never to that for a typesym, this means all debug
entries generated for typesyms are thrown away.
The problem with that is that we translate typesyms into
DW_TAG_typedef, and gdb's dwarf-2 reader only makes types
globally visibly if they are defined using a DW_TAG_typedef.
So as a result, before running dsymutil types only become
available once you stepped into/over a function in the object
file where they are declared, and after running dsymutil they
are all gone (printng variables still works because the
tdef dwarf info is still available, but you cannot typecast
anything outside the declaring units because the type names
are not known there).
The solution: if a tdef has an associated typesym, let the
debug label for the tdef point to a DW_TAG_typedef instead
of directly to the tdef itself. And don't write anything
special for the typesym itself.
Update: we now also do this for other platforms, because
otherwise if you compile unit A without debug info and
use one of its types in unit B, then no typedef will be
generated and hence gdb will not be able to give a definition
of the type.
}
if assigned(def.typesym) and
not(df_generic in def.defoptions) then
begin
{ On Darwin, dwarf info is not linked in the final binary,
but kept in the individual object files. This allows for
faster linking, but means that you have to keep the object
files for debugging and also that gdb only loads in the
debug info of a particular object file once you step into
or over a procedure in it.
To solve this, there is a tool called dsymutil which can
extract all the dwarf info from a program's object files.
This utility however performs "smart linking" on the dwarf
info and throws away all unreferenced dwarf entries. Since
variables' types always point to the dwarfino for a tdef
and never to that for a typesym, this means all debug
entries generated for typesyms are thrown away.
The problem with that is that we translate typesyms into
DW_TAG_typedef, and gdb's dwarf-2 reader only makes types
globally visibly if they are defined using a DW_TAG_typedef.
So as a result, before running dsymutil types only become
available once you stepped into/over a function in the object
file where they are declared, and after running dsymutil they
are all gone (printng variables still works because the
tdef dwarf info is still available, but you cannot typecast
anything outside the declaring units because the type names
are not known there).
The solution: if a tdef has an associated typesym, let the
debug label for the tdef point to a DW_TAG_typedef instead
of directly to the tdef itself. And don't write anything
special for the typesym itself.
}
if assigned(def.typesym) and
not(df_generic in def.defoptions) then
begin
current_asmdata.getaddrlabel(TAsmLabel(pointer(labsym)));
append_entry(DW_TAG_typedef,false,[
DW_AT_name,DW_FORM_string,symname(def.typesym)+#0
]);
append_labelentry_ref(DW_AT_type,labsym);
finish_entry;
current_asmdata.asmlists[al_dwarf_info].concat(tai_symbol.create(labsym,0));
end;
current_asmdata.getaddrlabel(TAsmLabel(pointer(labsym)));
append_entry(DW_TAG_typedef,false,[
DW_AT_name,DW_FORM_string,symname(def.typesym)+#0
]);
append_labelentry_ref(DW_AT_type,labsym);
finish_entry;
current_asmdata.asmlists[al_dwarf_info].concat(tai_symbol.create(labsym,0));
end;
end;
@ -2260,20 +2263,9 @@ implementation
procedure TDebugInfoDwarf.appendsym_type(list:TAsmList;sym: ttypesym);
begin
if not (target_info.system in systems_darwin) then
begin
if not(df_generic in sym.typedef.defoptions) then
begin
append_entry(DW_TAG_typedef,false,[
DW_AT_name,DW_FORM_string,symname(sym)+#0
]);
append_labelentry_ref(DW_AT_type,def_dwarf_lab(sym.typedef));
end;
finish_entry;
end
else
{ just queue the def if needed }
def_dwarf_lab(sym.typedef);
{ just queue the def if needed, beforeappenddef will
emit the typedef if necessary }
def_dwarf_lab(sym.typedef);
end;