Can't map two sources to same destination

[gbryant-arm]

OS: Ubuntu 20.04
VSCode version: 1.78.0
CodeLLDB version: 1.9.1
Compiler: rustc 1.65.0
VSCode is running in a dev container

I'm trying to set breakpoints on two binaries whose sources are symlinked to the same codebase via different symlinks:

• veracruz-server:
  • DWARF info points to */linux-host/crates/* which symlinks ../../
• runtime enclave:
  • called by veracruz-server and followed by LLDB (settings set target.process.follow-fork-mode child)
  • DWARF info points to */linux-runtime/crates/** which symlinks ../../

I've followed the troubleshooting guide and configured sourceMap as follows:

"sourceMap": {
	"/work/Veracruz/veracruz/workspaces/linux-host/crates" : "/work/Veracruz/veracruz",
	"/work/Veracruz/veracruz/workspaces/linux-runtime/crates" : "/work/Veracruz/veracruz"
},

Interestingly only the breakpoints associated with */linux-host/* get resolved. Output from breakpoint list --verbose:

Current breakpoints:
1: file = '/work/Veracruz/veracruz/workspaces/linux-host/crates/veracruz-server/src/cli.rs', line = 30, exact_match = 0

    1.1: 
      module = /work/Veracruz/veracruz/workspaces/linux-host/target/debug/veracruz-server
      compile unit = 4b0wvdf3qht5gwlu
      function = veracruz_server::main
      location = /work/Veracruz/veracruz/workspaces/linux-host/crates/veracruz-server/src/cli.rs:30:15
      address = 0x000055555566f327
      resolved = true
      hardware = false
      hit count = 1   


2: file = '/work/Veracruz/veracruz/workspaces/linux-host/crates/execution-engine/src/native_module_manager.rs', line = 235, exact_match = 0

Swapping the mappings (moving the first one below the second) makes the */linux-runtime/* mapping work and the */linux-host/* mapping fail. Output from breakpoint list --verbose:

Current breakpoints:
1: file = '/work/Veracruz/veracruz/workspaces/linux-runtime/crates/veracruz-server/src/cli.rs', line = 30, exact_match = 0


2: file = '/work/Veracruz/veracruz/workspaces/linux-runtime/crates/execution-engine/src/native_module_manager.rs', line = 235, exact_match = 0

    2.1: 
      module = /tmp/.tmp2nFOcW/runtime_enclave_binary
      compile unit = 3cuu6b0f6ua8ejbf
      function = execution_engine::native_module_manager::NativeModuleManager::execute
      location = /work/Veracruz/veracruz/workspaces/linux-runtime/crates/execution-engine/src/native_module_manager.rs:235:9
      address = 0x0000555555bbb535
      resolved = true
      hardware = false
      hit count = 0 

Looks like mappings to an already mapped destination are ignored, or am I missing something?

[vadimcn]

The source mappings must be 1:1 in both directions. The debugger first transforms file paths, then then resolves breakpoints. It isn't going to try all alternate mappings until the breakpoint gets resolved.

[gbryant-arm]

To provide some context my project targets several platforms, and uses Cargo workspaces to better divide them and scale. They all share the same codebase (give or take some features), hence the symlinks (cf. https://github.com/veracruz-project/veracruz/tree/main/workspaces/linux-host and https://github.com/veracruz-project/veracruz/tree/main/workspaces/linux-runtime).

It isn't going to try all alternate mappings until the breakpoint gets resolved.

Is there any technical challenge in iterating over all mappings?
Alternatively, would that make sense to add an option to resolve symlinks into real paths?

[vadimcn]

Is there any technical challenge in iterating over all mappings?

This would be a question for LLDB devs. CodeLLDB is about integration of LLDB and VSCode, I do not develop the core debugging engine.

Alternatively, would that make sense to add an option to resolve symlinks into real paths?

Rustc does resolve symlinks into real paths.

Maybe "breakpointMode": "file" will work or you? As long as you don't need to set too many breakpoints in mod.rs...

[gbryant-arm]

Maybe "breakpointMode": "file" will work or you? As long as you don't need to set too many breakpoints in mod.rs...

Thanks, sounds like a reasonable workaround 👍

Rustc does resolve symlinks into real paths.

I'm confused. How come the symlinks in the debug info aren't resolved then? Is debug info generation achieved independently from rustc?

[vadimcn]

I'm confused. How come the symlinks in the debug info aren't resolved then? Is debug info generation achieved independently from rustc?

Hmm, I guess it only does that when the entire workspoace directory is symlinked.

[gbryant-arm]

Found a satisfying workaround: passing --remap-path-prefix to rustc 🥳