This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Improved ^c support for gdb/guile
- From: ludo at gnu dot org (Ludovic CourtÃs)
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: xdje42 at gmail dot com, gdb-patches at sourceware dot org, guile-user at gnu dot org
- Date: Mon, 17 Feb 2014 17:06:26 +0100
- Subject: Re: [PATCH] Improved ^c support for gdb/guile
- Authentication-results: sourceware.org; auth=none
- References: <wrbvbwejihe dot fsf at sspiff dot org> <201402170927 dot s1H9RgXf020012 at glazunov dot sibelius dot xs4all dot nl>
Mark Kettenis <mark.kettenis@xs4all.nl> skribis:
> Didn't realize Guile used threads. I guess that's safe if the
> interpreter makes sure it never calls into GDB code concurrently.
Actually :-), Guile comes with a REPL server, which clients (such as
Geiser, an Emacs mode for Scheme) can connect to. But the server runs
in a separate thread.
My reaction as a Guiler was to spawn that server, and connect Emacs to
it so I could do live development âthe usual wayâ. But sometimes,
starting a new thread crashes GDB. When it does not, accessing the
inferiorâs memory from the server thread always fails (âCannot access
memoryâ), even though accessing the same memory region from GDBâs main
thread does work.
Anyway, I gather that this is not supported.
(Note that by default, Guile 2.0 has one signal-handling thread in
addition to its main thread. The BDW GC can also be configured to use a
separate marking thread. I donât think these are a concern for GDB
though.)
Thanks,
Ludoâ.