Guile and GDB

Guile and GDB

[Ludovic Courtès]

Hello,

"Neil Jerram" <neil@ossau.uklinux.net> writes:

>     The first kind is that libguile includes the utility functions
>     gdb_print, gdb_eval, etc., and the variable gdb_output.  These have no
>     purpose except for developers to use from GDB when debugging
>     something.  For example, if you have a SCM x and want to know what it
>     is, you can do:
>     
>     (gdb) call gdb_print(x)
>     (gdb) p gdb_output

Actually, it's also meant to be used directly by GDB.  Normally, GDB
should try to display SCM values on its own (using its own copy of
`tags.h' and the corresponding printing procedures) and resort to
calling `gdb_print ()' when it doesn't know how to display a value.

In practice, GDB currently only supports the latter, which makes it
not-so-useful (the same result can be achieved with trivial GDB macros).
See http://sourceware.org/ml/gdb-patches/2007-07/msg00231.html .

Thanks,
Ludo'.

Re: Guile and GDB

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Actually, it's also meant to be used directly by GDB.  Normally, GDB
> should try to display SCM values on its own (using its own copy of
> `tags.h' and the corresponding printing procedures) and resort to
> calling `gdb_print ()' when it doesn't know how to display a value.
>
> In practice, GDB currently only supports the latter, which makes it
> not-so-useful (the same result can be achieved with trivial GDB macros).
> See http://sourceware.org/ml/gdb-patches/2007-07/msg00231.html .

Wow, that's pretty cool!  So your patches are actually in GDB now, are
they?

Notwithstanding, it looks like my conclusion that we don't need
GDB_INTERFACE and GDB_INTERFACE_INIT in guile.c is still correct - can
you confirm that?

(In other words, instead of using some kind of registration API, I
guess that GDB either links to libguile, or looks up the gdb_*
functions that it needs dynamically, or has an independent copy of the
libguile code that it needs to do printing.  Is that right?)

Regards,
        Neil

Re: Guile and GDB

[Ludovic Courtès]

Hi Neil,

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Actually, it's also meant to be used directly by GDB.  Normally, GDB
>> should try to display SCM values on its own (using its own copy of
>> `tags.h' and the corresponding printing procedures) and resort to
>> calling `gdb_print ()' when it doesn't know how to display a value.
>>
>> In practice, GDB currently only supports the latter, which makes it
>> not-so-useful (the same result can be achieved with trivial GDB macros).
>> See http://sourceware.org/ml/gdb-patches/2007-07/msg00231.html .
>
> Wow, that's pretty cool!  So your patches are actually in GDB now, are
> they?

Yes, but as I said, they're not too useful as it stands.

> Notwithstanding, it looks like my conclusion that we don't need
> GDB_INTERFACE and GDB_INTERFACE_INIT in guile.c is still correct - can
> you confirm that?

I think so.

> (In other words, instead of using some kind of registration API, I
> guess that GDB either links to libguile, or looks up the gdb_*
> functions that it needs dynamically, or has an independent copy of the
> libguile code that it needs to do printing.  Is that right?)

Currently, it just calls `gdb_print ()' et al. in the inferior process.
Eventually, it should use its own printers, so that it can work without
interfering the process being debugged, work on core files, etc.

Thanks,
Ludo'.

Re: Guile and GDB

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Neil,

Hi Ludo!

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> Wow, that's pretty cool!  So your patches are actually in GDB now, are
>> they?
>
> Yes, but as I said, they're not too useful as it stands.

I don't really understand why you say that.  They look useful to me.

>> Notwithstanding, it looks like my conclusion that we don't need
>> GDB_INTERFACE and GDB_INTERFACE_INIT in guile.c is still correct - can
>> you confirm that?
>
> I think so.

Thanks.

>> (In other words, instead of using some kind of registration API, I
>> guess that GDB either links to libguile, or looks up the gdb_*
>> functions that it needs dynamically, or has an independent copy of the
>> libguile code that it needs to do printing.  Is that right?)
>
> Currently, it just calls `gdb_print ()' et al. in the inferior process.
> Eventually, it should use its own printers, so that it can work without
> interfering the process being debugged, work on core files, etc.

Ah yes, of course, GDB must be able to do that...

Regards,
        Neil

Re: Guile and GDB

[Ludovic Courtès]

Hello,

Neil Jerram <neil@ossau.uklinux.net> writes:

>> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>>> Wow, that's pretty cool!  So your patches are actually in GDB now, are
>>> they?
>>
>> Yes, but as I said, they're not too useful as it stands.
>
> I don't really understand why you say that.  They look useful to me.

Because one can achieve the same result with simple GDB macros such as
those attached below (actually Andy put similar macros in the
repository).  One expects much more from a debugger, most notably being
able to analyze data without running code in the inferior process.

Thanks,
Ludo'.

--8<---------------cut here---------------start------------->8---
# GNU Guile debugging macros.

set $SCM_BOOL_F      = 0x004
set $SCM_BOOL_T      = 0x104
set $SCM_UNDEFINED   = 0x204
set $SCM_EOF_VAL     = 0x304
set $SCM_EOL         = 0x404
set $SCM_UNSPECIFIED = 0x504

define guile-backtrace
  call scm_make_stack ($SCM_BOOL_T, $SCM_EOL)
  call scm_stack_length ($)
  call scm_current_output_port ()
  call scm_display_backtrace_with_highlights ($$2, \
           $, \
           $SCM_BOOL_F, $$, \
	   $SCM_UNDEFINED)
end
document guile-backtrace
Show a Guile Scheme-level stack.
end

define guile-print
  if $argc == 1
    call scm_current_output_port ()
    call scm_write ($arg0, $)
  end
end
document guile-print
Print the value of an `SCM' object.
end

define guile-ref
  if $argc == 1
    call scm_c_lookup ($arg0)
  end
end
document guile-ref
Return the value of the given binding.
end

define guile-pre-installation
  set environment LD_LIBRARY_PATH /home/ludo/src/guile/libguile/.libs:/home/ludo/src/guile/srfi/.libs
  set environment GUILE_LOAD_PATH /home/ludo/src/guile
end
document guile-pre-installation
Setup the right environment for a pre-installation Guile.
end
--8<---------------cut here---------------end--------------->8---

Re: Guile and GDB

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Because one can achieve the same result with simple GDB macros such as
> those attached below (actually Andy put similar macros in the
> repository).

Thanks for explaining, I understand now.  Although I still think that
it's a useful extra benefit for the _GDB_ backtrace to show SCM data
nicely, as you showed in your examples at
http://sourceware.org/ml/gdb-patches/2007-07/msg00231.html.

> One expects much more from a debugger, most notably being
> able to analyze data without running code in the inferior process.
 
It's all running code of one kind or another; is there really a clear
distinction here?

Regards,
        Neil

Re: Guile and GDB

[Ludovic Courtès]

Hello!

Neil Jerram <neil@ossau.uklinux.net> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Because one can achieve the same result with simple GDB macros such as
>> those attached below (actually Andy put similar macros in the
>> repository).
>
> Thanks for explaining, I understand now.  Although I still think that
> it's a useful extra benefit for the _GDB_ backtrace to show SCM data
> nicely, as you showed in your examples at
> http://sourceware.org/ml/gdb-patches/2007-07/msg00231.html.

Well, admittedly, it looks nice.  :-)

>> One expects much more from a debugger, most notably being
>> able to analyze data without running code in the inferior process.
>  
> It's all running code of one kind or another; is there really a clear
> distinction here?

Yes: running code in the process being debugged is intrusive, and it
interferes with the behavior one is trying to observe.  It's also
impossible in many cases, e.g., when the inferior process was stopped
due to SIGSEGV, or when inspecting from a core file.

Thanks,
Ludo'.

Re: Guile and GDB

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

>> It's all running code of one kind or another; is there really a clear
>> distinction here?
>
> Yes: running code in the process being debugged is intrusive, and it
> interferes with the behavior one is trying to observe.  It's also
> impossible in many cases, e.g., when the inferior process was stopped
> due to SIGSEGV, or when inspecting from a core file.

Ah yes, I had forgotten about the process separation (i.e. the GDB
process being different from the inferior).  I completely see your
point now.

Regards,
        Neil