regno_reg_rtx and related macros

regno_reg_rtx and related macros

[Richard Kenner]

I think these are *very bad* ideas.  For one thing, the convention is that
macros be upper case.  But much more importantly, it means that you can't
simply print the expression in GDB: you need to know the full name.

Why was this done in the first place?  It seems a major step backward to me.
If we do want to do this rename, I think we have to do it that way: not as
a macro.

Re: regno_reg_rtx and related macros

[Joern Rennecke]

> I think these are *very bad* ideas.  For one thing, the convention is that
> macros be upper case.  But much more importantly, it means that you can't
> simply print the expression in GDB: you need to know the full name.

Seconded.
FWIW I think cur_insn_uid is even more important than regno_reg_rtx.

> Why was this done in the first place?  It seems a major step backward to me.
> If we do want to do this rename, I think we have to do it that way: not as
> a macro.

AFAIK it was supposed to make switching between functions easier and more
bullet-proof, and garbage collection a bit easier.
I think we should rather have a function that is used for every switch,
I.e. copy the separate global variables into current_function->emit,
change current_function, copy current_function->emit into the separate
global variables, and zero out any pointers in current_funtion->emit that
we copied out (to avoid garbage collection following stale roots).

To make garbage collection work, every pointer that is made into a global
variable again has also to be registered as a gc root.

Re: regno_reg_rtx and related macros

[Bernd Schmidt]

> I think we should rather have a function that is used for every switch,
> I.e. copy the separate global variables into current_function->emit,
> change current_function, copy current_function->emit into the separate
> global variables, and zero out any pointers in current_funtion->emit that
> we copied out (to avoid garbage collection following stale roots).
> 
> To make garbage collection work, every pointer that is made into a global
> variable again has also to be registered as a gc root.

Sounds exactly like the mess we used to have.  IMO small inconveniences in
debugging don't outweigh the benefit of having much simpler code in the
compiler.

I do agree that we should get rid of the macros.  Introducing them was
mainly a way to keep the patches small.  I'll try to come up with patches
to eliminate them soon.  At that point, I'll also change "current_function"
to have a shorter name (I think we agreed on "cfun" last time this was
discussed - right?), so we'll have less to type when debugging.

Bernd

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Bernd" == Bernd Schmidt <bernds@balti.cygnus.co.uk> writes:

    Bernd> I do agree that we should get rid of the macros.
    Bernd> Introducing them was mainly a way to keep the patches
    Bernd> small.  I'll try to come up with patches to eliminate them
    Bernd> soon.  At that point, I'll also change "current_function"
    Bernd> to have a shorter name (I think we agreed on "cfun" last
    Bernd> time this was discussed - right?), so we'll have less to
    Bernd> type when debugging.

I agree with Bernd that his changes are completely for the better.
The copying-in/coyping-out strategy is error-prone.  The current code
is far cleaner.

These debugging problems are the same one sees in any object-oriented
environment; all Bernd has done is packaged stuff up in objects.

Possibly useful would be patches to .gdbinit to abbreviate some of
these things.  For example, `pregno_rtx' could print regno_rtx of its
argument, or some such.  Also, we could create functions
(regno_rtx_fn) to use in debugging.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Geoff Keating]

Bernd Schmidt <bernds@balti.cygnus.co.uk> writes:

> > I think we should rather have a function that is used for every switch,
> > I.e. copy the separate global variables into current_function->emit,
> > change current_function, copy current_function->emit into the separate
> > global variables, and zero out any pointers in current_funtion->emit that
> > we copied out (to avoid garbage collection following stale roots).
> > 
> > To make garbage collection work, every pointer that is made into a global
> > variable again has also to be registered as a gc root.
> 
> Sounds exactly like the mess we used to have.  IMO small inconveniences in
> debugging don't outweigh the benefit of having much simpler code in the
> compiler.

Perhaps we could have both; for instance, if we have a macro

#define FOO(a,b,c) some_huge_computation + a + b + c

then, in a separate source file, do

int (FOO) (int a, int b, int c) { return FOO(a,b,c); }

this way you can write

print FOO(aa,bb,cc)

in the debugger.

This would be particularly useful for all those RTX accessor macros so
you don't have to remember which rtunion field you should be looking
at, and can copy-and-paste from source files into the debugger.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: regno_reg_rtx and related macros

[Jeffrey A Law]

  In message < jmemcigpvo.fsf@envy.cygnus.com >you write:
 > Perhaps we could have both; for instance, if we have a macro
  > 
  > #define FOO(a,b,c) some_huge_computation + a + b + c
  > 
  > then, in a separate source file, do
  > 
  > int (FOO) (int a, int b, int c) { return FOO(a,b,c); }
  > 
  > this way you can write
  > 
  > print FOO(aa,bb,cc)
  > 
  > in the debugger.
  > 
  > This would be particularly useful for all those RTX accessor macros so
  > you don't have to remember which rtunion field you should be looking
  > at, and can copy-and-paste from source files into the debugger.
This seems like a great idea to me.

jeff









  > 
  > -- 
  > - Geoffrey Keating <geoffk@cygnus.com>
  > 
  > 

Internal macros as fns for debug (was: Re: regno_reg_rtx and relatedmacros)

[Hans-Peter Nilsson]

Geoff Keating wrote:

> if we have a macro
> 
> #define FOO(a,b,c) some_huge_computation + a + b + c
> 
> then, in a separate source file, do
> 
> int (FOO) (int a, int b, int c) { return FOO(a,b,c); }
> 
> this way you can write
> 
> print FOO(aa,bb,cc)
> 
> in the debugger.
> 
> This would be particularly useful for all those RTX accessor macros so
> you don't have to remember which rtunion field you should be looking
> at, and can copy-and-paste from source files into the debugger.

Have you (or anybody else) started doing this, at least for
rtl-accessors?

If not, I'll do it right away.  An exercise if nothing else.

Sketches:
- Prototypes in rtl.h
- Functions in (new) internal-debug.c (or keep them in rtl.c?)
- Functions and declaration guarded by autoconf macro
  (HAVE_MACRONAME_AS_IDENTIFIER) for the benefit of bootstrapping
  from broken preprocessors that don't like the same token as macro
  and identifier token - if there are any.

Anyway, Merry Christmas and Happy Holidays to you all.
brgds, H-P

Re: Internal macros as fns for debug

[Doug Landauer]

> Have you (or anybody else) started doing this, at least for
> rtl-accessors?

I did something like this for most of the RTL and TREE accessors,
though in a somewhat more awkward way (I didn't realize that
surrounding the macro name in parens would prevent its expansion).


Is there a macro gcc developers use to mean "WHILE_DEBUGGING_GCC",
that these things could be #ifdef'd under?


I could send you what I have, if you're interested.  I've included
some excerpts, below.

> Sketches:
> - Prototypes in rtl.h
> - Functions in (new) internal-debug.c (or keep them in rtl.c?)

I'd say put them in a new file -- I find the TREE ones
vital to my debugging work, during those times that our gdb is
healthy enough to understand them.



> - Functions and declaration guarded by autoconf macro
>   (HAVE_MACRONAME_AS_IDENTIFIER) for the benefit of bootstrapping
>   from broken preprocessors that don't like the same token as macro
>   and identifier token - if there are any.

Perhaps my method could be used for some of those preprocessors,
although it does depend on "##" working.

 
> Anyway, Merry Christmas and Happy Holidays to you all.

And you.


Here are some of the TREE macros ...

/* TREE and RTL debugging macro functions.  What we do here is to
  instantiate each macro as a function *BY THE SAME NAME*.  Depends
  on having the '##' macro operator to paste together a name x_MACRO,
  then we define that function to call the (expanded) macro, then we
  '#undef' the MACRO, and finally define another function, named
  MACRO, to call the x_MACRO function.

  Note that the fact that we #undef the thing doesn't matter even
  if later macros need that macro:  those uses will just turn into
  function calls instead of macros!   */

#define pre_1_fn( m, rt, pt ) \
    rt x_ ## m ( pt a ) {     \
     return  m(a) ;           \
    }

#define post_1_fn( m, rt, pt ) \
    rt m ( pt a ) {            \
     return  x_ ## m (a) ;     \
    }

#define pre_2_fn( m, rt, p1, p2 ) \
    rt x_ ## m ( p1 a, p2 b ) {   \
     return  m(a,b) ;             \
    }

#define post_2_fn( m, rt, p1, p2 ) \
    rt m ( p1 a, p2 b ) {          \
     return  x_ ## m (a, b) ;      \
    }

#include "rtl.h"

/* MACROS from tree.h (single-parameter ones) */

pre_1_fn( AGGREGATE_TYPE_P, int, tree )
#undef AGGREGATE_TYPE_P
post_1_fn( AGGREGATE_TYPE_P, int, tree )

pre_1_fn( BINFO_BASETYPES, tree, tree )
#undef BINFO_BASETYPES
post_1_fn( BINFO_BASETYPES, tree, tree )

pre_1_fn( BINFO_INHERITANCE_CHAIN, tree, tree )
#undef BINFO_INHERITANCE_CHAIN
post_1_fn( BINFO_INHERITANCE_CHAIN, tree, tree )

pre_1_fn( BINFO_OFFSET, tree, tree )
#undef BINFO_OFFSET
post_1_fn( BINFO_OFFSET, tree, tree )

pre_1_fn( BINFO_OFFSET_ZEROP, int, tree )
#undef BINFO_OFFSET_ZEROP
post_1_fn( BINFO_OFFSET_ZEROP, int, tree )

pre_1_fn( BINFO_SIZE, tree, tree )
#undef BINFO_SIZE
post_1_fn( BINFO_SIZE, tree, tree )

pre_1_fn( BINFO_TYPE, tree, tree )
#undef BINFO_TYPE
post_1_fn( BINFO_TYPE, tree, tree )

pre_1_fn( BINFO_VIRTUALS, tree, tree )
#undef BINFO_VIRTUALS
post_1_fn( BINFO_VIRTUALS, tree, tree )

  ...  and lots more ...




/* MACROS from rtl.h (single-parameter ones):
   MACRO_NAME, returnType, param,
       almost always rtx, rtx */

pre_1_fn( ADDR_DIFF_VEC_FLAGS, addr_diff_vec_flags, rtx )
#undef ADDR_DIFF_VEC_FLAGS
post_1_fn( ADDR_DIFF_VEC_FLAGS, addr_diff_vec_flags, rtx )

pre_1_fn( ADDRESSOF_DECL, tree, rtx )
#undef ADDRESSOF_DECL
post_1_fn( ADDRESSOF_DECL, tree, rtx )

pre_1_fn( ADDRESSOF_REGNO, int, rtx )
#undef ADDRESSOF_REGNO
post_1_fn( ADDRESSOF_REGNO, int, rtx )

pre_1_fn( CALL_INSN_FUNCTION_USAGE, rtx, rtx )
#undef CALL_INSN_FUNCTION_USAGE
post_1_fn( CALL_INSN_FUNCTION_USAGE, rtx, rtx )

pre_1_fn( CODE_LABEL_NUMBER, int, rtx )
#undef CODE_LABEL_NUMBER
post_1_fn( CODE_LABEL_NUMBER, int, rtx )

pre_1_fn( CONST0_RTX, rtx, rtx )
#undef CONST0_RTX
post_1_fn( CONST0_RTX, rtx, rtx )


   ... and many many more ...

  and there are quite a few from cp/ptree.h as well.

Total for my method is about 2800 lines of code.  You can probably
take them and work them over with emacs or python or something to turn
them into your cleaner method of function definitions.


    -- Doug Landauer

Re: Internal macros as fns for debug

[Hans-Peter Nilsson]

On Tue, 21 Dec 1999, Doug Landauer wrote:
> > Have you (or anybody else) started doing this, at least for
> > rtl-accessors?
> 
> I did something like this for most of the RTL and TREE accessors,
> though in a somewhat more awkward way (I didn't realize that
> surrounding the macro name in parens would prevent its expansion).

Thank you!

But sorry, I think this is a bit too awkward, judging from your snippets;
no ## are allowed, and there's too much fuzz around the macro definitions.
Perhaps just my nits, don't be offended.

> Is there a macro gcc developers use to mean "WHILE_DEBUGGING_GCC",
> that these things could be #ifdef'd under?

I don't think that's necessary for providing the functions as Geoff K
showed, and would generally be an extra encumberance.

brgds, H-P

Re: regno_reg_rtx and related macros

[Bernd Schmidt]

> I think we should rather have a function that is used for every switch,
> I.e. copy the separate global variables into current_function->emit,
> change current_function, copy current_function->emit into the separate
> global variables, and zero out any pointers in current_funtion->emit that
> we copied out (to avoid garbage collection following stale roots).
> 
> To make garbage collection work, every pointer that is made into a global
> variable again has also to be registered as a gc root.

Sounds exactly like the mess we used to have.  IMO small inconveniences in
debugging don't outweigh the benefit of having much simpler code in the
compiler.

I do agree that we should get rid of the macros.  Introducing them was
mainly a way to keep the patches small.  I'll try to come up with patches
to eliminate them soon.  At that point, I'll also change "current_function"
to have a shorter name (I think we agreed on "cfun" last time this was
discussed - right?), so we'll have less to type when debugging.

Bernd

Re: regno_reg_rtx and related macros

[Joern Rennecke]

> I think these are *very bad* ideas.  For one thing, the convention is that
> macros be upper case.  But much more importantly, it means that you can't
> simply print the expression in GDB: you need to know the full name.

Seconded.
FWIW I think cur_insn_uid is even more important than regno_reg_rtx.

> Why was this done in the first place?  It seems a major step backward to me.
> If we do want to do this rename, I think we have to do it that way: not as
> a macro.

AFAIK it was supposed to make switching between functions easier and more
bullet-proof, and garbage collection a bit easier.
I think we should rather have a function that is used for every switch,
I.e. copy the separate global variables into current_function->emit,
change current_function, copy current_function->emit into the separate
global variables, and zero out any pointers in current_funtion->emit that
we copied out (to avoid garbage collection following stale roots).

To make garbage collection work, every pointer that is made into a global
variable again has also to be registered as a gc root.

Re: Internal macros as fns for debug

[Hans-Peter Nilsson]

On Tue, 21 Dec 1999, Doug Landauer wrote:
> > Have you (or anybody else) started doing this, at least for
> > rtl-accessors?
> 
> I did something like this for most of the RTL and TREE accessors,
> though in a somewhat more awkward way (I didn't realize that
> surrounding the macro name in parens would prevent its expansion).

Thank you!

But sorry, I think this is a bit too awkward, judging from your snippets;
no ## are allowed, and there's too much fuzz around the macro definitions.
Perhaps just my nits, don't be offended.

> Is there a macro gcc developers use to mean "WHILE_DEBUGGING_GCC",
> that these things could be #ifdef'd under?

I don't think that's necessary for providing the functions as Geoff K
showed, and would generally be an extra encumberance.

brgds, H-P

Internal macros as fns for debug (was: Re: regno_reg_rtx and relatedmacros)

[Hans-Peter Nilsson]

Geoff Keating wrote:

> if we have a macro
> 
> #define FOO(a,b,c) some_huge_computation + a + b + c
> 
> then, in a separate source file, do
> 
> int (FOO) (int a, int b, int c) { return FOO(a,b,c); }
> 
> this way you can write
> 
> print FOO(aa,bb,cc)
> 
> in the debugger.
> 
> This would be particularly useful for all those RTX accessor macros so
> you don't have to remember which rtunion field you should be looking
> at, and can copy-and-paste from source files into the debugger.

Have you (or anybody else) started doing this, at least for
rtl-accessors?

If not, I'll do it right away.  An exercise if nothing else.

Sketches:
- Prototypes in rtl.h
- Functions in (new) internal-debug.c (or keep them in rtl.c?)
- Functions and declaration guarded by autoconf macro
  (HAVE_MACRONAME_AS_IDENTIFIER) for the benefit of bootstrapping
  from broken preprocessors that don't like the same token as macro
  and identifier token - if there are any.

Anyway, Merry Christmas and Happy Holidays to you all.
brgds, H-P

regno_reg_rtx and related macros

[Richard Kenner]

I think these are *very bad* ideas.  For one thing, the convention is that
macros be upper case.  But much more importantly, it means that you can't
simply print the expression in GDB: you need to know the full name.

Why was this done in the first place?  It seems a major step backward to me.
If we do want to do this rename, I think we have to do it that way: not as
a macro.

Re: Internal macros as fns for debug

[Doug Landauer]

> Have you (or anybody else) started doing this, at least for
> rtl-accessors?

I did something like this for most of the RTL and TREE accessors,
though in a somewhat more awkward way (I didn't realize that
surrounding the macro name in parens would prevent its expansion).


Is there a macro gcc developers use to mean "WHILE_DEBUGGING_GCC",
that these things could be #ifdef'd under?


I could send you what I have, if you're interested.  I've included
some excerpts, below.

> Sketches:
> - Prototypes in rtl.h
> - Functions in (new) internal-debug.c (or keep them in rtl.c?)

I'd say put them in a new file -- I find the TREE ones
vital to my debugging work, during those times that our gdb is
healthy enough to understand them.



> - Functions and declaration guarded by autoconf macro
>   (HAVE_MACRONAME_AS_IDENTIFIER) for the benefit of bootstrapping
>   from broken preprocessors that don't like the same token as macro
>   and identifier token - if there are any.

Perhaps my method could be used for some of those preprocessors,
although it does depend on "##" working.

 
> Anyway, Merry Christmas and Happy Holidays to you all.

And you.


Here are some of the TREE macros ...

/* TREE and RTL debugging macro functions.  What we do here is to
  instantiate each macro as a function *BY THE SAME NAME*.  Depends
  on having the '##' macro operator to paste together a name x_MACRO,
  then we define that function to call the (expanded) macro, then we
  '#undef' the MACRO, and finally define another function, named
  MACRO, to call the x_MACRO function.

  Note that the fact that we #undef the thing doesn't matter even
  if later macros need that macro:  those uses will just turn into
  function calls instead of macros!   */

#define pre_1_fn( m, rt, pt ) \
    rt x_ ## m ( pt a ) {     \
     return  m(a) ;           \
    }

#define post_1_fn( m, rt, pt ) \
    rt m ( pt a ) {            \
     return  x_ ## m (a) ;     \
    }

#define pre_2_fn( m, rt, p1, p2 ) \
    rt x_ ## m ( p1 a, p2 b ) {   \
     return  m(a,b) ;             \
    }

#define post_2_fn( m, rt, p1, p2 ) \
    rt m ( p1 a, p2 b ) {          \
     return  x_ ## m (a, b) ;      \
    }

#include "rtl.h"

/* MACROS from tree.h (single-parameter ones) */

pre_1_fn( AGGREGATE_TYPE_P, int, tree )
#undef AGGREGATE_TYPE_P
post_1_fn( AGGREGATE_TYPE_P, int, tree )

pre_1_fn( BINFO_BASETYPES, tree, tree )
#undef BINFO_BASETYPES
post_1_fn( BINFO_BASETYPES, tree, tree )

pre_1_fn( BINFO_INHERITANCE_CHAIN, tree, tree )
#undef BINFO_INHERITANCE_CHAIN
post_1_fn( BINFO_INHERITANCE_CHAIN, tree, tree )

pre_1_fn( BINFO_OFFSET, tree, tree )
#undef BINFO_OFFSET
post_1_fn( BINFO_OFFSET, tree, tree )

pre_1_fn( BINFO_OFFSET_ZEROP, int, tree )
#undef BINFO_OFFSET_ZEROP
post_1_fn( BINFO_OFFSET_ZEROP, int, tree )

pre_1_fn( BINFO_SIZE, tree, tree )
#undef BINFO_SIZE
post_1_fn( BINFO_SIZE, tree, tree )

pre_1_fn( BINFO_TYPE, tree, tree )
#undef BINFO_TYPE
post_1_fn( BINFO_TYPE, tree, tree )

pre_1_fn( BINFO_VIRTUALS, tree, tree )
#undef BINFO_VIRTUALS
post_1_fn( BINFO_VIRTUALS, tree, tree )

  ...  and lots more ...




/* MACROS from rtl.h (single-parameter ones):
   MACRO_NAME, returnType, param,
       almost always rtx, rtx */

pre_1_fn( ADDR_DIFF_VEC_FLAGS, addr_diff_vec_flags, rtx )
#undef ADDR_DIFF_VEC_FLAGS
post_1_fn( ADDR_DIFF_VEC_FLAGS, addr_diff_vec_flags, rtx )

pre_1_fn( ADDRESSOF_DECL, tree, rtx )
#undef ADDRESSOF_DECL
post_1_fn( ADDRESSOF_DECL, tree, rtx )

pre_1_fn( ADDRESSOF_REGNO, int, rtx )
#undef ADDRESSOF_REGNO
post_1_fn( ADDRESSOF_REGNO, int, rtx )

pre_1_fn( CALL_INSN_FUNCTION_USAGE, rtx, rtx )
#undef CALL_INSN_FUNCTION_USAGE
post_1_fn( CALL_INSN_FUNCTION_USAGE, rtx, rtx )

pre_1_fn( CODE_LABEL_NUMBER, int, rtx )
#undef CODE_LABEL_NUMBER
post_1_fn( CODE_LABEL_NUMBER, int, rtx )

pre_1_fn( CONST0_RTX, rtx, rtx )
#undef CONST0_RTX
post_1_fn( CONST0_RTX, rtx, rtx )


   ... and many many more ...

  and there are quite a few from cp/ptree.h as well.

Total for my method is about 2800 lines of code.  You can probably
take them and work them over with emacs or python or something to turn
them into your cleaner method of function definitions.


    -- Doug Landauer

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Bernd" == Bernd Schmidt <bernds@balti.cygnus.co.uk> writes:

    Bernd> I do agree that we should get rid of the macros.
    Bernd> Introducing them was mainly a way to keep the patches
    Bernd> small.  I'll try to come up with patches to eliminate them
    Bernd> soon.  At that point, I'll also change "current_function"
    Bernd> to have a shorter name (I think we agreed on "cfun" last
    Bernd> time this was discussed - right?), so we'll have less to
    Bernd> type when debugging.

I agree with Bernd that his changes are completely for the better.
The copying-in/coyping-out strategy is error-prone.  The current code
is far cleaner.

These debugging problems are the same one sees in any object-oriented
environment; all Bernd has done is packaged stuff up in objects.

Possibly useful would be patches to .gdbinit to abbreviate some of
these things.  For example, `pregno_rtx' could print regno_rtx of its
argument, or some such.  Also, we could create functions
(regno_rtx_fn) to use in debugging.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Jeffrey A Law]

  In message < jmemcigpvo.fsf@envy.cygnus.com >you write:
 > Perhaps we could have both; for instance, if we have a macro
  > 
  > #define FOO(a,b,c) some_huge_computation + a + b + c
  > 
  > then, in a separate source file, do
  > 
  > int (FOO) (int a, int b, int c) { return FOO(a,b,c); }
  > 
  > this way you can write
  > 
  > print FOO(aa,bb,cc)
  > 
  > in the debugger.
  > 
  > This would be particularly useful for all those RTX accessor macros so
  > you don't have to remember which rtunion field you should be looking
  > at, and can copy-and-paste from source files into the debugger.
This seems like a great idea to me.

jeff









  > 
  > -- 
  > - Geoffrey Keating <geoffk@cygnus.com>
  > 
  > 

Re: regno_reg_rtx and related macros

[Geoff Keating]

Bernd Schmidt <bernds@balti.cygnus.co.uk> writes:

> > I think we should rather have a function that is used for every switch,
> > I.e. copy the separate global variables into current_function->emit,
> > change current_function, copy current_function->emit into the separate
> > global variables, and zero out any pointers in current_funtion->emit that
> > we copied out (to avoid garbage collection following stale roots).
> > 
> > To make garbage collection work, every pointer that is made into a global
> > variable again has also to be registered as a gc root.
> 
> Sounds exactly like the mess we used to have.  IMO small inconveniences in
> debugging don't outweigh the benefit of having much simpler code in the
> compiler.

Perhaps we could have both; for instance, if we have a macro

#define FOO(a,b,c) some_huge_computation + a + b + c

then, in a separate source file, do

int (FOO) (int a, int b, int c) { return FOO(a,b,c); }

this way you can write

print FOO(aa,bb,cc)

in the debugger.

This would be particularly useful for all those RTX accessor macros so
you don't have to remember which rtunion field you should be looking
at, and can copy-and-paste from source files into the debugger.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

Re: regno_reg_rtx and related macros

[David S. Miller]

   Date: Sat, 18 Dec 1999 23:55:04 -0700 (MST)
   From: <llewelly@198.dsl.xmission.com>

   Does gdb provide support for macro expansions?

No it doesn't, and never has.  Several vendor debuggers provide
this feature, and gdb eventually ought to as well.

Later,
David S. Miller
davem@redhat.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    I'm not talking about debuggin; I'm talking about coding.  When
    coding, as Bernd just explained, you had to know that things got
    copied around, and what they were called in both places.

True, but far more people *read* (and debug) code than *write* it, so
difficulties in the former are more important than the latter.

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> No, not really.  In an OO environment, the debugger knows
    Richard> how to display objects when the user cuts and pastes the
    Richard> same expression on his screen.  But here they are macros,
    Richard> so GDB can't do it.  That's the major difference.

That's a difference.  Dare I suggest fixing GDB?

I see this as a deficiency in the debugger, and I don't think it's
worth *in this case* obfuscating the code in GCC.  I can imagine cases
where the tradeoffs would be balanced differently, but here I think
the status quo is good.  Improvements would include, as I mentioned:

  o Fixing GDB.
  o Adding .gdbinit improvements.
  o Adding functions to use in the debugger.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    These debugging problems are the same one sees in any object-oriented
    environment; all Bernd has done is packaged stuff up in objects.

No, not really.  In an OO environment, the debugger knows how to
display objects when the user cuts and pastes the same expression on
his screen.  But here they are macros, so GDB can't do it.  That's the
major difference.

The whole point behind OO is information hiding, but that hiding needs to
be known in order to display values in the debugger using the present scheme.

Re: regno_reg_rtx and related macros

[Richard Kenner]

    That's a difference.  Dare I suggest fixing GDB?

    I see this as a deficiency in the debugger, 

How?  The debugger never sees the macros and it would be unrealistic to
have it to macro expansions even if it did.

    and I don't think it's worth *in this case* obfuscating the code in
    GCC.

The issue is what "obfuscating" means.  I certainly agree the sources should
be clean in this regard.  However, they were before this change!

  o Adding .gdbinit improvements.
  o Adding functions to use in the debugger.

Yes, this is certainly one approach, but every time another level of
macros is added, it makes debugging the compiler harder, even with this.
That's not to say it shouldn't be done, but, in my opinion, it's a real
downside to making such changes and needs to be considered when such changes
are made.

Even with these function, you have to know to call them and what they are.
That serves to *increase* the amount of information you need to know in
order to work in GCC and that amount is already quite high.

The point is that if I see the expression:

	regno_reg_rtx[i] != 0

and I'm in the debugger and want to see what the value is, the most natural
thing to do is

	print regno_reg_rtx[i]

That doesn't work and there's no way to get it to work.

Certainly we can set things up so that

	p i
	prif

prints the register info, but, as I said, that's yet one more nonobvious
thing for someone learning GCC to have to figure out.

Re: regno_reg_rtx and related macros

[Richard Kenner]

    So unrealistic that gcc even has a documented option which is supposed
    to provide such information for a debugger:

    `-gLEVEL'

     ...

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.


Right, but my understanding is that this is meant to allow *constants* to
be understood by the debugger.  Full macro expansion is quite another thing.
Certainly, I'm all for it if it can be done, but I'm somewhat dubious.

Re: regno_reg_rtx and related macros

[David S. Miller]

   Date: Sat, 18 Dec 99 20:38:39 EST
   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)

       That's a difference.  Dare I suggest fixing GDB?

       I see this as a deficiency in the debugger, 

   How?  The debugger never sees the macros and it would be unrealistic to
   have it to macro expansions even if it did.

So unrealistic that gcc even has a documented option which is supposed
to provide such information for a debugger:

`-gLEVEL'

 ...

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.

Later,
David S. Miller
davem@redhat.com

Re: regno_reg_rtx and related macros

[Bernd Schmidt]

> 
>     and I don't think it's worth *in this case* obfuscating the code in
>     GCC.
> 
> The issue is what "obfuscating" means.

We were able to eliminate a lot of code by moving all the global variables
into a structure.  We have one "struct function" now for every function we
compile, and we can switch them around by just putting a different pointer
into current_function.  This allowed us to delete the following immediately:
 - code to save/restore global variables when parsing a nested function
 - code to add gc roots for all the globals; we only need to walk the
   function structures and have no globals to worry about
 - the INLINE_HEADER rtx and all the gross code dealing with it
Subsequently, this also made it possible to simplify integrate.c a whole lot.
No need to save and restore constants anymore, we just keep the constant pool
for each function.

> The point is that if I see the expression:
> 
> 	regno_reg_rtx[i] != 0
> 
> and I'm in the debugger and want to see what the value is, the most natural
> thing to do is
> 
> 	print regno_reg_rtx[i]
> 
> That doesn't work and there's no way to get it to work.

True, but that's also the case for almost everything in gcc - simple things
like "REGNO (x)" or "NEXT_INSN (insn)" aren't debuggable either.
But in principle I agree with you that these accessor macros are bad.  If you
look into function.h you'll even find a comment to that effect.  As I said,
doing it this way kept the patches small.  Actually doing the search and
replace simply has fallen through the cracks in the last two or three months,
but I'll try to get it cleaned up quickly.

Bernd

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard>     Yup.  And, the old way meant that working on the code
    Richard> required you to know more: namely the variables and the
    Richard> places in various structs where they were squirrelled
    Richard> away as we switched between functions.

    Richard> No, you didn't need to "know" that since you could just
    Richard> look at what's in the source and pass that to the
    Richard> debugger.

I'm not talking about debuggin; I'm talking about coding.  When
coding, as Bernd just explained, you had to know that things got
copied around, and what they were called in both places.

    Richard>     I agree with Bernd; expanding the macros in the
    Richard> source is probably an improvement.  Then you can
    Richard> cut-and-paste things again.  Of course, the things will
    Richard> be longer.

    Richard> Right and *that* has a cleanliness impact!

Sure it does.  But, in my opinion, that negative impact is immensely
outweighed by all the other *positive* impacts from the change.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    Yup.  And, the old way meant that working on the code required you to
    know more: namely the variables and the places in various structs
    where they were squirrelled away as we switched between functions.

No, you didn't need to "know" that since you could just look at what's
in the source and pass that to the debugger.

    I agree with Bernd; expanding the macros in the source is probably an
    improvement.  Then you can cut-and-paste things again.  Of course, the
    things will be longer.

Right and *that* has a cleanliness impact!

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> How?  The debugger never sees the macros and it would be
    Richard> unrealistic to have it to macro expansions even if it
    Richard> did.

There are ways of representing macros in debugging information, and
there have been debuggers than expanded them just fine.  I fully
expect that this will happen in gdb when the cpplib code is finished.

    Richard> The issue is what "obfuscating" means.  I certainly agree
    Richard> the sources should be clean in this regard.  However,
    Richard> they were before this change!

Cleanliness is a matter of opinion.  In my opinion, they were not as
clean as they are now, when the information about a function is nicely
encapsulated in a single data structure, rather than littered about in
lots and lots of statics.

    Richard> downside to making such changes and needs to be
    Richard> considered when such changes are made.

I'm sure this impact *was* considered.

    Richard> prints the register info, but, as I said, that's yet one
    Richard> more nonobvious thing for someone learning GCC to have to
    Richard> figure out.

Yup.  And, the old way meant that working on the code required you to
know more: namely the variables and the places in various structs
where they were squirrelled away as we switched between functions.

I agree with Bernd; expanding the macros in the source is probably an
improvement.  Then you can cut-and-paste things again.  Of course, the
things will be longer.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[llewelly]

Does gdb provide support for macro expansions?

My (admittedly cursory) search through info gdb did not reveal hints about
  gdb support for debugging cpp macros, nor did my attempt to debug a test
  case compiled with -ggdb3 .

If gdb does provide features for debugging macros, I would appreciate
  knowing  how to make use of them.

On Sat, 18 Dec 1999, David S. Miller wrote:

>    Date: Sat, 18 Dec 99 20:38:39 EST
>    From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> 
>        That's a difference.  Dare I suggest fixing GDB?
> 
>        I see this as a deficiency in the debugger, 
> 
>    How?  The debugger never sees the macros and it would be unrealistic to
>    have it to macro expansions even if it did.
> 
> So unrealistic that gcc even has a documented option which is supposed
> to provide such information for a debugger:
> 
> `-gLEVEL'
> 
>  ...
> 
>      Level 3 includes extra information, such as all the macro
>      definitions present in the program.  Some debuggers support macro
>      expansion when you use `-g3'.
> 
> Later,
> David S. Miller
> davem@redhat.com
> 

Re: regno_reg_rtx and related macros

[Richard Kenner]

    So unrealistic that gcc even has a documented option which is supposed
    to provide such information for a debugger:

    `-gLEVEL'

     ...

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.


Right, but my understanding is that this is meant to allow *constants* to
be understood by the debugger.  Full macro expansion is quite another thing.
Certainly, I'm all for it if it can be done, but I'm somewhat dubious.

Re: regno_reg_rtx and related macros

[David S. Miller]

   Date: Sat, 18 Dec 1999 23:55:04 -0700 (MST)
   From: <llewelly@198.dsl.xmission.com>

   Does gdb provide support for macro expansions?

No it doesn't, and never has.  Several vendor debuggers provide
this feature, and gdb eventually ought to as well.

Later,
David S. Miller
davem@redhat.com

Re: regno_reg_rtx and related macros

[llewelly]

Does gdb provide support for macro expansions?

My (admittedly cursory) search through info gdb did not reveal hints about
  gdb support for debugging cpp macros, nor did my attempt to debug a test
  case compiled with -ggdb3 .

If gdb does provide features for debugging macros, I would appreciate
  knowing  how to make use of them.

On Sat, 18 Dec 1999, David S. Miller wrote:

>    Date: Sat, 18 Dec 99 20:38:39 EST
>    From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> 
>        That's a difference.  Dare I suggest fixing GDB?
> 
>        I see this as a deficiency in the debugger, 
> 
>    How?  The debugger never sees the macros and it would be unrealistic to
>    have it to macro expansions even if it did.
> 
> So unrealistic that gcc even has a documented option which is supposed
> to provide such information for a debugger:
> 
> `-gLEVEL'
> 
>  ...
> 
>      Level 3 includes extra information, such as all the macro
>      definitions present in the program.  Some debuggers support macro
>      expansion when you use `-g3'.
> 
> Later,
> David S. Miller
> davem@redhat.com
> 

Re: regno_reg_rtx and related macros

[David S. Miller]

   Date: Sat, 18 Dec 99 20:38:39 EST
   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)

       That's a difference.  Dare I suggest fixing GDB?

       I see this as a deficiency in the debugger, 

   How?  The debugger never sees the macros and it would be unrealistic to
   have it to macro expansions even if it did.

So unrealistic that gcc even has a documented option which is supposed
to provide such information for a debugger:

`-gLEVEL'

 ...

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.

Later,
David S. Miller
davem@redhat.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    I'm not talking about debuggin; I'm talking about coding.  When
    coding, as Bernd just explained, you had to know that things got
    copied around, and what they were called in both places.

True, but far more people *read* (and debug) code than *write* it, so
difficulties in the former are more important than the latter.

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard>     Yup.  And, the old way meant that working on the code
    Richard> required you to know more: namely the variables and the
    Richard> places in various structs where they were squirrelled
    Richard> away as we switched between functions.

    Richard> No, you didn't need to "know" that since you could just
    Richard> look at what's in the source and pass that to the
    Richard> debugger.

I'm not talking about debuggin; I'm talking about coding.  When
coding, as Bernd just explained, you had to know that things got
copied around, and what they were called in both places.

    Richard>     I agree with Bernd; expanding the macros in the
    Richard> source is probably an improvement.  Then you can
    Richard> cut-and-paste things again.  Of course, the things will
    Richard> be longer.

    Richard> Right and *that* has a cleanliness impact!

Sure it does.  But, in my opinion, that negative impact is immensely
outweighed by all the other *positive* impacts from the change.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    Yup.  And, the old way meant that working on the code required you to
    know more: namely the variables and the places in various structs
    where they were squirrelled away as we switched between functions.

No, you didn't need to "know" that since you could just look at what's
in the source and pass that to the debugger.

    I agree with Bernd; expanding the macros in the source is probably an
    improvement.  Then you can cut-and-paste things again.  Of course, the
    things will be longer.

Right and *that* has a cleanliness impact!

Re: regno_reg_rtx and related macros

[Bernd Schmidt]

> 
>     and I don't think it's worth *in this case* obfuscating the code in
>     GCC.
> 
> The issue is what "obfuscating" means.

We were able to eliminate a lot of code by moving all the global variables
into a structure.  We have one "struct function" now for every function we
compile, and we can switch them around by just putting a different pointer
into current_function.  This allowed us to delete the following immediately:
 - code to save/restore global variables when parsing a nested function
 - code to add gc roots for all the globals; we only need to walk the
   function structures and have no globals to worry about
 - the INLINE_HEADER rtx and all the gross code dealing with it
Subsequently, this also made it possible to simplify integrate.c a whole lot.
No need to save and restore constants anymore, we just keep the constant pool
for each function.

> The point is that if I see the expression:
> 
> 	regno_reg_rtx[i] != 0
> 
> and I'm in the debugger and want to see what the value is, the most natural
> thing to do is
> 
> 	print regno_reg_rtx[i]
> 
> That doesn't work and there's no way to get it to work.

True, but that's also the case for almost everything in gcc - simple things
like "REGNO (x)" or "NEXT_INSN (insn)" aren't debuggable either.
But in principle I agree with you that these accessor macros are bad.  If you
look into function.h you'll even find a comment to that effect.  As I said,
doing it this way kept the patches small.  Actually doing the search and
replace simply has fallen through the cracks in the last two or three months,
but I'll try to get it cleaned up quickly.

Bernd

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> How?  The debugger never sees the macros and it would be
    Richard> unrealistic to have it to macro expansions even if it
    Richard> did.

There are ways of representing macros in debugging information, and
there have been debuggers than expanded them just fine.  I fully
expect that this will happen in gdb when the cpplib code is finished.

    Richard> The issue is what "obfuscating" means.  I certainly agree
    Richard> the sources should be clean in this regard.  However,
    Richard> they were before this change!

Cleanliness is a matter of opinion.  In my opinion, they were not as
clean as they are now, when the information about a function is nicely
encapsulated in a single data structure, rather than littered about in
lots and lots of statics.

    Richard> downside to making such changes and needs to be
    Richard> considered when such changes are made.

I'm sure this impact *was* considered.

    Richard> prints the register info, but, as I said, that's yet one
    Richard> more nonobvious thing for someone learning GCC to have to
    Richard> figure out.

Yup.  And, the old way meant that working on the code required you to
know more: namely the variables and the places in various structs
where they were squirrelled away as we switched between functions.

I agree with Bernd; expanding the macros in the source is probably an
improvement.  Then you can cut-and-paste things again.  Of course, the
things will be longer.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    That's a difference.  Dare I suggest fixing GDB?

    I see this as a deficiency in the debugger, 

How?  The debugger never sees the macros and it would be unrealistic to
have it to macro expansions even if it did.

    and I don't think it's worth *in this case* obfuscating the code in
    GCC.

The issue is what "obfuscating" means.  I certainly agree the sources should
be clean in this regard.  However, they were before this change!

  o Adding .gdbinit improvements.
  o Adding functions to use in the debugger.

Yes, this is certainly one approach, but every time another level of
macros is added, it makes debugging the compiler harder, even with this.
That's not to say it shouldn't be done, but, in my opinion, it's a real
downside to making such changes and needs to be considered when such changes
are made.

Even with these function, you have to know to call them and what they are.
That serves to *increase* the amount of information you need to know in
order to work in GCC and that amount is already quite high.

The point is that if I see the expression:

	regno_reg_rtx[i] != 0

and I'm in the debugger and want to see what the value is, the most natural
thing to do is

	print regno_reg_rtx[i]

That doesn't work and there's no way to get it to work.

Certainly we can set things up so that

	p i
	prif

prints the register info, but, as I said, that's yet one more nonobvious
thing for someone learning GCC to have to figure out.

Re: regno_reg_rtx and related macros

[Mark Mitchell]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

    Richard> No, not really.  In an OO environment, the debugger knows
    Richard> how to display objects when the user cuts and pastes the
    Richard> same expression on his screen.  But here they are macros,
    Richard> so GDB can't do it.  That's the major difference.

That's a difference.  Dare I suggest fixing GDB?

I see this as a deficiency in the debugger, and I don't think it's
worth *in this case* obfuscating the code in GCC.  I can imagine cases
where the tradeoffs would be balanced differently, but here I think
the status quo is good.  Improvements would include, as I mentioned:

  o Fixing GDB.
  o Adding .gdbinit improvements.
  o Adding functions to use in the debugger.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: regno_reg_rtx and related macros

[Richard Kenner]

    These debugging problems are the same one sees in any object-oriented
    environment; all Bernd has done is packaged stuff up in objects.

No, not really.  In an OO environment, the debugger knows how to
display objects when the user cuts and pastes the same expression on
his screen.  But here they are macros, so GDB can't do it.  That's the
major difference.

The whole point behind OO is information hiding, but that hiding needs to
be known in order to display values in the debugger using the present scheme.