Re: location lists revisited

[Michael Eager <eager at eagercon dot com>]

Todd -- 

By only sending you a reply, I had tried to take this off the Dwarf 2
email list, particularly since you suggested discussing this offline.

By also copying the Dwarf 2 email list, you seem unwilling to follow
your own suggestion. 

Todd Allen wrote:
> 
> > >
> > > 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


-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077