Re: [Chicken-hackers] [PATCH] Some small debugger data and wire protocol improvements
> > > > There is a protocol_version test in feathers.tcl ... Is this what you mean? > > Ah, I suppose so. I couldn't find it so quickly; where is it in the C code? C_DEBUG_PROTOCOL_VERSION > What happens when the version is different? feathers aborts. felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Some small debugger data and wire protocol improvements
On Sun, Nov 25, 2018 at 07:29:57PM +0100, felix.winkelm...@bevuta.com wrote: > > > > One thing though; I think we need to add some sort of versioning support > > to the debugger protocol so when you run feathers to talk to a program > > compiled with a different version of CHICKEN, this is going to fail. > > > > I think this is a situation we ought to at least detect and warn or error > > on, so the user won't be left with confusing behaviour. This is quite > > likely when you consider the debugger can be used remotely; there is no > > guarantee that the program on the remote end is using the same version > > of the debugger protocol. > > > > There is a protocol_version test in feathers.tcl ... Is this what you mean? Ah, I suppose so. I couldn't find it so quickly; where is it in the C code? What happens when the version is different? Maybe we should simply bump that version then. Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Some small debugger data and wire protocol improvements
> > One thing though; I think we need to add some sort of versioning support > to the debugger protocol so when you run feathers to talk to a program > compiled with a different version of CHICKEN, this is going to fail. > > I think this is a situation we ought to at least detect and warn or error > on, so the user won't be left with confusing behaviour. This is quite > likely when you consider the debugger can be used remotely; there is no > guarantee that the program on the remote end is using the same version > of the debugger protocol. > There is a protocol_version test in feathers.tcl ... Is this what you mean? felix ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Some small debugger data and wire protocol improvements
On Sun, Jul 22, 2018 at 11:45:17PM +1200, Evan Hanson wrote: > Hello hackers, > > Here are a few small changes to the debugging backend, to address some > snags I hit into while working on a program that uses the debugger > protocol. As the commit message says, they're intended to "simplify the > use of the debugging protocol by client applications by fixing a few > oddities that would otherwise need to be coded around on the client > side." If you have any questions, just let me know. Hi Evan, I've finally gotten around to taking a look and even though I don't know all that much about the debugger, the change looks fine. One thing though; I think we need to add some sort of versioning support to the debugger protocol so when you run feathers to talk to a program compiled with a different version of CHICKEN, this is going to fail. I think this is a situation we ought to at least detect and warn or error on, so the user won't be left with confusing behaviour. This is quite likely when you consider the debugger can be used remotely; there is no guarantee that the program on the remote end is using the same version of the debugger protocol. > I also have an accompanying patch to update the debugger-protocol egg, > which can be applied once this looks OK to you. Please do! Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
Re: [Chicken-hackers] [PATCH] Some small debugger data and wire protocol improvements
On Sun, Jul 22, 2018 at 11:45:17PM +1200, Evan Hanson wrote: > Hello hackers, > > Here are a few small changes to the debugging backend, to address some > snags I hit into while working on a program that uses the debugger > protocol. As the commit message says, they're intended to "simplify the > use of the debugging protocol by client applications by fixing a few > oddities that would otherwise need to be coded around on the client > side." If you have any questions, just let me know. I'd prefer to postpone this to 5.1, let's avoid making any large changes to 5.0, OK? Cheers, Peter signature.asc Description: PGP signature ___ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
[Chicken-hackers] [PATCH] Some small debugger data and wire protocol improvements
Hello hackers,
Here are a few small changes to the debugging backend, to address some
snags I hit into while working on a program that uses the debugger
protocol. As the commit message says, they're intended to "simplify the
use of the debugging protocol by client applications by fixing a few
oddities that would otherwise need to be coded around on the client
side." If you have any questions, just let me know.
I also have an accompanying patch to update the debugger-protocol egg,
which can be applied once this looks OK to you.
Happy Sunday,
Evan
>From 1b325fd658c01f3e1a540b9567cf2f53be337da7 Mon Sep 17 00:00:00 2001
From: Evan Hanson
Date: Sun, 22 Jul 2018 22:23:17 +1200
Subject: [PATCH] Some small debugger data and wire protocol improvements
These changes are intended to simplify the use of the debugging protocol
by client applications by fixing a few oddities that would otherwise
need to be coded around on the client side.
Populate the "location" slot for call events. Previously, the debugging
stub would send Scheme filenames and line number information to clients
in the "location" slot for all except for 'call' events, which would
instead have the location as a prefix of the "value" slot. Move this
source information into the "location" slot so that all events sent to
the client use the fields in the same way in all cases.
Send missing values to the client as `#f' rather than as strings.
Previously, the debugging stub would send missing values to the client
as either an empty string or a string containing "#f" (a byproduct of
using `->string' during code generation), but it's easier to handle the
"real" #f token on the client side. So, introduce a `send_string_value'
procedure that sends C strings to the client as either a quoted string
or #f if the string is NULL or empty, rather than as strings in all
cases. Update call sites to indicate missing events and file locations
as NULL in C and #f on the wire. This requires bumping the predefined
integer value definitions by one, since event locations may now be NULL
if no Scheme or C source information is available. Rename `send_value'
to `send_scheme_value' for consistency with `send_string_value'. Update
feathers.tcl as necessary.
Emit C source info as a single string, rather than as a separate
filename and line number, to simplify its use in dbg-stub.c.
Use symbols for `##core#debug-event' node event types in core.scm.
Previously, these were strings in some places and symbols in others.
---
c-backend.scm | 4 +++-
chicken.h | 26 ++
core.scm | 26 ++
dbg-stub.c| 49 +++--
feathers.tcl | 43 +++
runtime.c | 2 +-
support.scm | 12 +++-
7 files changed, 97 insertions(+), 65 deletions(-)
diff --git a/c-backend.scm b/c-backend.scm
index c6514ecd..ee74d2b9 100644
--- a/c-backend.scm
+++ b/c-backend.scm
@@ -971,7 +971,9 @@
(gen #t "{" (second info) ",0,")
(for-each
(lambda (x)
- (gen "C_text(\"" (backslashify (->string x)) "\"),"))
+ (if (not x)
+ (gen "NULL,")
+ (gen "C_text(\"" (backslashify (->string x)) "\"),")))
(cddr info))
(gen "},"))
(sort dbg-info-table (lambda (i1 i2) (< (car i1) (car i2)
diff --git a/chicken.h b/chicken.h
index 1bbd1ba6..dd65be42 100644
--- a/chicken.h
+++ b/chicken.h
@@ -784,6 +784,9 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
#define CHICKEN_default_toplevel ((void *)C_default_5fstub_toplevel)
+#define C__STR1(x) #x
+#define C__STR2(x) C__STR1(x)
+
#define C_align4(n)(((n) + 3) & ~3)
#define C_align8(n)(((n) + 7) & ~7)
#define C_align16(n) (((n) + 15) & ~15)
@@ -826,10 +829,9 @@ typedef void (C_ccall *C_proc)(C_word, C_word *) C_noret;
*/
# define C_VAL1(x) C__PREV_TMPST.n1
# define C_VAL2(x) C__PREV_TMPST.n2
-# define C__STR(x) #x
# define C__CHECK_panic(a,s,f,l) \
((a) ? (void)0 : \
- C_panic_hook(C_text("Low-level type assertion " s " failed at " f ":" C__STR(l
+ C_panic_hook(C_text("Low-level type assertion " s " failed at " f ":" C__STR1(l
# define C__CHECK_core(v,a,s,x) \
({ struct { \
typeof(v) n1; \
@@ -1644,16 +1646,16 @@ typedef struct C_DEBUG_INFO {
C_char *val;
} C_DEBUG_INFO;
-#define C_DEBUG_CALL0
-#define C_DEBUG_GLOBAL_ASSIGN 1
-#define C_DEBUG_GC 2
-#define C_DEBUG_ENTRY 3
-#define C_DEBUG_SIGNAL 4
-#define C_DEBUG_CONNECT 5
-#define C_DEBUG_LISTEN 6
-#define C_DEBUG_INTERRUPTED
