unsupported DW_FORM value: 0x1e

[tipeter]

OS: Ubuntu 22.04.1
VSCode version: 1.72.0-insider
CodeLLDB version: v1.7.4
Compiler: GNAT 12.1.0
Debuggee: lldb version 14.0.0

Hi!

I am studying Ada programming and I would like to use CodeLLDB as a debugger. I managed to configure VSCode. Everything works normally, except debugging.
Webfreak's NativeDebug (gdb) works, CodeLLDB does not.

The debug session starts, but none of the breakpoints work; nor does the pause.
I get the following error message in the LLDB Output window (among others):
'unsupported DW_FORM value: 0x1e'

I am currently using lldb-14 (from the Ubuntu repository), but the same phenomenon is happening with the CodeLLDB's own LLDB.

Many thanks for any help/ideas!

LLDB Output:

Initial debug configuration: {
  name: '(CodeLLDB) Build & debug',
  preLaunchTask: 'ada: Build current project',
  type: 'lldb',
  request: 'launch',
  cwd: '${workspaceFolder}',
  windows: { program: '${workspaceRoot}/bin/sdlfract.exe' },
  linux: { program: '${workspaceRoot}/bin/sdlfract', terminal: 'external' },
  __configurationTarget: 6
}
Resolved debug configuration: {
  name: '(CodeLLDB) Build & debug',
  preLaunchTask: 'ada: Build current project',
  type: 'lldb',
  request: 'launch',
  cwd: '${workspaceFolder}',
  windows: { program: '${workspaceRoot}/bin/sdlfract.exe' },
  linux: { program: '${workspaceRoot}/bin/sdlfract', terminal: 'external' },
  __configurationTarget: 6,
  relativePathBase: '/home/ptihanyi/AdaWorkspace/learning/sdlfract',
  _adapterSettings: {
    displayFormat: 'auto',
    showDisassembly: 'auto',
    dereferencePointers: true,
    suppressMissingSourceFiles: true,
    evaluationTimeout: 5,
    consoleMode: 'commands',
    sourceLanguages: null,
    terminalPromptClear: null,
    evaluateForHovers: true,
    commandCompletions: true,
    reproducer: false
  }
}
warning: (x86_64) /home/ptihanyi/AdaWorkspace/learning/sdlfract/bin/sdlfract unsupported DW_FORM value: 0x1e
[2022-09-15T08:54:26.249Z ERROR codelldb::terminal] channel closed
Debug adapter exit code=0 (0x0), signal=null.

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Build & debug",
            "preLaunchTask": "ada: Build current project",
            "type": "gdb",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "valuesFormatting": "parseText",
            "windows": {
                "target": "${workspaceRoot}/bin/sdlfract.exe",
            },
            "linux": {
                "target": "${workspaceRoot}/bin/sdlfract",
                "terminal": "xterm"
            }
        },
        {
            "name": "(CodeLLDB) Build & debug",
            "preLaunchTask": "ada: Build current project",
            "type": "lldb",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "windows": {
                "program": "${workspaceRoot}/bin/sdlfract.exe",
            },
            "linux": {
                "program": "${workspaceRoot}/bin/sdlfract",
                "terminal": "external"
            }
        }
    ]
}

[vadimcn]

The 'unsupported DW_FORM ...' message is likely due to Ada compiler emitting some debug info encoding that LLDB does not understand yet. Depending on which part of the debug info is affected, this could be a blocker or just a benign warning, though since gdb works without a problem, it's likely to be the former. But just in case it's not, does any of this help: https://github.com/vadimcn/vscode-lldb/wiki/Breakpoints-are-not-getting-hit?

Also, check your compiler's users forum or mailing list, they are more likely to know what' going on.

[tipeter]

Thanks for the reply!
I checked the article you recommended.
It seems the binary compiled by GNAT is fine. It includes debug info and source file names without path.
What's interesting: if I include "stopOnEntry": true -line in launch.json, "PAUSE" works. Without it, it does not work (but debug session is started...).
But if I resume running after PAUSE, I get the following error message on the LLDB Output:

ERROR(Python) 13:36:09 codelldb: Traceback (most recent call last):
  File "/home/ptihanyi/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.7.4/adapter/codelldb.py", line 142, in compile_code
    pycode = compile(expr, filename, 'eval')
  File "<input>", line 1
    "__frame_vars["_start"]
                         ^
SyntaxError: unterminated string literal (detected at line 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/ptihanyi/.vscode-insiders/extensions/vadimcn.vscode-lldb-1.7.4/adapter/codelldb.py", line 144, in compile_code
    pycode = compile(expr, filename, 'exec')
  File "<input>", line 1
    "__frame_vars["_start"]
                         ^
SyntaxError: unterminated string literal (detected at line 1)

[2022-09-16T11:36:09.049Z ERROR codelldb::debug_session] unterminated string literal (detected at line 1) (<input>, line 1)

I have attached the debug symbols, they might be useful. Note: I am not a professional, just an enthusiastic amateur... :)

readelf --string-dump=.debug_str BOSNFCUTIL.elf > debug_symbols.txt

debug_symbols.txt

readelf --syms sdlfract > debug_symbols2.txt

debug_symbols2.txt

[vadimcn]

SyntaxError: unterminated string literal (detected at line 1)

I don't think this is relevant to your problem.
As I said, this is probably due to LLDB not supporting some aspect of debug info emitted by GNAT.

I am currently using lldb-14 (from the Ubuntu repository), but the same phenomenon is happening with the CodeLLDB's own LLDB.

CodeLLDB is currently based on lldb-14, so this is not surprising. There's a chance that this bug got fixed in lldb-15, which was recently released...