Re: location lists revisited

[todd dot allen at ccur dot com (Todd Allen)]

> > 
> > Furthermore, from 3.1:
> > 
> >    A compilation unit typically represents the text and data contributed
> >    by a single relocatable object file.  It may be derived from several
> >    source files, including pre-processed "include files".
> 
> So?
> 
> > This seems not only to permit the placement of the declarations of global as
> > I did, but also to encourage it.
> 
> In what fashion does it dictate that you (a) must use location lists,
> and (b) must provide incorrect and inaccurate values for the ranges?
> 

It doesn't.  I meant that it suggests that my example source should have the
example DWARF that I gave, but ignoring the location lists.  You stated:

   The first definition of "global" declares that it's lifetime is
   limited to source1.c.  This appears to be a file local symbol,
   not a global, although the AT_external is true.  ...

I'm worried by the fact that you think it's a file local symbol.  A
restatement of my point using the terms you're bandying about is: Because
DW_AT_external is TRUE, it must be a global.  DW_AT_external => TRUE forces
it to be global, and it's the only thing that can make an entity global.  In
particular, there is no magic place to put symbols to be global.

Or perhaps you merely were saying that it seemed like a file local symbol
because of the location list?  If so, then we just had a miscommunication.

> > 
> > Very well.  Despite all the confusion, I think everyone is agreed that using
> > location lists to describe global variables is a bad idea.  I'm pleased.  I
> > only explored the approach because Michael seemed to be advocating it.
> 
> Could you please tell me where I appeared to be advocating this idea?  
> Since I think that this is a bad idea, either I have not been expressing
> myself clearly, or you seem to be completely misinterpreting my statements.
> 

I assure you, that cuts both ways.  I keep having to wonder if I'm expressing
myself clearly, and it seems to me that you're completely misinterpreting my
statements, too.  But I think we're starting to understand each other better,
now.  (Well, I can hope.)

> 
> > You keep asserting that DWARF2 provides a way to describe this latest case
> > I'm talking about.  Certainly, I can't find a way, and you haven't said
> > anything to back up your assertion.  Perhaps you can provide a proof of
> > concept.
> 
> As I previously suggested, look at what GCC generates for this
> code.
>  

I'll state it more clearly: GCC provides no support for describing local
copies of globals in DWARF2.  This is not just based on a search for location
lists.  I found no support at all for this concept, based on a survey of the
source, DWARF dumps, and actually building debugging an example.

> 
> You seem to have picked a solution (and a flawed one, in my opinion)
> and you now look for compilers and debuggers which have implemented
> this solution.  I'd (again) suggest that you look at how the compilers
> and debuggers address this code, without insisting that they use
> your solution.
> 

I have not picked any particular solution.  I'm looking for any solution.  In
particular, and as I've already stated, I think location lists for globals
are a bad idea.  You have asserted that other compilers and debuggers support
descriptions of local copies of global already, but so far the only concrete
example you've suggested does not appear to.

I hardly have access to all compilers and debuggers in the world.  If someone
can suggest one that does actually support this, I'll look at how it does it,
and if it makes sense, I'll follow their lead.  If not, then there's what
follows...

> > Certainly, I don't think it's a good idea.  Let's let it die as relates to
> > global variables with local copies.  (I would still like to understand what
> > you were getting at regarding scopes, though!)
> > 
> > So, what approach is workable?  At least so far, no one has suggested
> > anything concrete that stays within the bounds of DWARF2.  So, the best idea
> > that I see is Jason's DW_TAG_variable/DW_TAG_constant local copy extension.
> > In the absence of any other concrete approach, I'm willing to write up the
> > local copy extension as a proposal.
> 
> You have a dogged attachment to what does not appear to be a necessary
> extension to Dwarf.  
> 
> Please review my previous suggestion about relaxing the prohibition
> on locations in non-defining declarations.  Perhaps you don't believe
> that this was a concrete suggestion. 
> 

What exactly is the difference in the two approaches?  As I see it, to
describe local copies of global variables, both approaches end up providing
something like this:

   DW_TAG_compile_unit

      DW_TAG_variable      <-----------------------------\
      DW_AT_name "global"                                |
      DW_AT_location [DW_OP_addr ...]                    |
                                                         |
   NULL                                                  |
                                                         |
   DW_TAG_compile_unit                                   |
                                                         |
      DW_TAG_subroutine                                  |
                                                         |
         DW_TAG_variable                                 |
         ... note absence of DW_AT_name ...              |
         DW_AT_declaration                               |
         DW_AT_specification ----------------------------/
         DW_AT_location [DW_OP_reg...]

      NULL

   NULL

This is the utility that I see for your relaxation.  Is it not what you
intended?  If not, please elaborate on what you did intend.

If it is what you intended, then we're in agreement (and have been for a
while now).  And the only potential extension that I see would be wording to
clarify that this might be a good way to describe local copies of globals.

-- 
Todd Allen
Concurrent Computer Corporation