LLDB: Specifying source search folders for flattened folder structure

Question

I'm using VSCode + CodeLLDB + LLDB to debug a JIT'ed language (KL), however I'm having trouble getting LLDB to recognize the source files.

This is a duplicate question to LLDB equivalent of gdb "directory" command for specifying source search path?, however it's accepted answer doesn't work for me.

LLDB seems to think every source unit is compiled to the local directory - so if I execute

kl /MyWork/someFile.kl

and this file includes /any/other/path/external.kl, LLDB will believe the file is located as /MyWork/external.kl

So far, I'm (mostly) working around this problem by using

settings set target.source-map /MyWork/ /any/other/path/

However this only seems to work for a single folder. If I tried:

settings set target.source-map /MyWork/ /any/other/path/
settings set target.source-map /MyWork/ /I/use/many/dependencies/

Then LLDB seems to not be able to find -any- files in either folder. Interestingly, when I tried this LLDB errored with accurate messages

can't find external.kl in /I/use/many/dependencies/
can't find dependencies.kl in /any/other/path/

Which are accurate messages, but seems almost as if LLDB is just looking for an excuse to error-out :).

Note - I can set breakpoints and view locals, I just can't seem to view the source code at that spot.

Anywho - is there any suggestions on how to deal with this issue? There are 3 possibilities to work with: - Modify/work with LLDB to find the source files - Modify CodeLLDB to modify paths between LLDB + VSCode - Somehow convince VSCode to ignore the path given to it, and search its own folders for any file matching the name.

My suspicion is that LLDB is the right place to fix this, but I am open to any suggestions (right up to the point of linking each and every source file into a flat folder I can redirect to).

Answer 1

lldb only knows about source paths from what is written in the debug information. The rule in DWARF (the debug format lldb uses) is that if an include file is just given by relative path or base name then it is taken to be relative to the compilation directory. Looks like that's what is happening in your case. That sounds like a compiler bug. lldb's not going to be able to reconstruct the file hierarchy at this point.

The source maps should give you a manual way to fix this, and from the sound of it, what you are describing should work. But maybe there's something else odd in the DWARF output from kl that is confusing it. You'll need to file a bug with some example binary to http://bugreporter.apple.com.