Re: add vector container type

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Mon, Jul 10, 2006 at 01:54:04PM +0200, Mark Kettenis wrote:
> Nathan, can you give a motivation why we need this in GDB?  Just the fact
> that GCC uses it and CSL developed some stuff that's based on this, is
> hardly enough to justify introducing yet another API to do memory
> allocation in GDB.  Why are the existing interfaces not good enough for
> implementing the flash programming stuff?  If this interface is better,
> are we going to convert other bits of GDB to use these interfaces?

This isn't an API for memory allocation; it's more like the STL but for
C.  Nathan's post was a little short of examples, but here's the one
from the comments:

+    An example of their use would be,                                                                  
+                                                                                
+    DEF_VEC_P(tree);   // non-managed tree vector.                         
+                                                                                                       
+    struct my_struct {                                                                                 
+      VEC(tree) *v;      // A (pointer to) a vector of tree pointers.  
+    };                                                                
+                                                                           
+    struct my_struct *s;                                                                               
+                                                                                                       
+    if (VEC_length(tree, s->v)) { we have some contents }                                              
+    VEC_safe_push(tree, s->v, decl); // append some decl onto the end                                  
+    for (ix = 0; VEC_iterate(tree, s->v, ix, elt); ix++)                                               
+      { do something with elt }                                                                        

It's a mostly type-safe, dynamic, growable array.  We've got at least a
handful of reimplementations of the same thing in GDB, and when we were
looking at needing another for memory maps, Nathan suggested we use
GCC's instead.

It offers both standard array access (you can get a pointer to the
first element) and iterators.

Easy-to-use generic data structures are a great thing and something I
think GDB is really short of.  They make writing new code a lot
simpler.

Offhand, linux-nat.c:struct simple_pid_list could be replaced with a
VEC of ints.  Other structures couldn't be entirely replaced, but could
have their linked list pointers removed, e.g. struct fork_info,
struct thread_info.  And there are probably places where the VEC
types would be useful in the symbol table.  For instance, struct
fn_fieldlist could use one; that would make the hairy code to
construct fieldlists in the dwarf reader a bit simpler.  And
there's really no need for struct badness_vector or struct
vbase, which both want to be lists.

> Could you provide a few examples of how this would be used?
> 
> Oh, and Eli will want you to write a paragraph on how to use this in
> gdbint.tex.

Me too!

-- 
Daniel Jacobowitz
CodeSourcery