Part Number: CCSTUDIO-THEIA
CCS 20.4 - source-line breakpoints "unverified" when debugging an externally-built .out (built in a Linux container); disassembly breakpoints and watch expressions work
Environment
CCS 20.4.0.13 (Theia-based), Windows 11
TI C2000 CGT 22.6.2.LTS
Target: TMS320F28P550SJ9 LaunchPad, XDS110
Project: managed C2000 project, EABI (--abi=eabi)
Use case
We build our firmware inside a Docker Linux container so that what a
developer debugs is bit-identical to what our CI produces. The container
uses the same compiler version (22.6.2.LTS, linux-x64 build) and the
repository is bind-mounted at /work, so the compiler's working directory
is /work/<project> and DWARF records paths under /work.
CCS drives that build: the managed project's builder has
arguments="-f ../Makefile.ccs BUILD=debug", and that makefile shells into
the container. The container build then copies its .out into the CCS
configuration directory, so the artifact CCS flashes and the artifact we
built are the same file (SHA256 verified identical).
What works
- Build from CCS (Ctrl+B) runs the container build.
- Flashing and running on the LaunchPad.
- Watch expressions read and update correctly (e.g. a static u16
counter changes as expected), so the symbol table resolves.
- Breakpoints set in the Disassembly view bind and are hit.
- In project mode, halting at a disassembly breakpoint opened main.c at
the correct line with a marker, so CCS located the source file.
What does not work
- Breakpoints set in the source editor are always reported "unverified"
and show as disabled. This happens in main.c and in other files.
- With the project closed (target configuration launched directly,
Run > Load > Load Program on the container .out), halting shows only
the Disassembly view, no source.
The binary appears correct
Checked with ofd2000 22.6.2:
- ELF 32-bit, TI C2000, EABI, "with debug_info, not stripped"
- .debug_info, .debug_line, .debug_frame, .debug_str, .symtab all present
- 204 line programs, 7697 line-number entries total
- main.c compilation unit: DW_AT_comp_dir = /work/pb/dcdc_cpu_b,
file name recorded as "main.c" (relative, directory index 0)
- Real line numbers with addresses (main at 0x000867d7, lines 34, 36,
42, 45, ... present)
- No Windows paths anywhere in the file; every recorded path is /work/...
- Some units record absolute names, e.g. /work/core/pxcan/pxcan.c
What we have tried
- .theia/launch.json, connections[].cores[].sourceMappings[] entries of
the form { module, compilationDir, sourceDir }, mapping
compilationDir "/work" to the local Windows repository root. Also
tried one entry per recorded directory (/work/pb/dcdc_cpu_b,
/work/core, /work/device_f28p55x). No effect on breakpoint binding.
- sourceDirs[] with the same local directories.
- An explicit "program" pointing at the container-built .out.
- Both with and without projectInfo in the launch configuration.
- No "Locate File" / source lookup prompt is ever shown, so we have not
been able to let CCS record a mapping itself.
Questions
1. Is sourceMappings in .theia/launch.json intended to affect breakpoint
resolution, or only source display when the debugger halts?
2. Is there a supported way to tell CCS 20.4 that a DWARF
DW_AT_comp_dir of /work/... corresponds to a local Windows directory,
such that source-line breakpoints bind?
3. Is debugging an externally-built .out with source-line breakpoints
supported in CCS 20.4? If so, what is the correct configuration?
4. If path remapping is not supported, is there a recommended way to
build so that CCS can resolve the sources - for example compiling
with source paths relative to the project directory?
Requirement: we need the debugged image to be the same binary CI produces,
so rebuilding natively in CCS for debugging is not an option we want.
