libera/#clasp - IRC Chatlog
Search
14:58:47
yitzi
Ok. I am building right now. I was on a different branch. I need to get better with gdb apparently. Would you mind sending at least what you had to do to get to seeing the clasp-cleavir::recurse path? Maybe I'll try the enhanced metadata on a different branch.
14:59:29
Bike
i started clasp, connected to it with gdb (gdb -p pid), put a breakpoint on cl__error, and then had clasp call a function that called error
15:00:12
Bike
the alternate metadata thing is going to be pretty involved if it works at all. you'd need to rewrite at least some of how we collect backtrace information since we couldn't use DIContext:::getLineInfoForAddress as we do now, and i'm not sure how to put extra information in the DIBuilder
15:02:33
yitzi
Yeah, I see that. No matter what way we do it I'd like to make this PR doable. I can make a video showing this, but it makes viewing source code in the Jupyter debugger really slick.
15:07:53
Bike
well, like i said, i'm honestly pretty inclined to forget about gdb/lldb in this area. i mean it's not even all lisp code it would be flubbing on. but drmeister is down in gdb more often than i am so maybe he thinks differently
15:35:56
Bike
looking at the file, for example, it has wrapped_cl__error_T_spList_sp but not just cl__error, so I can't jump to that definition
15:39:49
yitzi
I don't think our source references are completely working in direct-calls. When you start stepping into those functions they report `GENERATED:CLWRAPPERS.LISP` not the c code locations.
15:41:20
Bike
i'm not totally familiar with ninja, but looking at the build.ninja file, the "build ../TAGS:" only lists some generated headers and not most of the sources
15:44:49
Bike
the stepper does its own source location dumping rather than work through dwarf, so it might be something with that rather than direct calls per se
15:45:49
Bike
or, no, maybe i don't understand... all the stepper dumps is the source form, not a location. the locations would be coming from the backtrace/dwarf stuff i think
15:46:47
yitzi
Can you try replacing all occurences of `:etags` in src/koga/target-sources.lisp with `:tags` and rerunning koga then `ninja -C build tags`>
15:49:21
Bike
build.ninja now has a lot more files, but M-. is still not working and i still don't see cl__error or cl__read for example in the TAGS
15:50:25
Bike
which is pretty weird, since i see src/core/primitives.cc in the list of files passed to tags
15:51:10
yitzi
I think that just updating in direct-calls via core:set-source-pos-info is not enough. I think the backtrace is reporting the compilation info from the `defun` in the macro expansion.
15:52:27
yitzi
In respect to TAGS: This could be the CTAGS issue. etags gets confused about some of the function declarations.
15:52:36
Bike
yeah, right, so there's like two different things here. there's the source info we store in lisp objects, which is what ext:source-location and set-source-pos-info and stuff deal with. then there's the debug info that's compiled into the fasls, which the compiler does
15:53:06
Bike
those two systems are in some respects independent, and set-source-pos-info is not going to affect the compiler
15:54:57
Bike
when looking through frames, i think it would make sense to preserve the location in GENERATED in some circumstances, like if we're dealing with the lisp separately from the underlying c++ code
15:59:03
yitzi
I dont think it is super critical either way. Its mostly just that the reference to clwrappers isnt very useful.
16:10:02
Bike
and --version gives a ctags.io website, so it's probably not some weird alias. yeah it does have that
17:55:49
kpoeck
:notify drmeister: could you have a look at the comments in https://gitlab.common-lisp.net/drmeister/asdf/-/commit/0a27ab4efb5ee7a0df2f01e5f14ffd36dfd69f71
17:56:09
kpoeck
::notify drmeister could you have a look at the comments in https://gitlab.common-lisp.net/drmeister/asdf/-/commit/0a27ab4efb5ee7a0df2f01e5f14ffd36dfd69f71
18:29:03
Colleen
drmeister: kpoeck said 32 minutes, 53 seconds ago: could you have a look at the comments in https://gitlab.common-lisp.net/drmeister/asdf/-/commit/0a27ab4efb5ee7a0df2f01e5f14ffd36dfd69f71
19:16:06
kpoeck
now as bike proposed attached as file to https://gitlab.common-lisp.net/drmeister/asdf/-/commit/0a27ab4efb5ee7a0df2f01e5f14ffd36dfd69f71
19:21:56
drmeister
Are you recommending that I apply the launch-programl.lisp.patch to my code and resubmit the merge request?
19:24:52
kpoeck
yes, since the asdf maintainers complain that you code doesn't work with older clasps
19:54:00
yitzi
Bike: did you ask drmeister about the logical-path gdb thing? Not sure if you asked via DM or something.
20:34:16
Bike
drmeister: did you see the earlier conversation about source locations and logical pathnames
20:44:29
Bike
yitzi has a PR that fixes a lot of source location problems and is probably the architectural direction we should go, but it means gdb can't list sources for clasp functions (as in, ones in clasp. user code compiled by clasp is fine)
20:46:34
yitzi
My two cents. In order to make logical pathname source references work I stored logical pathnames in LLVM::DIFile for lisp files. This means that when in gdb the logical pathname will print instead of an absolute path. Does this matter.
20:47:05
drmeister
You mean we will not be able to use source information in gdb for Common Lisp code?
20:51:19
drmeister
So you are putting things like this: "SYS:SRC;LISP;KERNEL;CLEAVIR;TOPLEVEL.LISP" into the DWARF?
20:51:20
Bike
the source information in the dwarf is a logical pathname, which gdb doesn't know how to parse
20:53:52
drmeister
Ah - maybe it won't be a problem for profiling. Profiling won't try and interpret the logical path.
20:54:37
drmeister
Can we use paths like: "/mnt/clasp-source/src/lisp/kernel/cleavir/toplevel.lisp" ?
20:55:23
Bike
it would introduce some complexity in the backtrace parsing, but i don't know that it wouldn't work
20:56:27
yitzi
So we could store the sys root in the directory slot and the relative path in the filename slot. Then if we see a directory that is the "original" compiled sys root we could reconstruct the logical pathname in list.
20:58:11
drmeister
I'd like to be able to do source debugging of clasp common lisp code in GDB - it's saved me so much time.
20:58:25
Bike
yeah gdb has stuff to deal with relative pathnames. there's sort of a PATH type list of pathnames it'll try prepending
20:59:09
yitzi
I think we would need the gdb relative pathname stuff anyways when we put and compiled binary into /usr/bin
21:04:16
yitzi
Ok, so I guess I try to figure out how to make the gdb stuff work while maintaining logical paths on the lisp side.
21:17:30
Bike
probably something deep in debuginfo.lisp should check for logical pathnames and translate/chop them up appropriately
21:52:13
Bike
i don't think there are any conceptual barriers, but the debuginfo generation code is pretty messy
22:08:36
Bike
this is unrelated, but i've heard a few times now on the llvm discord that story register names in llvm-ir slows things down appreciably. maybe we should try turning off names when not debugging, which is what clang does for example
22:08:53
Bike
there's some option we can pass in that makes llvm discard names, so we wouldn't have to mess around in our code generator too much, i don't think
23:04:51
yitzi
Bike: on a related note, I think i know how to get rid of the GENERATED host and just have SYS
23:06:59
Bike
to be clear, i don't think using other hosts would be a serious problem, but it would e nice to only use the one we're guaranteed if possible
23:10:05
yitzi
Basically, the idea is that when we are in a dev tree we have the mapping "SYS:GENERATED;**;*.*.*" -> "build/boehmprecise/generated/**/*.*" while in the installed version we just skip that mapping.
23:13:30
yitzi
ok. cool. Mine does all the code highlighting and weird emoticons I don't actually know.
23:14:10
Bike
but yeah that's the kind of thing i meant by 'giving it some top level "directories" with specific translations', i should have elaborated
23:15:06
Bike
yeah the scare quotes are supposed to mean they're artificial. clear communication does not come easily to me unfortunately
23:15:46
Bike
anyway, great. and of course tell me if you want help navigating the compiler when figuring out the DIFile stuff
23:16:24
Bike
i've been going through the llvm api bit by bit as you saw in #commonlisp the other day, and soon i may understand it well enough to take a crack at rewriting debuginfo.lisp