[RFA] convert blocks to dictionaries, phase 1, main part

[RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton]

This is the first of three patches that will begin the process of
converting blocks to do variable lookup via dictionaries.  (Which are
what I'd been calling environments until Andrew noted that that
clashed with the existing 'struct environ'.)

The goal of these three patches it to make sure that all blocks that
are created have a 'dict' member.  Once these patches are applied, it
will be possible to lookup variables either using the old methods
(BLOCK_SYM, etc.) or using the new dictionary methods.  Phase 2 will
then convert all accessors over to using th new dictionary methods;
phase 3 will get rid of the old methods so that the new dictionary
methods get used exclusively.

The patches in this e-mail cover the core code: they introduce the new
dictionary creation stuff necessary to carry out phase 1 (introducing
a new file dictionary.c and adding declarations to symtab.h), and
modify buildsym.c to initialize initialize BLOCK_DICT properly.  In my
next two e-mails, I'll submit patches to jv-lang.c and to mdebugread.c;
those are special cases, so they might as well be forked out
separately.

Note that I'm not including all of the new accessor methods and
dictionary creation functions in this patch: I'm only including enough
to get phase 1 completed.  If you want to see what all that stuff will
look like, it's in
<http://sources.redhat.com/ml/gdb-patches/2002-09/msg00202.html>.
Doing things this way has the advantage that I'm not submitting code
that hasn't been run through the testsuite.

I've run this through the testsuite; no new regressions.

David Carlton
carlton@math.stanford.edu

2002-09-16  David Carlton  <carlton@math.stanford.edu>

	* mdebugread.c: Delete 'maxsyms' member of parse_stack.
	(new_block): Remove argument.
	(new_symtab): Remove 'maxsyms' argument.
	(parse_symbol): Update calls to new_block.
	(parse_procedure): Ditto.
	(fixup_sigtramp): Ditto.
	(psymtab_to_symtab_1): Update calls to new_symtab; don't set
	maxsyms.
	(shrink_block): Comment out entire function.
	(parse_symbol): Remove calls to shrink_block.
	(add_symbol): Add symbol via DICT_TEMP_add_block_symbol.
	(parse_symbol): Initialize BLOCK_DICT (b) after creating new
	blocks.
	(parse_procedure): Ditto.
	(new_symtab): Ditto.
	(fixup_sigtramp): Ditto.
	* jv-lang.c (get_java_class_symtab): Initialize the BLOCK_DICT of
	the static and global blocks.
	(add_class_symtab_symbol): Add symbol via
	DICT_TEMP_add_block_symbol.
	Delete variable class_symtab_space.
	* buildsym.c (finish_block): Initialize BLOCK_DICT (block).
	* Makefile.in: Add source file dictionary.c.
	* dictionary.c: New file.
	* symtab.h: Add 'dict' member to struct block, and add initial
	dictionary-related declarations.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.258
diff -u -p -r1.258 Makefile.in
--- Makefile.in	14 Sep 2002 02:09:39 -0000	1.258
+++ Makefile.in	16 Sep 2002 20:59:22 -0000
@@ -529,7 +529,8 @@ SFILES = ada-exp.y ada-lang.c ada-typepr
 	buildsym.c c-exp.y c-lang.c c-typeprint.c c-valprint.c \
 	coffread.c \
 	complaints.c completer.c corefile.c cp-valprint.c dbxread.c \
-	demangle.c dwarfread.c dwarf2read.c elfread.c environ.c eval.c \
+	demangle.c dictionary.c dwarfread.c \
+	dwarf2read.c elfread.c environ.c eval.c \
 	event-loop.c event-top.c \
 	expprint.c f-exp.y f-lang.c f-typeprint.c f-valprint.c \
 	findvar.c regcache.c gdbarch.c arch-utils.c gdbtypes.c osabi.c \
@@ -820,7 +821,7 @@ TAGFILES_WITH_SRCDIR = $(HFILES_WITH_SRC
 COMMON_OBS = version.o blockframe.o breakpoint.o findvar.o regcache.o \
 	source.o values.o eval.o valops.o valarith.o valprint.o printcmd.o \
 	symtab.o symfile.o symmisc.o linespec.o infcmd.o infrun.o \
-	expprint.o environ.o stack.o thread.o \
+	dictionary.o expprint.o environ.o stack.o thread.o \
 	macrotab.o macrocmd.o macroexp.o macroscope.o \
 	event-loop.o event-top.o inf-loop.o completer.o \
 	gdbarch.o arch-utils.o gdbtypes.o osabi.o copying.o $(DEPFILES) \
@@ -1619,6 +1620,8 @@ dcache.o: dcache.c $(defs_h) $(dcache_h)
 delta68-nat.o: delta68-nat.c $(defs_h)
 demangle.o: demangle.c $(defs_h) $(command_h) $(gdbcmd_h) $(demangle_h) \
 	$(gdb_string_h)
+dictionary.o: $(defs_h) $(gdb_obstack_h) $(symtab_h) $(buildsym_h) \
+	$(gdb_assert_h)
 dink32-rom.o: dink32-rom.c $(defs_h) $(gdbcore_h) $(target_h) $(monitor_h) \
 	$(serial_h) $(symfile_h) $(inferior_h) $(regcache_h)
 doublest.o: doublest.c $(defs_h) $(doublest_h) $(floatformat_h) \

Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.39
diff -u -p -r1.39 symtab.h
--- symtab.h	12 Sep 2002 19:19:37 -0000	1.39
+++ symtab.h	16 Sep 2002 20:59:13 -0000
@@ -25,6 +25,7 @@
 
 /* Opaque declarations.  */
 struct obstack;
+struct dictionary;
 
 /* Don't do this; it means that if some .o's are compiled with GNU C
    and some are not (easy to do accidentally the way we configure
@@ -373,6 +374,11 @@ struct block
 
   struct block *superblock;
 
+  /* The dictionary for looking up the symbols associated to names in
+     this block.  */
+
+  struct dictionary *dict;
+
   /* Version of GCC used to compile the function corresponding
      to this block, or 0 if not compiled with GCC.  When possible,
      GCC should be compatible with the native compiler, or if that
@@ -385,6 +391,9 @@ struct block
 
   unsigned char gcc_compile_flag;
 
+  /* FIXME: carlton/2002-09-16: the rest of the members will be
+     deleted once the transition to dictionaries is finished.  */
+
   /* The symbols for this block are either in a simple linear list or
      in a simple hashtable.  Blocks which correspond to a function
      (which have a list of symbols corresponding to arguments) use
@@ -418,6 +427,7 @@ struct block
 #define BLOCK_END(bl)		(bl)->endaddr
 #define BLOCK_FUNCTION(bl)	(bl)->function
 #define BLOCK_SUPERBLOCK(bl)	(bl)->superblock
+#define BLOCK_DICT(bl)		(bl)->dict
 #define BLOCK_GCC_COMPILED(bl)	(bl)->gcc_compile_flag
 #define BLOCK_HASHTABLE(bl)	(bl)->hashtable
 
@@ -1418,5 +1428,36 @@ extern struct cleanup *make_cleanup_free
    const. */
 extern void set_main_name (const char *name);
 extern /*const */ char *main_name (void);
+
+/* Code for manipulating dictionaries.  These are used to look up the
+   symbols associated to a name.  They are represented by an opaque
+   type 'struct dictionary'.  */
+
+/* FIXME: carlton/2002-09-16: I'm adding in prototypes, etc. only as
+   needed in the patches I'm submitting, so the following list may
+   seem a bit scant.  */
+
+/* FIXME: carlton/2002-09-11: Names that start with DICT_TEMP are
+   intended to be relatively ephemeral; they'll all be deleted once
+   the transition to dictionaries is completed.  */
+
+/* The functions for creating various types of dictionaries.  */
+
+/* Create an dictionary implemented via a struct block.  */
+
+extern struct dictionary *DICT_TEMP_create_block (struct block *block);
+
+/* Create an dictionary implemented via a struct block that can grow
+   if necessary.  The dictionary is initially empty; to add symbols to
+   it, call DICT_TEMP_add_block_symbol().  */
+
+extern struct dictionary *DICT_TEMP_create_block_expandable (struct block
+							     *block);
+/* Add a symbol to an DICT_TEMP_block_expandable.  Returns the
+   associated block (which may get moved during the call in
+   question).  */
+
+extern struct block *DICT_TEMP_add_block_symbol (struct dictionary *dict,
+						 struct symbol *sym);
 
 #endif /* !defined(SYMTAB_H) */

--- /dev/null	Thu Apr 11 07:25:15 2002
+++ dictionary.c	Mon Sep 16 10:44:58 2002
@@ -0,0 +1,200 @@
+/* Routines for name->symbol translation in GDB.
+   
+   Copyright 2002 Free Software Foundation, Inc.
+
+   Contributed by David Carlton <carlton@bactrian.org>.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or (at
+   your option) any later version.
+
+   This program is distributed in the hope that it will be useful, but
+   WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+#include "defs.h"
+#include "gdb_obstack.h"
+#include "symtab.h"
+#include "buildsym.h"
+#include "gdb_assert.h"
+
+/* FIXME: carlton/2002-09-11: Names that start with DICT_TEMP are
+   intended to be relatively ephemeral; they'll all be deleted once
+   the transition to dictionaries is completed.  */
+
+/* There are various different implementations of dictionaries, all
+   accessible to the outside world via an opaque 'struct dictionary'.
+   Given that goal, and the (admittedly less important) goal not to
+   have unnecessary pointers within the data structure, the simplest
+   way to handle this seems to be to have struct dictionary have a
+   single member, which is a union of structs giving all of the
+   different implementations; each of those structs starts off with an
+   'dict_type' member which tells you what member of the union to
+   actually look at.  */
+
+/* These are the different types of implementations.  */
+
+/* FIXME: carlton/2002-09-16: I'll include the code for the various
+   implementations once they become necessary, but this enum gives you
+   a preview as to what there will be.  */
+
+enum dict_type
+  {
+    /* Symbols are stored in a (fixed-size) hash table.  */
+    DICT_HASHED,
+    /* Symbols are stored in a (fixed-size) array.  */
+    DICT_LINEAR,
+    /* Symbols are stored in an expandable array.  */
+    DICT_LINEAR_EXPANDABLE,
+    /* Symbols are stored in a struct block.  */
+    DICT_TEMP_BLOCK,
+    /* Symbols are stored in a struct block that can expand.  */
+    DICT_TEMP_BLOCK_EXPANDABLE,
+  };
+
+/* These are the data structures holding the implementations
+   themselves.  */
+
+/* In this implementation, symbols are stored in a struct block.  */
+
+struct DICT_TEMP_dictionary_block
+{
+  struct block *block;
+};
+
+/* In this implementation, symbols are stored in a struct block that
+   can expand.  */
+
+struct DICT_TEMP_dictionary_block_expandable
+{
+  struct block *block;
+  int capacity;
+};
+
+/* See comments before the definition of enum dict_type for a
+   discussion on the multiplicity of implementations.  */
+
+/* NOTE: carlton/2002-09-12: At some point, I considered having struct
+   dictionary be a struct containing one data member that was a union
+   of implementation structs, each of which started with the data
+   that's common to all implementations (currently just
+   implementation_type).  The advantage to that is that then the
+   dictionary creation functions could allocate just enough space to
+   store the current implementation, rather than enough space to store
+   the largest possible implementation.  The disavantage is that it's
+   theoretically slightly nonportable and makes it a bit more
+   tedious/error-prone to add new common data in the future.  Given
+   the small amount of wasted space, the disadvantages of that method
+   seemed to outweigh the benefits.  */
+
+struct dictionary
+{
+  enum dict_type implementation_type;
+  union
+  {
+    struct DICT_TEMP_dictionary_block DICT_TEMP_block;
+    struct DICT_TEMP_dictionary_block_expandable DICT_TEMP_block_expandable;
+  }
+  data;
+};
+
+/* Accessor macros.  */
+
+#define DICT_TYPE(d)		(d)->implementation_type
+
+/* This can be used on block_expandable dictionaries, too.  */
+
+#define DICT_TEMP_BLOCK_BLOCK(d)		(d)->data.DICT_TEMP_block.block
+
+#define DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY(d)	\
+	(d)->data.DICT_TEMP_block_expandable.capacity
+
+/* This is the initial capacity for linear_expandable dictionaries.
+   (And it's also the capacity for block_expandable dictiroments once
+   a single symbol has been added to them.)  */
+
+#define DICT_LINEAR_EXPANDABLE_INITIAL_CAPACITY	10
+
+/* Create an dictionary implemented via a struct block.
+   
+   This has a memory leak: the memory allocated via it never gets
+   freed.  (Unless the calling code calls dict_free(), which is
+   unlikely.)  But given that this implementation of dictionaries will
+   go away once the transition to dictionaries is finished and given
+   that, in practice, the amount of memory leaked will be very small,
+   I'm not inclined to fix that (e.g. by allocating on the same
+   obstack used for the argument).  */
+
+struct dictionary *
+DICT_TEMP_create_block (struct block *block)
+{
+  struct dictionary *retval;
+
+  retval = xmalloc (sizeof (struct dictionary));
+  DICT_TYPE (retval) = DICT_TEMP_BLOCK;
+  DICT_TEMP_BLOCK_BLOCK (retval) = block;
+
+  return retval;
+}
+
+/* Create an dictionary implemented via a struct block that can grow
+   if necessary.  The dictionary is initially empty; to add symbols to
+   it, call DICT_TEMP_add_block_symbol().
+
+   As with DICT_TEMP_create_block(), this has an unimportant memory
+   leak.  */
+
+struct dictionary *
+DICT_TEMP_create_block_expandable (struct block *block)
+{
+  struct dictionary *retval;
+
+  retval = xmalloc (sizeof (struct dictionary));
+  DICT_TYPE (retval) = DICT_TEMP_BLOCK_EXPANDABLE;
+  DICT_TEMP_BLOCK_BLOCK (retval) = block;
+
+  /* Set capacity to 0; the first call to DICT_TEMP_add_block_symbol()
+     will resize the block.  */
+  DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY (retval) = 0;
+
+  return retval;
+}
+
+/* Add a symbol to an DICT_TEMP_block_expandable.  Returns the
+   associated block (which may get moved during the call in
+   question).  */
+
+struct block *
+DICT_TEMP_add_block_symbol (struct dictionary *dict,
+			    struct symbol *sym)
+{
+  gdb_assert (DICT_TYPE (dict) == DICT_TEMP_BLOCK_EXPANDABLE);
+
+  int nsyms = ++BLOCK_NSYMS (DICT_TEMP_BLOCK_BLOCK (dict));
+
+  /* Do we have enough room?  If not, grow it.  */
+  if (nsyms > DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY (dict)) {
+    DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY (dict)
+      = (DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY (dict)
+	 ? 2 * DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY (dict)
+	 : DICT_LINEAR_EXPANDABLE_INITIAL_CAPACITY);
+    DICT_TEMP_BLOCK_BLOCK (dict)
+      = xrealloc (DICT_TEMP_BLOCK_BLOCK (dict),
+		  sizeof (struct block)
+		  + ((DICT_TEMP_BLOCK_EXPANDABLE_CAPACITY (dict) - 1)
+		     * sizeof (struct symbol *)));
+  }
+
+  BLOCK_SYM (DICT_TEMP_BLOCK_BLOCK (dict), nsyms - 1) = sym;
+
+  return DICT_TEMP_BLOCK_BLOCK (dict);
+}

Index: buildsym.c
===================================================================
RCS file: /cvs/src/src/gdb/buildsym.c,v
retrieving revision 1.20
diff -u -p -r1.20 buildsym.c
--- buildsym.c	10 Sep 2002 23:45:26 -0000	1.20
+++ buildsym.c	16 Sep 2002 20:59:34 -0000
@@ -294,6 +294,7 @@ finish_block (struct symbol *symbol, str
   BLOCK_END (block) = end;
   /* Superblock filled in when containing block is made */
   BLOCK_SUPERBLOCK (block) = NULL;
+  BLOCK_DICT (block) = DICT_TEMP_create_block (block);
 
   BLOCK_GCC_COMPILED (block) = processing_gcc_compilation;
 

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton]

Whoops, I included too many ChangeLog entries: here's the correct
list.

David Carlton
carlton@math.stanford.edu

2002-09-16  David Carlton  <carlton@math.stanford.edu>

	* buildsym.c (finish_block): Initialize BLOCK_DICT (block).
	* Makefile.in: Add source file dictionary.c.
	* dictionary.c: New file.
	* symtab.h: Add 'dict' member to struct block, and add initial
	dictionary-related declarations.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Jacobowitz]

On Mon, Sep 16, 2002 at 03:25:53PM -0700, David Carlton wrote:
> This is the first of three patches that will begin the process of
> converting blocks to do variable lookup via dictionaries.  (Which are
> what I'd been calling environments until Andrew noted that that
> clashed with the existing 'struct environ'.)
> 
> The goal of these three patches it to make sure that all blocks that
> are created have a 'dict' member.  Once these patches are applied, it
> will be possible to lookup variables either using the old methods
> (BLOCK_SYM, etc.) or using the new dictionary methods.  Phase 2 will
> then convert all accessors over to using th new dictionary methods;
> phase 3 will get rid of the old methods so that the new dictionary
> methods get used exclusively.

David,

I've only skimmed this, but it looks nice.  I think that you should
take Andrew's suggestion, though - create a branch to finish this work
on.  It's a bit of a hassle, since you'll need to do periodic merges to
the branch, but I don't feel right adding something with this many
temporary interfaces and FIXMEs to the trunk.  Then you can commit
patches on the branch without approval, and get it into a stabler
state.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

> On Mon, Sep 16, 2002 at 03:25:53PM -0700, David Carlton wrote:
> 
>> This is the first of three patches that will begin the process of
>> converting blocks to do variable lookup via dictionaries.  (Which are
>> what I'd been calling environments until Andrew noted that that
>> clashed with the existing 'struct environ'.)
>> 
>> The goal of these three patches it to make sure that all blocks that
>> are created have a 'dict' member.  Once these patches are applied, it
>> will be possible to lookup variables either using the old methods
>> (BLOCK_SYM, etc.) or using the new dictionary methods.  Phase 2 will
>> then convert all accessors over to using th new dictionary methods;
>> phase 3 will get rid of the old methods so that the new dictionary
>> methods get used exclusively.
> 
> 
> David,
> 
> I've only skimmed this, but it looks nice.  I think that you should
> take Andrew's suggestion, though - create a branch to finish this work
> on.  It's a bit of a hassle, since you'll need to do periodic merges to
> the branch, but I don't feel right adding something with this many
> temporary interfaces and FIXMEs to the trunk.  Then you can commit
> patches on the branch without approval, and get it into a stabler
> state.

It will still need a general thumbs up, but at least the maintainer will 
have the confidence of knowing that it really does work.

cf the recent problem with ranges.

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

David,

Some brief stylistic notes (ref 
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_13.html#SEC113)

- create a header ``dictionary.h'' / ``nametab.h'' / ... that defines 
the interfaces for this new object.

- macro's are bad m'kay :-)

- the function names should be lower case

- just implement interfaces sufficient for the immediate needs.  For 
instance, instead of providing ``enum dict_type'', just describe the 
idea.  Since we can compile with -Werror, changing internal interface, 
when there is evidence that it is actually needed, has become relativly 
easy.

- keep gdbint.texinfo in mind

- you'll want to start compiling all targets

enjoy,
Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton]

On Tue, 17 Sep 2002 10:35:53 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> I think that you should take Andrew's suggestion, though - create a
> branch to finish this work on.  It's a bit of a hassle, since you'll
> need to do periodic merges to the branch, but I don't feel right
> adding something with this many temporary interfaces and FIXMEs to
> the trunk.  Then you can commit patches on the branch without
> approval, and get it into a stabler state.

Sure, if that's what you want.  Is it okay to put up an RFA after I've
switched over just blocks, or do you want me to wait until after I've
switched over global symbols as well?

Obviously my attempt to make patches smaller by introducing temporary
interfaces wasn't a smashing success.  Ah well; I'll know better next
time...

David Carlton
carlton@math.stanford.edu

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Jacobowitz]

On Tue, Sep 17, 2002 at 10:43:42AM -0700, David Carlton wrote:
> On Tue, 17 Sep 2002 10:35:53 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> 
> > I think that you should take Andrew's suggestion, though - create a
> > branch to finish this work on.  It's a bit of a hassle, since you'll
> > need to do periodic merges to the branch, but I don't feel right
> > adding something with this many temporary interfaces and FIXMEs to
> > the trunk.  Then you can commit patches on the branch without
> > approval, and get it into a stabler state.
> 
> Sure, if that's what you want.  Is it okay to put up an RFA after I've
> switched over just blocks, or do you want me to wait until after I've
> switched over global symbols as well?
> 
> Obviously my attempt to make patches smaller by introducing temporary
> interfaces wasn't a smashing success.  Ah well; I'll know better next
> time...

Basically, at any point when you don't have a lot of temporary gunk.  I
confess, I'm of two minds about working on a branch for this sort of thing:
I consider it very impractical for things which don't break up into
pieces easily afterwards.  GCC has been using an interesting approach,
which I think we could adapt and extend here.

How about a branch which require approval just like the mainline for
large patches, although giving David a little more freedom to play
around.  Then, we'd allow large merges from the branch back to the
trunk when they were ready and tested - larger patches than we'd
normally accept all at once, because they'd already been approved.

Andrew - thoughts?  Does it have any interesting possibilities?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton]

On Tue, 17 Sep 2002 12:29:47 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

> - create a header ``dictionary.h'' / ``nametab.h'' / ... that defines
>   the interfaces for this new object.

Sure.

> - macro's are bad m'kay :-)

Even accessor macros for members of structures?  Gee, I like those:
it's a lot easier to find all places where, say, struct block's
'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
than by grepping for 'hashtable' and then sorting out which ones of
those really are referring to the 'hashtable' member as opposed to
some other use of the phrase.

Admittedly, that's less important here since the structures in
question are opaque, so they'll only be accessed within one file.  So
if you want me to move away from them, that's fine; I was just trying
to follow existing practice in symtab.h and gdbtypes.h.

The macros that are currently used (as seen in
<http://sources.redhat.com/ml/gdb-patches/2002-09/msg00202.html>,
modulo replacing 'environment' by 'dictionary', not just in the
smaller portion of it that I recently put up for RFA) fit (I think!)
into the following taxonomy:

* One-argument accessor macros for members of structures.
* Two-argument accessor macros for members of structures that are
  arrays: these accessor macros take the index into the array as a
  second argument.
* Symbolic constants.
* ALL_DICT_SYMBOLS, to make looping over all the symbols easier.

I think the only macro that is publically accessible is
ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface
to iterating over symbols in dictionaries is a lot easier than the
interface to iterating over symbols in blocks.

So if you want me to get rid of all macros (other than, presumably,
symbolic constants, though I could use the enum trick there), I can
certainly do that.

> - just implement interfaces sufficient for the immediate needs.  For
>   instance, instead of providing ``enum dict_type'', just describe
>   the idea.  Since we can compile with -Werror, changing internal
>   interface, when there is evidence that it is actually needed, has
>   become relativly easy.

dict_type really is necessary currently: I need to provide hash tables
and linear environments to support the existing functionality of
blocks.  It's just like the 'hashtable' member of struct block.

> - keep gdbint.texinfo in mind

Right.

> - you'll want to start compiling all targets

Sure.  How do I go about doing this?  I don't have access to a wide
range of machines; are there machines at Red Hat that I can use?

David Carlton
carlton@math.stanford.edu

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton]

On Tue, 17 Sep 2002 13:49:28 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Tue, Sep 17, 2002 at 10:43:42AM -0700, David Carlton wrote:

>> Is it okay to put up an RFA after I've switched over just blocks,
>> or do you want me to wait until after I've switched over global
>> symbols as well?

> Basically, at any point when you don't have a lot of temporary gunk.

Great; I'll get rid of all the DICT_TEMP gunk, finish converting
blocks over, and send out a new RFA.  That won't take a separate
branch.  And maybe before doing that I'll send out an RFA that gets
rid of BLOCK_SHOULD_SORT.

> How about a branch which require approval just like the mainline for
> large patches, although giving David a little more freedom to play
> around.  Then, we'd allow large merges from the branch back to the
> trunk when they were ready and tested - larger patches than we'd
> normally accept all at once, because they'd already been approved.

From my point of view, having a separate branch could be quite useful
when getting to the global symbols, and what you propose could be a
reasonable mechanism.  For one thing, it seems plausible to me that it
might take some amount of playing around with implementation methods
before settling on one that works well, so a branch is a natural place
for that sort of playing around to occur.  And, for another thing,
having it be in a branch increases the chances that people other than
me can be shanghaied into working on this.  (I can work on converting
appropriate code to using struct dictionaries, you can play around
with getting the interface to symbol lookups just right, and if we're
lucky Daniel Berlin can pop by every once in a while saying that he
took a break over the weekend from law school stuff to tear out all of
the psymtab->symtab translation and replace it with a new, improved
mechanism, or something like that.)

So I'm not resistant to branches generally.

Incidentally, I really should send out some e-mail that talks about
what I think the eventual interface to symbol lookups should be.

David Carlton
carlton@math.stanford.edu

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

> Basically, at any point when you don't have a lot of temporary gunk.  I
> confess, I'm of two minds about working on a branch for this sort of thing:
> I consider it very impractical for things which don't break up into
> pieces easily afterwards.  GCC has been using an interesting approach,
> which I think we could adapt and extend here.

GCC's approach relies on GCC's development cycle: break, fix, release. 
You can only pull stuff in from those branches during the ``break'' 
phase.  And during that phase, things, from what I've seen, really are 
broken (I got stuck trying to commit a patch because I couldn't 
build/test GCC for several weeks).

I also, to be honest, think that GCC has bigger problems than GDB.  With 
GDB, the basic architecture is fine (if you look at the relationships 
and ignore all the globals and messed up interfaces :-).  GCC, on the 
other hand, needs some of its fundamental data structures and algorithms 
completly replaced.

> How about a branch which require approval just like the mainline for
> large patches, although giving David a little more freedom to play
> around.  Then, we'd allow large merges from the branch back to the
> trunk when they were ready and tested - larger patches than we'd
> normally accept all at once, because they'd already been approved.
> 
> Andrew - thoughts?  Does it have any interesting possibilities?

Let me put it this way, I'm scared shitless of another HP jumbo patch.

For GDB, I think change comes in two forms:

- external / structural / interface
- internal

Internal interfaces are the ones that can easily be broken down.  Since 
everything is hidden behind an interface nothing needs to know what 
happend (just as long as it still works :-).

External / structural / interface changes are harder.  For these, I 
think (based on regcache and reggroup) there can be several changes:

- proof of concept using a branch

I think each branch should be for a single experiment -> no approval 
required but all patches should be posted so everyone can see what is 
going down (and if they like point out problems).  The purpose being to 
explore the idea and figure out exactly what the interfaces should look 
like.  (See regcache branch where I changed the interface several times 
and now that its on the mainline, the interface is still evolving.)

While playing, you'll always identify stuff that can be immediatly 
pushed into the trunk.  The MIPS generic dummy frames pulled out a 
number of things that needed fixing.

- interface changes

Using the knowledge gained, implement a new interface, possibly 
implemented using existing structures.  This is often just big and 
mechanical.

Here, for instance, I think all the existing queries are based around 
``struct block''.  Abstract them and then, behind the scenes 
re-implement the underlying structure so that it does what it is really 
ment to do -- return the correct symbol given a block.

- change internals

Which would fill in the missing bits.  This and the interface changes 
often alternate (and occasionally there is a very large lumpy patch :-)

.

Branches, however, do also involve great risk.  Since there isn't that 
pressure to get things into the trunk, it is too easy to become 
defocused and change everything else and ignore the objective.

enjoy,
Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

>> - macro's are bad m'kay :-)
> 
> 
> Even accessor macros for members of structures?  Gee, I like those:
> it's a lot easier to find all places where, say, struct block's
> 'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
> than by grepping for 'hashtable' and then sorting out which ones of
> those really are referring to the 'hashtable' member as opposed to
> some other use of the phrase.

Yep.  If you think accessor macro's are a good idea, try debugging / 
using sim/common some time :-(

Also grep -e '->hashtable' works pretty well.

> Admittedly, that's less important here since the structures in
> question are opaque, so they'll only be accessed within one file.  So
> if you want me to move away from them, that's fine; I was just trying
> to follow existing practice in symtab.h and gdbtypes.h.

Have a look at more recent code such as regcache.h.

 > ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface


> The macros that are currently used (as seen in
> <http://sources.redhat.com/ml/gdb-patches/2002-09/msg00202.html>,
> modulo replacing 'environment' by 'dictionary', not just in the
> smaller portion of it that I recently put up for RFA) fit (I think!)
> into the following taxonomy:
> 
> * One-argument accessor macros for members of structures.
> * Two-argument accessor macros for members of structures that are
>   arrays: these accessor macros take the index into the array as a
>   second argument.
> * Symbolic constants.
> * ALL_DICT_SYMBOLS, to make looping over all the symbols easier.
> 
> I think the only macro that is publically accessible is
> ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface
> to iterating over symbols in dictionaries is a lot easier than the
> interface to iterating over symbols in blocks.

The ALL_xxx_yyy() iterator can probably stay.  Its an ``accepted'' 
convention.

> So if you want me to get rid of all macros (other than, presumably,
> symbolic constants, though I could use the enum trick there), I can
> certainly do that.

Yes, please.  Symbolic constants as enum's is recommended.

>> - just implement interfaces sufficient for the immediate needs.  For
>>   instance, instead of providing ``enum dict_type'', just describe
>>   the idea.  Since we can compile with -Werror, changing internal
>>   interface, when there is evidence that it is actually needed, has
>>   become relativly easy.

> dict_type really is necessary currently: I need to provide hash tables
> and linear environments to support the existing functionality of
> blocks.  It's just like the 'hashtable' member of struct block.

Then just mention those that do apply.
(I thought DanielJ indicated that you just doing an initial linear 
implementation?)

>> - keep gdbint.texinfo in mind
> 
> 
> Right.
> 
> 
>> - you'll want to start compiling all targets
> 
> 
> Sure.  How do I go about doing this?  I don't have access to a wide
> range of machines; are there machines at Red Hat that I can use?

target's not hosts :-)  There is some sed in MAINTAINERS for generating 
the target list.  Richard E, I believe, posted a script for doing all 
the config's and builds.

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

For branching, check the CVS man pages and:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC141
but that is overkill --- you don't need the -D flag.  So something like:

cvs -d :ext:sources.redhat.com:/cvs/src rtag 
carlton_something-YYYYMMDD-branchpoint gdb+dejagnu

cvs -d :ext:sources.redhat.com:/cvs/src rtag -b -r 
carlton_something-YYYYMMDD-branchpoint carlton_something-YYYYMMDD-branch 
gdb+dejagnu

cvs -d :ext:sources.redhat.com:/cvs/src co -r 
carlton_something-YYYYMMDD-branch gdb+dejagnu

(and assume I made a typo --- check the above carefully).
Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Jacobowitz]

On Tue, Sep 17, 2002 at 02:44:56PM -0400, Andrew Cagney wrote:
> 
> >Basically, at any point when you don't have a lot of temporary gunk.  I
> >confess, I'm of two minds about working on a branch for this sort of thing:
> >I consider it very impractical for things which don't break up into
> >pieces easily afterwards.  GCC has been using an interesting approach,
> >which I think we could adapt and extend here.
> 
> GCC's approach relies on GCC's development cycle: break, fix, release. 
> You can only pull stuff in from those branches during the ``break'' 
> phase.  And during that phase, things, from what I've seen, really are 
> broken (I got stuck trying to commit a patch because I couldn't 
> build/test GCC for several weeks).
> 
> I also, to be honest, think that GCC has bigger problems than GDB.  With 
> GDB, the basic architecture is fine (if you look at the relationships 
> and ignore all the globals and messed up interfaces :-).  GCC, on the 
> other hand, needs some of its fundamental data structures and algorithms 
> completly replaced.

I think this is just as true of GDB.

> >How about a branch which require approval just like the mainline for
> >large patches, although giving David a little more freedom to play
> >around.  Then, we'd allow large merges from the branch back to the
> >trunk when they were ready and tested - larger patches than we'd
> >normally accept all at once, because they'd already been approved.
> >
> >Andrew - thoughts?  Does it have any interesting possibilities?
> 
> Let me put it this way, I'm scared shitless of another HP jumbo patch.

That's not the point.  That's why I suggested a branch which does
require approval, precisely so that we wouldn't get into that problem.
But you don't seem to like that idea, so it's dead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Jacobowitz]

On Tue, Sep 17, 2002 at 03:16:52PM -0400, Andrew Cagney wrote:
> 
> >>- macro's are bad m'kay :-)
> >
> >
> >Even accessor macros for members of structures?  Gee, I like those:
> >it's a lot easier to find all places where, say, struct block's
> >'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
> >than by grepping for 'hashtable' and then sorting out which ones of
> >those really are referring to the 'hashtable' member as opposed to
> >some other use of the phrase.
> 
> Yep.  If you think accessor macro's are a good idea, try debugging / 
> using sim/common some time :-(
> 
> Also grep -e '->hashtable' works pretty well.

Not for anything with a generic name.  More than just blocks may have a
member named ->hashtable.  An accessor macro lets you do extra checking
where necessary and be much clearer about what interfaces are being
used.

We've argued about this before, and I still hold that your distrust of
simple accessor macros serves no purpose - ESPECIALLY after all of
Jim's work to improve macro debugging.  Which feels like it has a ways
to go, but is already tremendously useful to me.

> >So if you want me to get rid of all macros (other than, presumably,
> >symbolic constants, though I could use the enum trick there), I can
> >certainly do that.
> 
> Yes, please.  Symbolic constants as enum's is recommended.
> 
> >>- just implement interfaces sufficient for the immediate needs.  For
> >>  instance, instead of providing ``enum dict_type'', just describe
> >>  the idea.  Since we can compile with -Werror, changing internal
> >>  interface, when there is evidence that it is actually needed, has
> >>  become relativly easy.
> 
> >dict_type really is necessary currently: I need to provide hash tables
> >and linear environments to support the existing functionality of
> >blocks.  It's just like the 'hashtable' member of struct block.
> 
> Then just mention those that do apply.
> (I thought DanielJ indicated that you just doing an initial linear 
> implementation?)

No, I indicated that he was doing a linear and hashed implementation. 
I meant to, at least.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[David Carlton]

On Tue, 17 Sep 2002 15:16:52 -0400, Andrew Cagney <ac131313@ges.redhat.com> said:

>> Even accessor macros for members of structures?  Gee, I like those:
>> it's a lot easier to find all places where, say, struct block's
>> 'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
>> than by grepping for 'hashtable' and then sorting out which ones of
>> those really are referring to the 'hashtable' member as opposed to
>> some other use of the phrase.

> Yep.  If you think accessor macro's are a good idea, try debugging /
> using sim/common some time :-(

All right, all right...

>> ALL_DICT_SYMBOLS; but I'm happy to get rid of that since the interface
>> to iterating over symbols in dictionaries is a lot easier than the
>> interface to iterating over symbols in blocks.

> The ALL_xxx_yyy() iterator can probably stay.  Its an ``accepted''
> convention.

Okay.

>> So if you want me to get rid of all macros (other than, presumably,
>> symbolic constants, though I could use the enum trick there), I can
>> certainly do that.

> Yes, please.  Symbolic constants as enum's is recommended.

Great, will do.

>> dict_type really is necessary currently: I need to provide hash tables
>> and linear environments to support the existing functionality of
>> blocks.  It's just like the 'hashtable' member of struct block.

> Then just mention those that do apply.
> (I thought DanielJ indicated that you just doing an initial linear
> implementation?)

No, I'm doing initial implementations that are almost exactly the same
as currently used in struct block, namely hashtable + linear.  (And
the linear has an 'expandable' variant for use by jv-lang.c and
mdebugread.c: this doesn't affect symbol searching, but it does affect
how you are allowed to add symbols.)

I don't want to get rid of hashtables, certainly: that would slow
things down enormously.

>>> - you'll want to start compiling all targets

>> Sure.  How do I go about doing this?  I don't have access to a wide
>> range of machines; are there machines at Red Hat that I can use?

> target's not hosts :-) There is some sed in MAINTAINERS for
> generating the target list.  Richard E, I believe, posted a script
> for doing all the config's and builds.

Oh, right.  Thanks, that script looks useful.

I'm curious exactly how long it will take my machine to do all those
builds - it's a 4-year-old 333 MHz PII, and I don't think it would be
proper for me to ask the math department to buy a new machine just for
working on GDB - but they might all finish overnight.  If not, they'll
certainly finish over the weekend.

David Carlton
carlton@math.stanford.edu

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

> On Tue, Sep 17, 2002 at 02:44:56PM -0400, Andrew Cagney wrote:
> 
>> 
> 
>> >Basically, at any point when you don't have a lot of temporary gunk.  I
>> >confess, I'm of two minds about working on a branch for this sort of thing:
>> >I consider it very impractical for things which don't break up into
>> >pieces easily afterwards.  GCC has been using an interesting approach,
>> >which I think we could adapt and extend here.
> 
>> 
>> GCC's approach relies on GCC's development cycle: break, fix, release. 
>> You can only pull stuff in from those branches during the ``break'' 
>> phase.  And during that phase, things, from what I've seen, really are 
>> broken (I got stuck trying to commit a patch because I couldn't 
>> build/test GCC for several weeks).
>> 
>> I also, to be honest, think that GCC has bigger problems than GDB.  With 
>> GDB, the basic architecture is fine (if you look at the relationships 
>> and ignore all the globals and messed up interfaces :-).  GCC, on the 
>> other hand, needs some of its fundamental data structures and algorithms 
>> completly replaced.
> 
> 
> I think this is just as true of GDB.

Can you expand.  GCC is getting an entirely new tree representation.  I 
don't see GDB getting anything that fundamental.

>> >How about a branch which require approval just like the mainline for
>> >large patches, although giving David a little more freedom to play
>> >around.  Then, we'd allow large merges from the branch back to the
>> >trunk when they were ready and tested - larger patches than we'd
>> >normally accept all at once, because they'd already been approved.
>> >
>> >Andrew - thoughts?  Does it have any interesting possibilities?
> 
>> 
>> Let me put it this way, I'm scared shitless of another HP jumbo patch.
> 
> 
> That's not the point.  That's why I suggested a branch which does
> require approval, precisely so that we wouldn't get into that problem.
> But you don't seem to like that idea, so it's dead.

Me not liking an idea doesn't kill it.  It is the symtab maintainers, 
and not me that would do the review and hence, they and not me would 
need to be ok with it.

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Michael Snyder]

Andrew Cagney wrote:
> 
> >> - macro's are bad m'kay :-)

I'm guessing this doesn't apply to keyboard macros?   ;-)

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

>> Yep.  If you think accessor macro's are a good idea, try debugging /
>> using sim/common some time :-(

(I can say this cos I was part responsible for that code :-)

>> Then just mention those that do apply.
>> (I thought DanielJ indicated that you just doing an initial linear
>> implementation?)
> 
> 
> No, I'm doing initial implementations that are almost exactly the same
> as currently used in struct block, namely hashtable + linear.  (And
> the linear has an 'expandable' variant for use by jv-lang.c and
> mdebugread.c: this doesn't affect symbol searching, but it does affect
> how you are allowed to add symbols.)
> 
> I don't want to get rid of hashtables, certainly: that would slow
> things down enormously.

Ok.

>>>> - you'll want to start compiling all targets
> 
> 
>>> Sure.  How do I go about doing this?  I don't have access to a wide
>>> range of machines; are there machines at Red Hat that I can use?
> 
> 
>> target's not hosts :-) There is some sed in MAINTAINERS for
>> generating the target list.  Richard E, I believe, posted a script
>> for doing all the config's and builds.
> 
> 
> Oh, right.  Thanks, that script looks useful.
> 
> I'm curious exactly how long it will take my machine to do all those
> builds - it's a 4-year-old 333 MHz PII, and I don't think it would be
> proper for me to ask the math department to buy a new machine just for
> working on GDB - but they might all finish overnight.  If not, they'll
> certainly finish over the weekend.

There are now only 16(?) targets.  I was originally building 50 targets 
(gdb not gdb+dejagnu -- dejagnu is what takes the time) using a P200 and 
it took ~8 hours.

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Berlin]

On Tuesday, September 17, 2002, at 02:44  PM, Andrew Cagney wrote:

>
>> Basically, at any point when you don't have a lot of temporary gunk.  
>> I
>> confess, I'm of two minds about working on a branch for this sort of 
>> thing:
>> I consider it very impractical for things which don't break up into
>> pieces easily afterwards.  GCC has been using an interesting approach,
>> which I think we could adapt and extend here.
>
> GCC's approach relies on GCC's development cycle: break, fix, release. 
> You can only pull stuff in from those branches during the ``break'' 
> phase.  And during that phase, things, from what I've seen, really are 
> broken (I got stuck trying to commit a patch because I couldn't 
> build/test GCC for several weeks).
>
> I also, to be honest, think that GCC has bigger problems than GDB.  
> With GDB, the basic architecture is fine (if you look at the 
> relationships and ignore all the globals and messed up interfaces :-). 
>  GCC, on the other hand, needs some of its fundamental data structures 
> and algorithms completly replaced.
This is mistaken.
Not that GCC doesn't need things completely replaced, but that GDB is 
fine. It's symbol table, debug info reader, location evaluation, etc, 
needs some of its fundamental data structures and algorithms completely 
replaced.
I'd agree that the non-debug info related architecture is fine (IE 
multiarch and whatnot), excluding the way threads are handled.

But both GCC and GDB have these problems for the same reasons:
They were not designed to handle the complexities that they are now 
required to handle.
The scale up in terms of project size has been absurd in the past few 
years.
GCC has resigned itself to deal with these cases.
GDB has ignored them for the past few years, because nobody has had the 
time to do the replacements of algorithms and data structures, to 
handle things like namespaces, etc.
This doesn't, however, mean it doesn't need to be done.
--Dan

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Berlin]

On Tuesday, September 17, 2002, at 03:16  PM, Andrew Cagney wrote:

>
>>> - macro's are bad m'kay :-)
>> Even accessor macros for members of structures?  Gee, I like those:
>> it's a lot easier to find all places where, say, struct block's
>> 'hashtable' member is being used by grepping for 'BLOCK_HASHTABLE'
>> than by grepping for 'hashtable' and then sorting out which ones of
>> those really are referring to the 'hashtable' member as opposed to
>> some other use of the phrase.
>
> Yep.  If you think accessor macro's are a good idea, try debugging / 
> using sim/common some time :-(
macro expansion is  now supported, remember.
:)

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

> 
> On Tuesday, September 17, 2002, at 02:44  PM, Andrew Cagney wrote:
> 
> 
> Basically, at any point when you don't have a lot of temporary gunk.  I
> confess, I'm of two minds about working on a branch for this sort of thing:
> I consider it very impractical for things which don't break up into
> pieces easily afterwards.  GCC has been using an interesting approach,
> which I think we could adapt and extend here.
> 
> GCC's approach relies on GCC's development cycle: break, fix, release. You can only pull stuff in from those branches during the ``break'' phase.  And during that phase, things, from what I've seen, really are broken (I got stuck trying to commit a patch because I couldn't build/test GCC for several weeks).
> 
> I also, to be honest, think that GCC has bigger problems than GDB.  With GDB, the basic architecture is fine (if you look at the relationships and ignore all the globals and messed up interfaces :-).  GCC, on the other hand, needs some of its fundamental data structures and algorithms completly replaced.
> This is mistaken.

I think of that as evolution, not a revolution.  Different view point I 
guess.

Core GDB still views the symbol table the same way, still uses the same 
basic mechanisms and the same queries (struct symbol, struct block), the 
back-end just works faster cleaner, better.

enjoy,
Andrew

> Not that GCC doesn't need things completely replaced, but that GDB is fine. It's symbol table, debug info reader, location evaluation, etc, needs some of its fundamental data structures and algorithms completely replaced.
> I'd agree that the non-debug info related architecture is fine (IE multiarch and whatnot), excluding the way threads are handled.

> But both GCC and GDB have these problems for the same reasons:
> They were not designed to handle the complexities that they are now required to handle.
> The scale up in terms of project size has been absurd in the past few years.
> GCC has resigned itself to deal with these cases.
> GDB has ignored them for the past few years, because nobody has had the time to do the replacements of algorithms and data structures, to handle things like namespaces, etc.
> This doesn't, however, mean it doesn't need to be done.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Jacobowitz]

On Tue, Sep 17, 2002 at 03:49:35PM -0400, Andrew Cagney wrote:
> >On Tue, Sep 17, 2002 at 02:44:56PM -0400, Andrew Cagney wrote:
> >
> >>
> >
> >>>Basically, at any point when you don't have a lot of temporary gunk.  I
> >>>confess, I'm of two minds about working on a branch for this sort of 
> >>thing:
> >>>I consider it very impractical for things which don't break up into
> >>>pieces easily afterwards.  GCC has been using an interesting approach,
> >>>which I think we could adapt and extend here.
> >
> >>
> >>GCC's approach relies on GCC's development cycle: break, fix, release. 
> >>You can only pull stuff in from those branches during the ``break'' 
> >>phase.  And during that phase, things, from what I've seen, really are 
> >>broken (I got stuck trying to commit a patch because I couldn't 
> >>build/test GCC for several weeks).
> >>
> >>I also, to be honest, think that GCC has bigger problems than GDB.  With 
> >>GDB, the basic architecture is fine (if you look at the relationships 
> >>and ignore all the globals and messed up interfaces :-).  GCC, on the 
> >>other hand, needs some of its fundamental data structures and algorithms 
> >>completly replaced.
> >
> >
> >I think this is just as true of GDB.
> 
> Can you expand.  GCC is getting an entirely new tree representation.  I 
> don't see GDB getting anything that fundamental.

Symbol reading could use an overhaul - as Daniel likes to point out,
there's no reason to be carrying psymtabs around for DWARF-2.

Threads support is a little pulled-together under the hood - see w_f_i
and tell me it doesn't need to be redone.  A lot more of GDB's data
structures for state should be per-thread.  GDB should be properly
asynchronized so that code can run with one thread stopped without
having to force-stop all other threads; that's a horribly intrusive
wart.

I have several times mentioned my intent to overhaul the parsing of CLI
commands before the next release, if I can find a moment.  I'm doing
equally violent things to C++ although a lot of them need to wait on
improvements in symbol lookup and eventually in the DWARF-2 reader.

We can't debug inline functions much to speak of and we could; this
requires serious infrastructure changes and serious interface changes
that no one's had a chance to work on.

In even more areas, GDB is desperately need of the rewrite that parts
of GCC are getting.  We just don't have anyone willing to do them!

> >>>How about a branch which require approval just like the mainline for
> >>>large patches, although giving David a little more freedom to play
> >>>around.  Then, we'd allow large merges from the branch back to the
> >>>trunk when they were ready and tested - larger patches than we'd
> >>>normally accept all at once, because they'd already been approved.
> >>>
> >>>Andrew - thoughts?  Does it have any interesting possibilities?
> >
> >>
> >>Let me put it this way, I'm scared shitless of another HP jumbo patch.
> >
> >
> >That's not the point.  That's why I suggested a branch which does
> >require approval, precisely so that we wouldn't get into that problem.
> >But you don't seem to like that idea, so it's dead.
> 
> Me not liking an idea doesn't kill it.  It is the symtab maintainers, 
> and not me that would do the review and hence, they and not me would 
> need to be ok with it.

I was trying to suggest it as a general development practice for GDB,
but that is obviously not going to fly.  We'll have to wait for Jim or
Elena to see how it'll fly in this case.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Daniel Berlin]

On Tuesday, September 17, 2002, at 03:49  PM, Andrew Cagney wrote:
>>> ndamental data structures and algorithms completly replaced.
>> I think this is just as true of GDB.
>
> Can you expand.  GCC is getting an entirely new tree representation.  
> I don't see GDB getting anything that fundamental.
>
No it isn't.
The IR is being changed, but the changes are not revolution, they are 
evolution, as you put it.

This is not some major data structure change, it involves changing some 
enums and macro names, and changing the functions as appropriate for 
new semantics.

Of course, i'm summarizing a large amount of code (I work on the branch 
in question every day :P) in one sentence, so someone may take issue 
with it.
But in terms of "how deep it goes", this is as fundamental as the 
changes GDB needs in the areas i mentioned.
No more, no less.

It may seem more fundamental to someone who doesn't work on the 
internals of compilers, but trust me, it's not.

--Dan

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Richard Earnshaw]

>  There is some sed in MAINTAINERS for generating 
> the target list.  Richard E, I believe, posted a script for doing all 
> the config's and builds.

Maybe we should have a contrib directory where things like this are placed.

R.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

> 
> On Tuesday, September 17, 2002, at 03:49  PM, Andrew Cagney wrote:
> ndamental data structures and algorithms completly replaced.
> I think this is just as true of GDB.
> 
> Can you expand.  GCC is getting an entirely new tree representation.  I don't see GDB getting anything that fundamental.
> 
> No it isn't.
> The IR is being changed, but the changes are not revolution, they are evolution, as you put it.
> 
> This is not some major data structure change, it involves changing some enums and macro names, and changing the functions as appropriate for new semantics.
> 
> Of course, i'm summarizing a large amount of code (I work on the branch in question every day :P) in one sentence, so someone may take issue with it.
> But in terms of "how deep it goes", this is as fundamental as the changes GDB needs in the areas i mentioned.
> No more, no less.
> 
> It may seem more fundamental to someone who doesn't work on the internals of compilers, but trust me, it's not.

Well that excludes me.

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

>>  There is some sed in MAINTAINERS for generating 
>> the target list.  Richard E, I believe, posted a script for doing all 
>> the config's and builds.
> 
> 
> Maybe we should have a contrib directory where things like this are placed.

There is src/contrib but who knows who is responsible for that. 
src/gdb/contrib or src/gdb/scripts?  I'm personally ok with 
gdb/gdb_<scriptname=mbuild?>.sh

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Richard Earnshaw]

> >>  There is some sed in MAINTAINERS for generating 
> >> the target list.  Richard E, I believe, posted a script for doing all 
> >> the config's and builds.
> > 
> > 
> > Maybe we should have a contrib directory where things like this are placed.
> 
> There is src/contrib but who knows who is responsible for that. 
> src/gdb/contrib or src/gdb/scripts?  I'm personally ok with 
> gdb/gdb_<scriptname=mbuild?>.sh

gdb/gdb_mbuild.sh it is then.

Installed.  I've tweaked my original slightly so that it takes arguments 
rather than requiring tweaking for your local environment.

New syntax is

	gdb/gdb_mbuild.sh <srcdir> <builddir> [<par_jobs>]

Where par_jobs is an optional number of parallel jobs to run (defaults to 
1)

R.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Elena Zannoni]

Richard Earnshaw writes:
 > > >>  There is some sed in MAINTAINERS for generating 
 > > >> the target list.  Richard E, I believe, posted a script for doing all 
 > > >> the config's and builds.
 > > > 
 > > > 
 > > > Maybe we should have a contrib directory where things like this are placed.
 > > 
 > > There is src/contrib but who knows who is responsible for that. 
 > > src/gdb/contrib or src/gdb/scripts?  I'm personally ok with 
 > > gdb/gdb_<scriptname=mbuild?>.sh
 > 
 > gdb/gdb_mbuild.sh it is then.
 > 
 > Installed.  I've tweaked my original slightly so that it takes arguments 
 > rather than requiring tweaking for your local environment.
 > 
 > New syntax is
 > 
 > 	gdb/gdb_mbuild.sh <srcdir> <builddir> [<par_jobs>]
 > 
 > Where par_jobs is an optional number of parallel jobs to run (defaults to 
 > 1)
 > 
 > R.

Should we document these scripts somewhere? Maybe a README file of some
sort?  Or would it be more appropriate to have a chapter/section in
the internal manual?

Elena

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Andrew Cagney]

>  There is some sed in MAINTAINERS for generating 
>> >> the target list.  Richard E, I believe, posted a script for doing all 
>> >> the config's and builds.
> 
>> > 
>> > 
>> > Maybe we should have a contrib directory where things like this are placed.
> 
>> 
>> There is src/contrib but who knows who is responsible for that. 
>> src/gdb/contrib or src/gdb/scripts?  I'm personally ok with 
>> gdb/gdb_<scriptname=mbuild?>.sh
> 
> 
> gdb/gdb_mbuild.sh it is then.
> 
> Installed.  I've tweaked my original slightly so that it takes arguments 
> rather than requiring tweaking for your local environment.
> 
> New syntax is
> 
> 	gdb/gdb_mbuild.sh <srcdir> <builddir> [<par_jobs>]
> 
> Where par_jobs is an optional number of parallel jobs to run (defaults to 
> 1)

Thanks!

Andrew

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Richard Earnshaw]

> Should we document these scripts somewhere? Maybe a README file of some
> sort?  Or would it be more appropriate to have a chapter/section in
> the internal manual?

Maybe the web pages, or wherever we say what the submission rules for 
patches are.

R.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> > That's not the point.  That's why I suggested a branch which does
> > require approval, precisely so that we wouldn't get into that problem.
> > But you don't seem to like that idea, so it's dead.
> 
> Me not liking an idea doesn't kill it.  It is the symtab maintainers,
> and not me that would do the review and hence, they and not me would
> need to be ok with it.

I don't know how Elena feels, but I generally defer to Andrew's
judgement in these sorts of things.

I'd suggest the following process:

- Get things working on a branch.  That is, produce a branch on which
  namespaces actually work --- the block -> dictionary conversion
  isn't enough.  This branch will never be merged directly; it's dead
  code.

- You'll almost certainly find some small messes which can be cleaned
  up indepenently of any other work.  These can be submitted for
  inclusion in the main sources as you go.

- You'll also probably learn some things that you'll wish you had
  known when you started.  But the design backtracking won't happen in
  the public sources --- it'll happen on your dead branch.

  Backtracking is hard enough in pristine code.  If you're
  simultaneously trying to break the change into incremental steps,
  I imagine the backtracking will be even more difficult.

- Once you've got it working, the way it really should, then you can
  decide how to submit it.  At that point, you'll have better ideas
  about how to approach this.  If some of the patches are large, so be
  it.

The downside about this process is that it looks like you do the work
twice: on the branch, and then again in the public sources.  But I
think that is partly an illusion.  What actually takes time in these
situations isn't the typing: it's the research (figuring out how the
damned thing works), and the backtracking (oh, this can't support
`using namespace' directives, we've got to do it another way).  The
"second time", when you're working from tested, running code, goes
much faster.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> The ALL_xxx_yyy() iterator can probably stay.  Its an ``accepted''
> convention.

I think the real reason these are acceptable is not because they're
"established", or anything like that.  It's because doing them without
macros is a pain in the neck, no matter how you go about it.
Functions that apply functions to each entry in the table (á là
Scheme's for-each) are very clumsy in C.  Iterator objects need to be
freed.

I think the accessors like TYPE_NAME and SYMBOL_VALUE_ADDRESS are
generally okay.  Compiling with -g3 makes a big difference.

Re: [RFA] convert blocks to dictionaries, phase 1, main part

[Jim Blandy]

Andrew Cagney <ac131313@ges.redhat.com> writes:
> >>>> - you'll want to start compiling all targets
> >
> >>> Sure.  How do I go about doing this?  I don't have access to a wide
> >>> range of machines; are there machines at Red Hat that I can use?
> >
> >> target's not hosts :-) There is some sed in MAINTAINERS for
> >> generating the target list.  Richard E, I believe, posted a script
> >> for doing all the config's and builds.
> > Oh, right.  Thanks, that script looks useful.
> > I'm curious exactly how long it will take my machine to do all those
> > builds - it's a 4-year-old 333 MHz PII, and I don't think it would be
> > proper for me to ask the math department to buy a new machine just for
> > working on GDB - but they might all finish overnight.  If not, they'll
> > certainly finish over the weekend.
> 
> There are now only 16(?) targets.  I was originally building 50
> targets (gdb not gdb+dejagnu -- dejagnu is what takes the time) using
> a P200 and it took ~8 hours.

What's the value of building across all target architectures?  It's
not clear to me that different targets will exercise different parts
of the symtab code; making sure all the debug formats are covered
should be sufficient.

It seems to me that architecture-specific issues in the symtab code
will be pretty rare, and easily picked off as they are noticed.  It's
very hard for me to imagine broad target coverage revealing problems
in the design.  For regcache work, sure --- but for the symtab, I
don't see it.