This is the mail archive of the dwarf2@corp.sgi.com mailing list for the dwarf2 project.


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

Re: location lists


> 
> I don't think that it is necessary to describe all globals in every
> compilation unit, and, at least in C or C++, this isn't possible,
> since each compilation unit is unaware of the globals defined in 
> other compilation units.  Also, it is not uncommon for different
> shared libraries to contain global symbols which have the same 
> name but different scopes (i.e., restricted to the library). 
> 
> Dwarf is intended to describe the structure of a program.  It is
> not designed to be the internal format for a debugger's symbol table.
> I'm at a loss why one would want to use location lists to describe
> globals.  I guess you can do this, but it seems awkward, inefficient,
> and clearly unnecessary.  Your assumption that this is the only 
> solution seems to be the cause of your difficulty.
> 
> This is a quality of implementation issue.  When the user of a 
> debugger refers to a symbol, the debugger needs to determine 
> what symbol is being referenced.  If there is a reference to it
> in the current context (whatever that may mean to the debugger), 
> then that reference should be used.  This might be a location 
> list entry which indicates that the symbol is located in a
> register.  
> 

   Right here is where you lose me.  DWARF doesn't describe references to
   global symbols; it only describe declarations & definitions.  So, how can
   a debugger know if there is a reference in the current context?  Surely
   you're not talking about requiring a vendor extension to get this right?
   Maybe you're talking about deducing the presence of a reference by looking
   for a replicated global definition (which is problematic for Ada's
   describe-an-object-once-only approach)?

   I agree that this is a quality of implementation issue, but I don't see
   how DWARF is enabling a good quality implementation.

   BTW, have you read the DW_TAG_local_copy idea that's floating around?  It
   seems to solve this my describing globals as simple location descriptions,
   and then augmenting that with local information in any compilation that
   has special case locations for the global.  I believe it would provide all
   the descriptive functionality that's needed.

-- 
Todd Allen
Concurrent Computer Corporation


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