current namespace game plan

current namespace game plan

[David Carlton]

I've been tossing around namespace ideas in my head for a while, and
they're starting to converge on a game plan that makes sense to me; I
wanted to run it by other people.  Feel free to skip the parts of this
message starting with "So that's the first step".


The initial goal is to have GDB work about as well as it does now,
with the addition that lookup of global symbols will be more likely to
find symbols in namespaces where appropriate (and where the compiler
provides enough debugging information).  There are a few ways that you
can add namespaces that should be searched during symbol lookup:

* By explicit 'using' directives.
* By anonymous namespaces.
* By looking at what namespace the current function is defined in.
* By looking at the arguments of a function that you're trying to
  call.

I won't go into details; current compilers don't give us enough
information to recover the first of those, but we should probably be
able to have enough information to handle the other three cases.  And
Daniel Berlin has posted patches to get GCC to generate the debugging
information for the first of those.

So if I want to do a minimal change to GDB's data structures to allow
this, the thing to do seems to be to add a C++-specific field to
struct block that says what additional search namespaces should be
added to the search list if you're doing name lookup within that
block.  And then modify the symbol table readers to initialize that
field appropriately, and modify the various symbol lookup functions
to, when they hit the global environment, try adding all of those
namespaces to the beginning of the symbol name that you're searching
for.  There will also have to be some changes to C++-specific code to
do name lookup of functions correctly based on their arguments.

This will only modify symbol lookup, not how symbols are stored:
A::var will still be stored in some global block just like it is now.


So that's the first step; that should require relatively small changes
to GDB, and will significantly improve GDB's namespace behavior.
After that, though, there will still be some problems that remain;
here are some that come to mind:

* If a 'using' statement comes in the middle of a block, GDB will
  interpret as affecting the whole block.

I don't think it's worth spending time to get rid of it; it's not that
important, and this part of GDB's architecture is pretty centered on
treating blocks as undifferentiated wholes.  (There are certainly
non-namespace related bugs in this area.)

* Some C++ constructs won't get handled correctly: aliasing namespaces
  (e.g. 'namespace B = A;') or importing single variables from other
  namespaces ('using A::foo;').

I think the architecture from the first step might be able to be
modified to handle the latter; maybe not, though, and it certainly
won't be able to gracefully handle the former.  That won't come until
further down the road.

* We get the semantics of current lookups wrong.
  E.g. lookup_symbol_aux does the is_a_field_of_this stuff at the
  wrong time.  I suspect that overloading is a mess, and I suspect
  that we don't deal with static variables correctly.

These problems are more serious, and I want to solve them as part of
the second step of this process.  So the second step will involve
cleaning up current code, both to fix the semantics of variable lookup
and to just refactor the design of existing code to clean it up.
(E.g. perhaps both lookup_symbol and the code for doing overload
resolution could call the same iterator functions to track down
symbols.)  Hopefully Daniel Jacobowitz can get shanghaied into helping
here.  Ideally, I'd be able to get rid of the 'symtab' argument to
lookup_symbol as well as the global variable 'block_found' in this
stage.


Once the second step is done, there will still be problems: we still
won't handle all C++ constructs correctly (the namespace aliasing and
using-directives that I mentioned above), and there will still be too
much C++-specific stuff in code that everybody has to look at, which
is unfortunate.  I hope that, at this stage, I'll be able to
modularize the notions of lookup algorithms so that different
languages can implement their own weird lookup rules without affecting
other languages.  And, as a bonus, we can speed up symbol lookup
considerably.  That's the third step; it's vague enough that I don't
want to talk about it now.

David Carlton
carlton@math.stanford.edu

Re: current namespace game plan

[Daniel Jacobowitz]

On Fri, Oct 04, 2002 at 02:57:32PM -0700, David Carlton wrote:
> I've been tossing around namespace ideas in my head for a while, and
> they're starting to converge on a game plan that makes sense to me; I
> wanted to run it by other people.  Feel free to skip the parts of this
> message starting with "So that's the first step".
> 
> 
> The initial goal is to have GDB work about as well as it does now,
> with the addition that lookup of global symbols will be more likely to
> find symbols in namespaces where appropriate (and where the compiler
> provides enough debugging information).  There are a few ways that you
> can add namespaces that should be searched during symbol lookup:
> 
> * By explicit 'using' directives.
> * By anonymous namespaces.
> * By looking at what namespace the current function is defined in.
> * By looking at the arguments of a function that you're trying to
>   call.

You're skipping what I'd consider the most important step.

We can't even get namespaces right when the user gives us a fully
qualified name.  We do it for variables and functions by resorting to
the minsym and physname.  But types?  No way.  They all get entered in
the top level.

Same thing for types in other types.

We need:
  - DWARF-2 namespace support in the reader which is very easy,
both Dan Berlin and I have working code for this
  - DWARF-2 namespace support in GCC which Dan Berlin has done,
awaiting the GDB support
  - Inference support in both DWARF-2 and Stabs readers; I have the
prototypes of this all done.  We can correctly infer a type's full name
for everything but enums, I believe.

And:
  - Code to not print excessive qualification on names, for
instance printing the fully qualified type in constructors; it's ugly
and causes needless testsuite churn.

What I really should do is bundle up what I have onto a branch.  If I
feel inspired enough I'll try to do it tomorrow.  The last point caused
me to stop and focus on type printing and type correctness for a bit,
and I got completely sidetracked; a branch would help a lot.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: current namespace game plan

[David Carlton]

On Fri, 4 Oct 2002 18:11:17 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> You're skipping what I'd consider the most important step.

> We can't even get namespaces right when the user gives us a fully
> qualified name.  We do it for variables and functions by resorting to
> the minsym and physname.  But types?  No way.  They all get entered in
> the top level.

Whoops; good thing I asked.

Types are a little tricky without proper debugging information.  But
now I'm starting to remember some e-mails we had a month or so ago
where we said that, for a class, you could figure out the type by
looking at the physname of one of its members (possibly an implictly
defined function, but there should always be something).  Which
probably explains this:

>   - Inference support in both DWARF-2 and Stabs readers; I have the
> prototypes of this all done.  We can correctly infer a type's full
> name for everything but enums, I believe.

Because with enums, there's simply no way to get that information
without improved debugging information.

Fortunately, that sounds like it should complement the other stuff
that I was proposing as the first step, and indeed should be
orthogonal to that.  Do your changes create a symbol whose name is
fully qualified and whose demangled_name is null?  That seems to me
like it should work.

> And:
>   - Code to not print excessive qualification on names, for
> instance printing the fully qualified type in constructors; it's ugly
> and causes needless testsuite churn.

Hmm.  I'll keep that in the back of my mind, but you'll probably have
to remind me periodically that this is important.

> What I really should do is bundle up what I have onto a branch.  If
> I feel inspired enough I'll try to do it tomorrow.  The last point
> caused me to stop and focus on type printing and type correctness
> for a bit, and I got completely sidetracked; a branch would help a
> lot.

That would be great; and then one or the other of us could try to grab
out chunks of that.  E.g. it seems to me that the type inference stuff
that you mentioned would be an improvement to GDB right now, aside
from any other further namespace improvements.

David Carlton
carlton@math.stanford.edu

Re: current namespace game plan

[Daniel Jacobowitz]

On Fri, Oct 04, 2002 at 03:58:50PM -0700, David Carlton wrote:
> On Fri, 4 Oct 2002 18:11:17 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> 
> > You're skipping what I'd consider the most important step.
> 
> > We can't even get namespaces right when the user gives us a fully
> > qualified name.  We do it for variables and functions by resorting to
> > the minsym and physname.  But types?  No way.  They all get entered in
> > the top level.
> 
> Whoops; good thing I asked.
> 
> Types are a little tricky without proper debugging information.  But
> now I'm starting to remember some e-mails we had a month or so ago
> where we said that, for a class, you could figure out the type by
> looking at the physname of one of its members (possibly an implictly
> defined function, but there should always be something).  Which
> probably explains this:
> 
> >   - Inference support in both DWARF-2 and Stabs readers; I have the
> > prototypes of this all done.  We can correctly infer a type's full
> > name for everything but enums, I believe.
> 
> Because with enums, there's simply no way to get that information
> without improved debugging information.

Exactly.

> Fortunately, that sounds like it should complement the other stuff
> that I was proposing as the first step, and indeed should be
> orthogonal to that.  Do your changes create a symbol whose name is
> fully qualified and whose demangled_name is null?  That seems to me
> like it should work.

Not sure what to do for the symbols that go with types (which I'm not
sure should exist, anyway; they're (you guessed it) because that's how
stabs works).  That's probably what I'll settle on.  The type name is
fully qualified.

Things yet to be determined:
  - interaction with TYPE_TAG_NAME
  - interaction with Java
etc.  Type printing and type name handling are messed up all over GDB,
which is why this will take some doing.

> > And:
> >   - Code to not print excessive qualification on names, for
> > instance printing the fully qualified type in constructors; it's ugly
> > and causes needless testsuite churn.
> 
> Hmm.  I'll keep that in the back of my mind, but you'll probably have
> to remind me periodically that this is important.

Without it, for a type std::string (even assuming that were a type and
not the template gop it really is!), the argument lists get way out of
hand.

> > What I really should do is bundle up what I have onto a branch.  If
> > I feel inspired enough I'll try to do it tomorrow.  The last point
> > caused me to stop and focus on type printing and type correctness
> > for a bit, and I got completely sidetracked; a branch would help a
> > lot.
> 
> That would be great; and then one or the other of us could try to grab
> out chunks of that.  E.g. it seems to me that the type inference stuff
> that you mentioned would be an improvement to GDB right now, aside
> from any other further namespace improvements.

Except that it isn't without all the printing tweaks to keep output
succinct.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: current namespace game plan

[Jim Blandy]

For my own sake, at least, it would be nice to have specific examples
of code and commands that GDB gets wrong at present.  If they're as
obvious as they sound, I may try to whip up some examples myself and
turn them into test cases.

David Carlton <carlton@math.stanford.edu> writes:

> I've been tossing around namespace ideas in my head for a while, and
> they're starting to converge on a game plan that makes sense to me; I
> wanted to run it by other people.  Feel free to skip the parts of this
> message starting with "So that's the first step".
> 
> 
> The initial goal is to have GDB work about as well as it does now,
> with the addition that lookup of global symbols will be more likely to
> find symbols in namespaces where appropriate (and where the compiler
> provides enough debugging information).  There are a few ways that you
> can add namespaces that should be searched during symbol lookup:
> 
> * By explicit 'using' directives.
> * By anonymous namespaces.
> * By looking at what namespace the current function is defined in.
> * By looking at the arguments of a function that you're trying to
>   call.
> 
> I won't go into details; current compilers don't give us enough
> information to recover the first of those, but we should probably be
> able to have enough information to handle the other three cases.  And
> Daniel Berlin has posted patches to get GCC to generate the debugging
> information for the first of those.
> 
> So if I want to do a minimal change to GDB's data structures to allow
> this, the thing to do seems to be to add a C++-specific field to
> struct block that says what additional search namespaces should be
> added to the search list if you're doing name lookup within that
> block.  And then modify the symbol table readers to initialize that
> field appropriately, and modify the various symbol lookup functions
> to, when they hit the global environment, try adding all of those
> namespaces to the beginning of the symbol name that you're searching
> for.  There will also have to be some changes to C++-specific code to
> do name lookup of functions correctly based on their arguments.
> 
> This will only modify symbol lookup, not how symbols are stored:
> A::var will still be stored in some global block just like it is now.
> 
> 
> So that's the first step; that should require relatively small changes
> to GDB, and will significantly improve GDB's namespace behavior.
> After that, though, there will still be some problems that remain;
> here are some that come to mind:
> 
> * If a 'using' statement comes in the middle of a block, GDB will
>   interpret as affecting the whole block.
> 
> I don't think it's worth spending time to get rid of it; it's not that
> important, and this part of GDB's architecture is pretty centered on
> treating blocks as undifferentiated wholes.  (There are certainly
> non-namespace related bugs in this area.)
> 
> * Some C++ constructs won't get handled correctly: aliasing namespaces
>   (e.g. 'namespace B = A;') or importing single variables from other
>   namespaces ('using A::foo;').
> 
> I think the architecture from the first step might be able to be
> modified to handle the latter; maybe not, though, and it certainly
> won't be able to gracefully handle the former.  That won't come until
> further down the road.
> 
> * We get the semantics of current lookups wrong.
>   E.g. lookup_symbol_aux does the is_a_field_of_this stuff at the
>   wrong time.  I suspect that overloading is a mess, and I suspect
>   that we don't deal with static variables correctly.
> 
> These problems are more serious, and I want to solve them as part of
> the second step of this process.  So the second step will involve
> cleaning up current code, both to fix the semantics of variable lookup
> and to just refactor the design of existing code to clean it up.
> (E.g. perhaps both lookup_symbol and the code for doing overload
> resolution could call the same iterator functions to track down
> symbols.)  Hopefully Daniel Jacobowitz can get shanghaied into helping
> here.  Ideally, I'd be able to get rid of the 'symtab' argument to
> lookup_symbol as well as the global variable 'block_found' in this
> stage.
> 
> 
> Once the second step is done, there will still be problems: we still
> won't handle all C++ constructs correctly (the namespace aliasing and
> using-directives that I mentioned above), and there will still be too
> much C++-specific stuff in code that everybody has to look at, which
> is unfortunate.  I hope that, at this stage, I'll be able to
> modularize the notions of lookup algorithms so that different
> languages can implement their own weird lookup rules without affecting
> other languages.  And, as a bonus, we can speed up symbol lookup
> considerably.  That's the third step; it's vague enough that I don't
> want to talk about it now.
> 
> David Carlton
> carlton@math.stanford.edu

Re: current namespace game plan

[David Carlton]

On 04 Oct 2002 21:43:20 -0500, Jim Blandy <jimb@red-bean.com> said:

> For my own sake, at least, it would be nice to have specific
> examples of code and commands that GDB gets wrong at present.

I'm including a file with examples after my signature: break in main
and try to print out each expression listed in the body of main;
you'll have problems.  And break in B::b2 and try to print out b1;
you'll have problems.

For some of these (u1, a1, and b1, but not the foo expression, D::b1,
or e2), GDB actually prints out an answer that is incorrect, rather
than saying that there isn't a symbol by that name.  Pretty weird; I
just noticed that, and I really don't understand why GDB would do so.
I'll have to look into that, but if you happen to understand what's
going on with those examples, please tell me.

David Carlton
carlton@math.stanford.edu

namespace {
  int u1 = 1;
}

namespace A {
  int a1 = 1;
}

using namespace A;

namespace B {
  int b1 = 1;

  int b2()
  {
    return b1;
  }
}

namespace C {
  class c1 {};
  void foo(c1 x)
  {
  }
}

namespace D = B;

namespace E {
  int e1 = 1;
  int e2 = 2;
}

using E::e2;

int main()
{
  // For each of these, try to print out the expression in question,
  // as typed here.  (Well, you should probably enclose them in single
  // quotes.)  GDB either won't let you or will print out garbage.

  // GDB can't see unnamed namespaces.
  u1;
  // GDB can't see using directives.
  a1;
  // GDB can't do Koenig lookup.
  foo(C::c1());
  // GDB can't see namespace aliases.
  D::b1;
  // GDB can't see using declarations.
  e2;

  // For this one, break in B::b2 and try to print b1.  GDB won't let you.
  B::b2();
}

Re: current namespace game plan

[Elena Zannoni]

David Carlton writes:
 > On 04 Oct 2002 21:43:20 -0500, Jim Blandy <jimb@red-bean.com> said:
 > 
 > > For my own sake, at least, it would be nice to have specific
 > > examples of code and commands that GDB gets wrong at present.
 > 
 > I'm including a file with examples after my signature: break in main
 > and try to print out each expression listed in the body of main;
 > you'll have problems.  And break in B::b2 and try to print out b1;
 > you'll have problems.
 > 
 > For some of these (u1, a1, and b1, but not the foo expression, D::b1,
 > or e2), GDB actually prints out an answer that is incorrect, rather
 > than saying that there isn't a symbol by that name.  Pretty weird; I
 > just noticed that, and I really don't understand why GDB would do so.
 > I'll have to look into that, but if you happen to understand what's
 > going on with those examples, please tell me.
 > 

[back from vacation...]  

Could you start writing some test files with these examples? Even if
the tests are not passing, I find it is really useful while working on
something, to monitor my own progress. You could put these tests on
the branch(es), so that anybody can look at them. Or we could even add
them to mainline with KFAILs.

Elena


 > David Carlton
 > carlton@math.stanford.edu
 > 
 > namespace {
 >   int u1 = 1;
 > }
 > 
 > namespace A {
 >   int a1 = 1;
 > }
 > 
 > using namespace A;
 > 
 > namespace B {
 >   int b1 = 1;
 > 
 >   int b2()
 >   {
 >     return b1;
 >   }
 > }
 > 
 > namespace C {
 >   class c1 {};
 >   void foo(c1 x)
 >   {
 >   }
 > }
 > 
 > namespace D = B;
 > 
 > namespace E {
 >   int e1 = 1;
 >   int e2 = 2;
 > }
 > 
 > using E::e2;
 > 
 > int main()
 > {
 >   // For each of these, try to print out the expression in question,
 >   // as typed here.  (Well, you should probably enclose them in single
 >   // quotes.)  GDB either won't let you or will print out garbage.
 > 
 >   // GDB can't see unnamed namespaces.
 >   u1;
 >   // GDB can't see using directives.
 >   a1;
 >   // GDB can't do Koenig lookup.
 >   foo(C::c1());
 >   // GDB can't see namespace aliases.
 >   D::b1;
 >   // GDB can't see using declarations.
 >   e2;
 > 
 >   // For this one, break in B::b2 and try to print b1.  GDB won't let you.
 >   B::b2();
 > }

Re: current namespace game plan

[David Carlton]

On Wed, 16 Oct 2002 14:09:28 -0400, Elena Zannoni <ezannoni@redhat.com> said:

> Could you start writing some test files with these examples? Even if
> the tests are not passing, I find it is really useful while working on
> something, to monitor my own progress. You could put these tests on
> the branch(es), so that anybody can look at them. Or we could even add
> them to mainline with KFAILs.

Good idea.  I've added some tests to namespace.exp in
carlton_dictionary-branch that demonstrate the cases that that branch
is currently handling more-or-less correctly.  (Which, right now, is
anonymous namespaces and functions defined in a namespace, though
it doesn't handle either case _quite_ correctly yet.)

But I like your idea of adding a whole bunch of tests, even including
ones that I know won't be handled correctly, and marking them to fail.
I'll do that next.

David Carlton
carlton@math.stanford.edu

Re: current namespace game plan

[Andrew Cagney]

> On Wed, 16 Oct 2002 14:09:28 -0400, Elena Zannoni <ezannoni@redhat.com> said:
> 
> 
>> Could you start writing some test files with these examples? Even if
>> the tests are not passing, I find it is really useful while working on
>> something, to monitor my own progress. You could put these tests on
>> the branch(es), so that anybody can look at them. Or we could even add
>> them to mainline with KFAILs.
> 
> 
> Good idea.  I've added some tests to namespace.exp in
> carlton_dictionary-branch that demonstrate the cases that that branch
> is currently handling more-or-less correctly.  (Which, right now, is
> anonymous namespaces and functions defined in a namespace, though
> it doesn't handle either case _quite_ correctly yet.)
> 
> But I like your idea of adding a whole bunch of tests, even including
> ones that I know won't be handled correctly, and marking them to fail.
> I'll do that next.

This is also why KFAIL was added.  It was the political compromise that 
would allow us to add functional tests to a regression testsuite (you 
can't add tests that knowingly fail to a regression testsuite since a 
regression testsuite can only test functionality that works).

Andrew

Re: current namespace game plan

[Andrew Cagney]

David, humor me .... :-)

You've now figured out that GDB's symbol table and C++ are big nasty 
beasties that need to be tamed.  Unfortunatly they are so big, and so 
nasty that the direct approach (attack, attack) just leads to a near 
death experience - I see you're now somewhat recovered :-)

Anyway, as with a wild animal, can I suggest trying a different approach 
- confine it so that it is no longer able to lash out in all directions. 
  I see that you've even started doing this.

Anyway, to this end I've several idea's:

- Tighten the symtab - core-gdb interface
Here, the objective is to confine the symbol table readers to a very 
small arena so that you know exactly how GDB uses them.  Since GDB 
accesses things though a very tight interface, the symtab code gets 
closer to plug-and-play - drop in a new reader and test it.

- Push the partial symtab code into the stabs reader.
That way, all the partial symtab bufuddlement isn't in core GDB and you 
, and no one else, has to content with it.  Did I mention ``tighten the 
symtab - core-gdb interface''?

- eliminate all that symbol table memory mapping stuff
(Just remembered that this, last time, went into limbo) I really think, 
if symbol table reading is a problem, then better/cleaner solutions can 
be found - thinking about it, changing an already long sequence:
	.c >gcc> .s >as> .o >ld> .out >gdb
into an even longer:
	.c >gcc> .s >as> .o >ld> .out >gdb> .mmap >gdb
is like putting ``good money in after bad''.  At present we're clinging 
to it because it ``might be useful'' - just like so many of those 
unfinished ``#if 0'' blocks ``might be useful'' ....   Time to wield the 
axe?

None of these are directly name-space related.  However, I think that 
they help clear the deck so that you've a better foundation on which to 
build namespaces.

Andrew

Re: current namespace game plan

[Daniel Jacobowitz]

On Wed, Oct 23, 2002 at 07:36:22PM -0400, Andrew Cagney wrote:
> - eliminate all that symbol table memory mapping stuff
> (Just remembered that this, last time, went into limbo) I really think, 
> if symbol table reading is a problem, then better/cleaner solutions can 
> be found - thinking about it, changing an already long sequence:
> 	.c >gcc> .s >as> .o >ld> .out >gdb
> into an even longer:
> 	.c >gcc> .s >as> .o >ld> .out >gdb> .mmap >gdb
> is like putting ``good money in after bad''.  At present we're clinging 
> to it because it ``might be useful'' - just like so many of those 
> unfinished ``#if 0'' blocks ``might be useful'' ....   Time to wield the 
> axe?

I believe several people have said that Apple finished and uses this,
and that it is useful to them.  Which puts things in a different light.

> None of these are directly name-space related.  However, I think that 
> they help clear the deck so that you've a better foundation on which to 
> build namespaces.

But I don't see that most of these structural improvements are
necessary for the work David is doing...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: current namespace game plan

[Andrew Cagney]

> On Wed, Oct 23, 2002 at 07:36:22PM -0400, Andrew Cagney wrote:
> 
>> - eliminate all that symbol table memory mapping stuff
>> (Just remembered that this, last time, went into limbo) I really think, 
>> if symbol table reading is a problem, then better/cleaner solutions can 
>> be found - thinking about it, changing an already long sequence:
>> 	.c >gcc> .s >as> .o >ld> .out >gdb
>> into an even longer:
>> 	.c >gcc> .s >as> .o >ld> .out >gdb> .mmap >gdb
>> is like putting ``good money in after bad''.  At present we're clinging 
>> to it because it ``might be useful'' - just like so many of those 
>> unfinished ``#if 0'' blocks ``might be useful'' ....   Time to wield the 
>> axe?
> 
> 
> I believe several people have said that Apple finished and uses this,
> and that it is useful to them.  Which puts things in a different light.

GDB's experience with [large] merges is that they always degenerate into 
rewrites. I, unfortunatly, can't think of a reason to expect this 
feature's merge to be any different.  I also think that people working 
on cleaning up GDB's symtab code already have enough to contend with, 
without, that is, also having to worry about preserving the existing 
memmap code so that some hopothetical merge will be made easier. 
Instead I think the objective should be to focus solely on getting the 
basic code into shape, and then (and only then) consider new features 
such as this which was prototyped by Apple.

On an unrelated matter, I should respond to your last HP follow-fork 
post :-^

>> None of these are directly name-space related.  However, I think that 
>> they help clear the deck so that you've a better foundation on which to 
>> build namespaces.
> 
> 
> But I don't see that most of these structural improvements are
> necessary for the work David is doing...

As with the frame code, I've taken the more long term approach of 
cleaning up the existing code and tightening the interfaces, so that the 
CFI stuff can slip in (instead of just grafting the CFI code on top of 
the existing mechanisms as was done with x86-64).

An old old house, like GDB, needs constant maintanenace as without it, 
it will quickly fall into disrepair and crumble.

Andrew

Re: current namespace game plan

[Stan Shebs]

Andrew Cagney wrote:

>
> An old old house, like GDB, needs constant maintanenace as without it, 
> it will quickly fall into disrepair and crumble.

There's your next codename for a project: "BobVila" or just "Vila" :-)

Brings to mind a useless but amusing investigation: how many
chars in the current sources are there remaining, that were
originally typed in by RMS back in the 80s?

Stan

Re: current namespace game plan

[David Carlton]

On Wed, 23 Oct 2002 19:36:22 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Anyway, to this end I've several idea's:

> - Tighten the symtab - core-gdb interface
> Here, the objective is to confine the symbol table readers to a very
> small arena so that you know exactly how GDB uses them.  Since GDB
> accesses things though a very tight interface, the symtab code gets
> closer to plug-and-play - drop in a new reader and test it.

I'm working on doing this in ways that are useful to me.  (Well, not
quite: I'm interested in the specific task of associating names and
symbols, which is less general than "the symbol table readers".)  The
current situation isn't that bad: what's important to me is that I
know how to store data relevant to symbols (actual symbols, as opposed
to minimal symbols), how to look up names in various environments (in
a particular block, in the global environment, etc.), and how the
presence of minimal symbols and partial symbols affects this.

The building stuff that's relevant to me is already centralized in
buildsym.c.  Looking up symbols is in lookup_symbol (well,
lookup_symbol_aux) and search_symbol; I've tamed the former enough to
make me happy for now (i.e. I can now look up stuff in the global
environment by calling lookup_symbol_aux_nonlocal: the innards of that
function might be messy, but that's a separate issue), and I'll move
on to the latter soon.  The presence of partial and minimal symbols
certainly affects searches in the global environment; I've been
pleased at how effective it's been to encapsulate that all in
lookup_symbol_aux_nonlocal, however.

> - Push the partial symtab code into the stabs reader.
> That way, all the partial symtab bufuddlement isn't in core GDB and
> you, and no one else, has to content with it.

Gee, thanks, being a stabs expert is really what I have my heart set
on right now. :-)

Honestly, one of the things on my to do list is to rework how global
symbol lookup is handled, which might involve the sort of things
you're talking about.  Having said that, it keeps on going further and
further down my to do list, because I keep on getting surprised at how
little the current state of affairs gets in the way of adding
namespace support.  First, I thought I needed it to do any namespace
work; then I thought I needed it to do namespaces properly (as
first-class objects); now I'm pretty sure that I'll be able to do
namespaces as first class objects without that.  I still suspect that
I'll want to add iterators to namespace lookups (or to any symbol
lookups, really), and it's not at all clear to me that that will work
well with the current framework, but it's also not at all clear that
it won't.

> - eliminate all that symbol table memory mapping stuff

Is this xmmalloc and friends?  I just noticed that maybe three weeks
ago.  I was all ready to cut it all out until somebody claimed that
Apple uses it.  If it's true that it's useful to Apple, then it's not
clear to me that it's urgent to cut it out, since I don't think it's
particularly causing problems right now.  But I like deleting code, so
if you can build a consensus that this should go, let me know and I'll
be happy to handle it.  At the very least, we might as well check with
the relevant Apple people: if they don't think its presence in
mainline GDB is helpful to them (either because they don't use it
after all or because they've made so many changes to GDB to support it
that it won't make a difference if we axe it) then we should get rid
of it.

David Carlton
carlton@math.stanford.edu

Re: current namespace game plan

[Andrew Cagney]

> - Push the partial symtab code into the stabs reader.
>> That way, all the partial symtab bufuddlement isn't in core GDB and
>> you, and no one else, has to content with it.
> 
> 
> Gee, thanks, being a stabs expert is really what I have my heart set
> on right now. :-)

Well, I didn't say ``cleanly'' - just push.  Another verb would be 
``burry'' - burry the partial symtab code in the stabs reader :-)

Andrew