freenode/#clasp - IRC Chatlog
Search
0:52:58
drmeister
Hey Bike - I'm working with cando and slime and jumping to source code is giving interpretable but unexpected errors.
1:05:26
drmeister
Pulling a new slime doesn't fix the problem - the swank/clasp.lisp assumes the (clasp-debug:frame-source-location (frame-from-number frame-number))) returns a code-source-line object.
1:05:51
drmeister
It's really nice that when I M-. on (code-debug:code-source-line-pathname it jumps here though...
1:05:56
drmeister
https://github.com/clasp-developers/clasp/blob/main/src/lisp/kernel/lsp/debug.lsp#L48
1:06:31
drmeister
What happens is that (clasp-debug:frame-source-location (frame-from-number frame-number))) actually returns a #<source-pos-info ...> object.
1:24:57
Bike
frame-source-location should always return a code-source-line or nil, so returning a source pos info is wrong
1:26:45
Bike
mhm, the DebuggerFrame_O has a spi in it, which should be converted into a code-source-line by clasp-debug but isn't
1:27:49
Bike
alternately we could finally decide on a single source position object to use. we have like four at this point? but that would be more involved
1:28:40
Bike
also there's unfortunately no source info for C++ at all. all C++ frames have is the function name
2:53:23
drmeister
We can create those from C++. How about we unify around that as the source position object to use?
2:54:46
drmeister
https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/sourceFileInfo.h#L120
2:55:45
drmeister
These uniquify the file source file name and they store the _Filepos and _FunctionScope and _InlinedAt.
3:06:34
drmeister
That's not to challenge - it's simpler and if we don't need the stuff in SourcePosInfo_O we could get rid of it and use code-source-line.
3:14:58
Bike
given that we have multiple sources of information it might be best to have a kind of object with all possible fields but nullable
3:15:23
Bike
i think the tricky bit was sometimes we have a line number and column, and sometimes we just have the character position
4:08:54
drmeister
Also - I am getting backtrace entries that look like: 13: (#<FUNCTION CHEM:CONNECT-RESIDUES> #<TOPOLOGY :name :SIDECAP.ORIGIN @0x12bab6930> #<RESIDUE :SIDECAP :id 0 0x1c501190> -FG$ #<TOPOLOGY :name :ACID-FG$ @0x1462fd030> 51539607564 30786416014444)
4:10:38
drmeister
What do we use character offsets for? Do we ever need them? Where do they come from?
4:12:07
Bike
not sure where they come from, but if theyre in spi it might be the primitive source tracking, like from the reader
4:15:11
drmeister
Do you have any ideas about arguments after the 4th argument? They are arguments on the stack.
4:15:45
drmeister
This? (#<FUNCTION CHEM:CONNECT-RESIDUES> #<TOPOLOGY :name :SIDECAP.ORIGIN @0x12bab6930> #<RESIDUE :SIDECAP :id 0 0x1c501190> -FG$ #<TOPOLOGY :name :ACID-FG$ @0x1462fd030> 51539607564 30786416014444)
4:16:13
drmeister
No, these don't go into the register save area - you go on to the stack to get them.
4:19:02
Bike
i thought all the arguments would be in the register save area, so it just reads that many
4:19:35
Bike
i'm not sure what you mean by getting things from the stack. the register save area is on the stack, right?
4:20:55
drmeister
Starting here... https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64
4:21:42
drmeister
The register save area is 6 words allocated in the stack frame where the 6 register arguments are spilled by our code.
4:22:24
Bike
let me start over. do we use the register save area for anything but getting arguments for backtraces? my impression is no.
4:22:54
Bike
so why don't we just put all the arguments there? I don't see the relevance of what's in registers and what isn't
4:26:44
drmeister
You should use the macros in lispCallingConvention.h though - we don't want to hardcode these numbers.
4:28:05
drmeister
https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/lispCallingConvention.h#L167
4:28:39
drmeister
So instead of using 0, 1, 2 here: https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/lispCallingConvention.h#L167
4:29:14
drmeister
Use LCC_CLOSURE_REGISTER, LCC_NARGS_REGISTER, LCC_ARG0_REGISTER and LCC_ARGS_PASSED_IN_REGISTERS (should be 4 or 6 - I forget)
4:30:00
drmeister
https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/lispCallingConvention.h#L180
4:31:05
drmeister
That spills the registers and it sets the gp_offset - uh - maybe that's not useful here. I thought it might point to the fifth argument (first on the stack).
4:31:52
Bike
https://github.com/clasp-developers/clasp/blob/master/src/core/debugger.cc#L1544-L1550 this is the bit to copy, anyway
4:32:49
Bike
well i changed the code to get all the arguments at once instead of having a get-nth-argument function, but otherwise yes
4:34:10
drmeister
I set that function up to get interpreted frame arguments as well. It might even work.
4:34:38
drmeister
What I'm saying is you could call my function from your function and it will get the argument from the correct place.
4:35:17
Bike
i figure we could use more usual mechanisms to get the arguments to cl__eval or whatnot and interpret them appropriately