This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdb supports dwarf2 which is generated by ADS compiler?


On Thu, Jan 08, 2004 at 08:09:57AM -0600, Tim Combs wrote:
> The dwarf2 generated by the ADS compiler has only limited supported from GDB.
> especially from a C++ perspective.  The problem is in the way the compilation 
> units are created by the ADS compiler.
> 
> When GCC creates a compilation unit (at least in my example programs), the
> class definition contained in the header file and the member functions are 
> in a single compilation unit.
> 
> When ADS generates a compilation unit that contains a function, it also 
> generates  compilation units containing the definition of all the header 
> files included in the function file. I've been trying to work on a
> problem with C++ classes in particular and so from a C++ perspective,
> this creates a problem because the class definition is not in the same
> compilation unit as the member functions.  
> 
> These function definitions usually use either an AT_TAG_specifiction or 
> an AT_TAG_abstract tag that refers that uses a location description that
> points to the definition of the function and the class which it belongs.  
> When a user sets a breakpoint, GDB will go looking for the psymtab 
> that contains the address its looking for.  It then parses the debugging 
> information in *that* compilation unit.  Because of that, 
> GDB doesn't process the "header" compilation unit that has the definition 
> of the class.  So the class definition from GDB's perspective only
> contains the member functions that were contained the compilation
> unit that was parsed.  Again, from a C++ perspective, this means that 
> public and private as well as inherited class variables cannot be seen.

OK, thanks.  This problem is expected to get fixed this year... I hope. 
It's been on our todo list for ages.

> Then, there is another problem, at least with the 1.2 compiler in that if 
> the "this" pointer is not explicitly used in the code, Arm will generate
> a __this pointer.  So GDB's lookup function that's hard coded to look for
> "this" fails.

I'd have to see a complete sample to decide what to do about this...
but that's lower priority than the previous issue.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]