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>