I started playing with unbug the other day, and it seems like it could be a rather nifty tool. One thing that limits its immediate usefulness is the fact that breakpoints and stepping don't currently work. I'm told that the reason is because the opcodes that make this possible have been disabled.
I realize that doing anything about this is probably beyond my abilities, I was wondering what it would take to re-enable them, and what any pros and cons for doing this might be.
Any thoughts?
Bill
Which opcodes are that? How would they be used? Will it work with machine code?
/ Martin Stjernholm, Roxen IS
Previous text:
2004-04-07 21:57: Subject: unbug and opcodes
I started playing with unbug the other day, and it seems like it could be a rather nifty tool. One thing that limits its immediate usefulness is the fact that breakpoints and stepping don't currently work. I'm told that the reason is because the opcodes that make this possible have been disabled.
I realize that doing anything about this is probably beyond my abilities, I was wondering what it would take to re-enable them, and what any pros and cons for doing this might be.
Any thoughts?
Bill
/ Brevbäraren
Hubbe says:
Simple: Modify the byte code and insert an F_BREAKPOINT, then set a GDB breakpoint in o_breakpoint(). If I remember correctly, it then used a breakpoint inside the interpreter to ensure that it could put back the original opcode, execute it, and then put the F_BREAKPOINT back again...
/ Martin Nilsson (provokatör)
Previous text:
2004-04-08 13:51: Subject: unbug and opcodes
Which opcodes are that? How would they be used? Will it work with machine code?
/ Martin Stjernholm, Roxen IS
#if 0 /* This opcode needs mending if it is to work with machine code. */ OPCODE0_JUMP(F_BREAKPOINT, "breakpoint", 0, { extern void o_breakpoint(void); o_breakpoint(); DO_JUMP_TO(PROG_COUNTER-1); }); #endif
The comment there is true. #if 0 could perhaps be replaced with #ifndef PIKE_USE_MACHINE_CODE. A problem to work out if it's adapted for machine code is how to return from the opcode to a suitable position. That's why it was disabled.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-04-08 14:06: Subject: unbug and opcodes
Hubbe says:
Simple: Modify the byte code and insert an F_BREAKPOINT, then set a GDB breakpoint in o_breakpoint(). If I remember correctly, it then used a breakpoint inside the interpreter to ensure that it could put back the original opcode, execute it, and then put the F_BREAKPOINT back again...
/ Martin Nilsson (provokatör)
While at the topic unbug, could you take a look at the multiset code in unbug? I rewrote it to handle the new multisets, but it isn't working flawlessly.
Example:
(unbug) run Pike v7.5 release 25 running Hilfe v3.5 (Incremental Pike Frontend)
multiset y = (< "foo", "bar", "gazonk" >); kill(getpid(),signum("SIGINT"));
Starting program: /home/nilsson/Pike/7.5/build/linux-2.4.20-28.8-i686/test-install/pike/7.5.25/bin/pike
Program received signal SIGINT, Interrupt. 0x42028811 in kill () from /lib/i686/libc.so.6
OBJECT->___HilfeWrapper() at HilfeInput:1 Could not load source file "HilfeInput" (unbug) globals ___hilfe = (["y":(< $ERRROR(type:57350)$, "bar", $ERRROR(type:57350)$>)]) (unbug)
The type 57350 binary is 1110000000000110, which is the string type with the upper three bits set. I assume that you use them for something internally.
/ Martin Nilsson (provokatör)
Previous text:
2004-04-08 14:13: Subject: unbug and opcodes
#if 0 /* This opcode needs mending if it is to work with machine code. */ OPCODE0_JUMP(F_BREAKPOINT, "breakpoint", 0, { extern void o_breakpoint(void); o_breakpoint(); DO_JUMP_TO(PROG_COUNTER-1); }); #endif
The comment there is true. #if 0 could perhaps be replaced with #ifndef PIKE_USE_MACHINE_CODE. A problem to work out if it's adapted for machine code is how to return from the opcode to a suitable position. That's why it was disabled.
/ Martin Stjernholm, Roxen IS
Yes, see the comments in multiset.h. Something somewhere is accessing the index directly as an svalue, which it isn't (the struct just looks that way since it's convenient). There's a set of macros in multiset.h, e.g. assign_multiset_index_no_free, which should be used to access it. (It's not describe_multiset that's made that output; it handles this properly.)
/ Martin Stjernholm, Roxen IS
Previous text:
2004-04-08 14:21: Subject: unbug and opcodes
While at the topic unbug, could you take a look at the multiset code in unbug? I rewrote it to handle the new multisets, but it isn't working flawlessly.
Example:
(unbug) run Pike v7.5 release 25 running Hilfe v3.5 (Incremental Pike Frontend)
multiset y = (< "foo", "bar", "gazonk" >); kill(getpid(),signum("SIGINT"));
Starting program: /home/nilsson/Pike/7.5/build/linux-2.4.20-28.8-i686/test-install/pike/7.5.25/bin/pike
Program received signal SIGINT, Interrupt. 0x42028811 in kill () from /lib/i686/libc.so.6
OBJECT->___HilfeWrapper() at HilfeInput:1 Could not load source file "HilfeInput" (unbug) globals ___hilfe = (["y":(< $ERRROR(type:57350)$, "bar", $ERRROR(type:57350)$>)]) (unbug)
The type 57350 binary is 1110000000000110, which is the string type with the upper three bits set. I assume that you use them for something internally.
/ Martin Nilsson (provokatör)
No, the output is made by unbug. It accesses the data structure through gdb, so running any functions or macros might be hard.
/ Martin Nilsson (provokatör)
Previous text:
2004-04-08 14:37: Subject: unbug and opcodes
Yes, see the comments in multiset.h. Something somewhere is accessing the index directly as an svalue, which it isn't (the struct just looks that way since it's convenient). There's a set of macros in multiset.h, e.g. assign_multiset_index_no_free, which should be used to access it. (It's not describe_multiset that's made that output; it handles this properly.)
/ Martin Stjernholm, Roxen IS
The code is in MultisetHandle in unbug.
/ Martin Nilsson (provokatör)
Previous text:
2004-04-08 15:00: Subject: unbug and opcodes
No, the output is made by unbug. It accesses the data structure through gdb, so running any functions or macros might be hard.
/ Martin Nilsson (provokatör)
Then zero the highest four bits in the type field before using it as an svalue.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-04-08 15:00: Subject: unbug and opcodes
No, the output is made by unbug. It accesses the data structure through gdb, so running any functions or macros might be hard.
/ Martin Nilsson (provokatör)
When machine code is enabled, proper GDB breakpoints could be used instead. Shouldn't take too much unbug hacking to fix that...
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2004-04-08 14:13: Subject: unbug and opcodes
#if 0 /* This opcode needs mending if it is to work with machine code. */ OPCODE0_JUMP(F_BREAKPOINT, "breakpoint", 0, { extern void o_breakpoint(void); o_breakpoint(); DO_JUMP_TO(PROG_COUNTER-1); }); #endif
The comment there is true. #if 0 could perhaps be replaced with #ifndef PIKE_USE_MACHINE_CODE. A problem to work out if it's adapted for machine code is how to return from the opcode to a suitable position. That's why it was disabled.
/ Martin Stjernholm, Roxen IS
pike-devel@lists.lysator.liu.se