[patch] some mindless additions of BLOCK_ macros

[patch] some mindless additions of BLOCK_ macros

[David Carlton]

I recently noticed that the BLOCK_ macros weren't used everywhere they
could be.  I know Andrew doesn't like macros, but given that these
ones are used almost everywhere, they might as well be used
everywhere.

I've tested the parse.c part of this by doing a make check, the
x86-64-tdep.c part by doing an all targets build and noticing that it
still compiles, and the objc-lang.c part hasn't been tested at all.
They're all trivial changes, so that amount of testing seems to me to
be sufficient.

This patch seems obvious to me; if nobody complains, I'll commit it in
a day or two.

David Carlton
carlton@math.stanford.edu

2002-10-23  David Carlton  <carlton@math.stanford.edu>

	* parse.c (parse_exp_1): Use BLOCK_START.
	* x86-64-tdep.c (x86_64_skip_prologue): Use BLOCK_END,
	SYMBOL_BLOCK_VALUE.
	* objc-lang.c (find_methods): Use BLOCK_START, BLOCK_END.

Index: parse.c
===================================================================
RCS file: /cvs/src/src/gdb/parse.c,v
retrieving revision 1.29
diff -u -p -r1.29 parse.c
--- parse.c	14 Oct 2002 01:50:44 -0000	1.29
+++ parse.c	23 Oct 2002 20:23:36 -0000
@@ -1123,7 +1123,7 @@ parse_exp_1 (char **stringptr, struct bl
   if (block)
     {
       expression_context_block = block;
-      expression_context_pc = block->startaddr;
+      expression_context_pc = BLOCK_START (block);
     }
   else
     expression_context_block = get_selected_block (&expression_context_pc);
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.27
diff -u -p -r1.27 x86-64-tdep.c
--- x86-64-tdep.c	12 Sep 2002 08:39:26 -0000	1.27
+++ x86-64-tdep.c	23 Oct 2002 20:23:52 -0000
@@ -889,7 +889,7 @@ x86_64_skip_prologue (CORE_ADDR pc)
   if (!v_function || !v_function->ginfo.value.block || !v_sal.symtab)
     return pc;
 
-  endaddr = v_function->ginfo.value.block->endaddr;
+  endaddr = BLOCK_END (SYMBOL_BLOCK_VALUE (v_function));
 
   for (i = 0; i < v_sal.symtab->linetable->nitems; i++)
     if (v_sal.symtab->linetable->item[i].pc >= pc
Index: objc-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/objc-lang.c,v
retrieving revision 1.4
diff -u -p -r1.4 objc-lang.c
--- objc-lang.c	4 Oct 2002 01:18:48 -0000	1.4
+++ objc-lang.c	23 Oct 2002 20:24:04 -0000
@@ -1320,8 +1320,8 @@ find_methods (struct symtab *symtab, cha
 	continue;
 
       if (symtab)
-	if ((SYMBOL_VALUE_ADDRESS (msymbol) <  block->startaddr) ||
-	    (SYMBOL_VALUE_ADDRESS (msymbol) >= block->endaddr))
+	if ((SYMBOL_VALUE_ADDRESS (msymbol) <  BLOCK_START (block)) ||
+	    (SYMBOL_VALUE_ADDRESS (msymbol) >= BLOCK_END (block)))
 	  /* Not in the specified symtab.  */
 	  continue;
 

Re: [patch] some mindless additions of BLOCK_ macros

[Andrew Cagney]

> I recently noticed that the BLOCK_ macros weren't used everywhere they
> could be.  I know Andrew doesn't like macros, but given that these
> ones are used almost everywhere, they might as well be used
> everywhere.

Yep.

It's more that I like opaque types - it is all about `control' - with an 
opaque type it simply isn't possible to sneak in [old] code that grubs 
around in the internals.  You could consider block.[hc]?

(I need to come clean and admit that I'm quietly moving all the frame 
specific stuff out of blockframe.c and into frame.c so it can be opaque. 
  I suspect everone guessed this long ago, though :-)

> I've tested the parse.c part of this by doing a make check, the
> x86-64-tdep.c part by doing an all targets build and noticing that it
> still compiles, and the objc-lang.c part hasn't been tested at all.
> They're all trivial changes, so that amount of testing seems to me to
> be sufficient.
> 
> This patch seems obvious to me; if nobody complains, I'll commit it in
> a day or two.

I think its safe for today.

Andrew

Re: [patch] some mindless additions of BLOCK_ macros

[David Carlton]

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

>> I recently noticed that the BLOCK_ macros weren't used everywhere
>> they could be.  I know Andrew doesn't like macros, but given that
>> these ones are used almost everywhere, they might as well be used
>> everywhere.

> Yep.

> It's more that I like opaque types - it is all about `control' -
> with an opaque type it simply isn't possible to sneak in [old] code
> that grubs around in the internals.  You could consider block.[hc]?

Opaque types are good, no question about that.  Some of the macros in
symtab.h are also places where polymorphism would be helpful (c.f. the
recent INIT_DEMANGLED_NAME stuff), but I don't think people would be
too open to starting to rewrite parts of GDB in C++ just yet...

Actually, the reason why I discovered some of these places was because
I did create block.h on carlton_dictionary-branch: I got sick of
having to recompile most of GDB every time I tried to fiddle with
struct block, so I split out struct block and struct blockvector.
(But I haven't created block.c, largely because there's only two
function prototypes that seem to clearly belong in block.h.)  I posted
an RFC for splitting up symtab.h a few weeks ago, which got a tepid
response; if I decide that I like having a separate block.h, I'll
probably test the waters again in a month or so and see if I can get
approval for it on the mainline as well.  (And maybe eventually split
out other parts of symtab.h later; who knows.)

>> This patch seems obvious to me; if nobody complains, I'll commit it
>> in a day or two.

> I think its safe for today.

Okay, I'll do it when I have a moment.

David Carlton
carlton@math.stanford.edu

Re: [patch] some mindless additions of BLOCK_ macros

[Andrew Cagney]

> On Wed, 23 Oct 2002 19:04:04 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>>> I recently noticed that the BLOCK_ macros weren't used everywhere
>>> they could be.  I know Andrew doesn't like macros, but given that
>>> these ones are used almost everywhere, they might as well be used
>>> everywhere.
> 
> 
>> Yep.
> 
> 
>> It's more that I like opaque types - it is all about `control' -
>> with an opaque type it simply isn't possible to sneak in [old] code
>> that grubs around in the internals.  You could consider block.[hc]?
> 
> 
> Opaque types are good, no question about that.  Some of the macros in
> symtab.h are also places where polymorphism would be helpful (c.f. the
> recent INIT_DEMANGLED_NAME stuff), but I don't think people would be
> too open to starting to rewrite parts of GDB in C++ just yet...

It's also possible using C (just a bit garish).

Anyway, ``C++ has all the disadvantages of C, but none of the advantages 
of object oriented programming'' [gordoni].  I'd really rather wait for 
Java - universities are churning out Java programmers by the zillions.

> Actually, the reason why I discovered some of these places was because
> I did create block.h on carlton_dictionary-branch: I got sick of
> having to recompile most of GDB every time I tried to fiddle with
> struct block, so I split out struct block and struct blockvector.
> (But I haven't created block.c, largely because there's only two
> function prototypes that seem to clearly belong in block.h.)  I posted
> an RFC for splitting up symtab.h a few weeks ago, which got a tepid
> response; if I decide that I like having a separate block.h, I'll
> probably test the waters again in a month or so and see if I can get
> approval for it on the mainline as well.  (And maybe eventually split
> out other parts of symtab.h later; who knows.)

Perhaphs a different marketing approach is needed.  Instead of trying to 
sell the ``splitting of symtab.h into 50 million little files'' (which 
will have everyone running in fear :-), propose the creation of a single 
large block.[hc] that contains an opaque block/vector object (which will 
have everyone thinking - hmm, sounds good, can't hurt anyone, certainly 
do-able, even incremental so no need to branch, ... :-).

Andrew

Re: [patch] some mindless additions of BLOCK_ macros

[David Carlton]

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

> Anyway, ``C++ has all the disadvantages of C, but none of the
> advantages of object oriented programming'' [gordoni].  I'd really
> rather wait for Java - universities are churning out Java
> programmers by the zillions.

I confess, I'm getting more respect for C++ the more I learn about it.
I don't know Java too well yet, though, and certainly having garbage
collection would be nice.  (But not worth rewriting all of GDB to
get.)

> Perhaphs a different marketing approach is needed.  Instead of
> trying to sell the ``splitting of symtab.h into 50 million little
> files'' (which will have everyone running in fear :-), propose the
> creation of a single large block.[hc] that contains an opaque
> block/vector object (which will have everyone thinking - hmm, sounds
> good, can't hurt anyone, certainly do-able, even incremental so no
> need to branch, ... :-).

That's kind of what I'm doing.  Right now, the first plan is to just
try to create a separate block.h, taken straight out of symtab.h:
surely nobody could mind such an innocent action as that?  The
resulting struct block won't be any more opaque than it currently is,
though.  But the main place where it could use some opacity is in its
hashtable, nsyms, and sym members: and there I have a working version
of GDB that handles those using an opaque struct dictionary.

But I need a good excuse to spring that struct dictionary part on
people; right now, it honestly isn't adding anything other than code
cleanliness.  Having it around would have made the transition from
sorted linear blocks to hashtable blocks a lot easier; but that
transition has already happened.  And it's possible that I'll find a
good use for it in the namespace stuff that will require me to
rejigger it slightly; so it's perhaps best to wait until after I've
got a bit more of that under my belt.

David Carlton
carlton@math.stanford.edu

Re: [patch] some mindless additions of BLOCK_ macros

[Daniel Jacobowitz]

On Wed, Oct 23, 2002 at 07:04:04PM -0400, Andrew Cagney wrote:
> >I recently noticed that the BLOCK_ macros weren't used everywhere they
> >could be.  I know Andrew doesn't like macros, but given that these
> >ones are used almost everywhere, they might as well be used
> >everywhere.
> 
> Yep.
> 
> It's more that I like opaque types - it is all about `control' - with an 
> opaque type it simply isn't possible to sneak in [old] code that grubs 
> around in the internals.  You could consider block.[hc]?
> 
> (I need to come clean and admit that I'm quietly moving all the frame 
> specific stuff out of blockframe.c and into frame.c so it can be opaque. 
>  I suspect everone guessed this long ago, though :-)

Hey, I didn't even notice the trick you were pulling until yesterday :)

I admit C++ grows more attractive every passing day though.  Thing we
can take the leap, in a few years maybe?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch] some mindless additions of BLOCK_ macros

[David Carlton]

On Wed, 23 Oct 2002 19:24:24 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> I admit C++ grows more attractive every passing day though.  Thing
> we can take the leap, in a few years maybe?

Maybe I'll just start doing 'make CC=g++' on
carlton_dictionary-branch...  (It already has code in it with
hand-rolled vtables.)  Alas, that wouldn't work, but I'll just start
submitting little patches that, say, rename every variable in GDB
called 'namespace' to something else, to avoid gratuitous conflicts.

David Carlton
carlton@math.stanford.edu

Re: [patch] some mindless additions of BLOCK_ macros

[Elena Zannoni]

David Carlton writes:
 > I recently noticed that the BLOCK_ macros weren't used everywhere they
 > could be.  I know Andrew doesn't like macros, but given that these
 > ones are used almost everywhere, they might as well be used
 > everywhere.
 > 

These macros are a bit less evil. They are the precursors to accessor
functions. And Andrew likes those....

Elena