libera/#clasp - IRC Chatlog
Search
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