lldb `call` can't find function symbols

[sylvanc]

When running a Pony program in lldb, it is convenient to be able to call functions (as one does in C programs). This used to work.

Unfortunately, at some point it stopped working. For example:

(lldb) call String_box_cpointer_Zo(source)
error: use of undeclared identifier 'String_box_cpointer_Zo'

Note that if we try to set a breakpoint, it works:

(lldb) b String_box_cpointer_Zo
Breakpoint 3: where = peg`String_box_cpointer_Zo + 18 at string.pony:205, address = 0x0000000100005a22

It's possible this has to do with how the language identifier is set in the DWARF info. The right long term solution is full support for Pony in lldb:

http://lldb.llvm.org/adding-language-support.html

[SeanTAllen]

I poked at this on current main (LLVM 21, lldb 22). The literal symptom from the original report is gone. lldb finds the symbol now. What it does instead is yell at you about the return type:

(lldb) expression Adder_box_add_iii(2, 3)
error: 'Adder_box_add_iii' has unknown return type; cast the call to its declared return type

If you cast, the call works:

(lldb) print (int)Adder_box_add_iii(2, 3)
(int) 6

So somewhere between 2017 and now, lldb learned to fall back to the symbol table when the C++ name lookup misses. That turned "can't find it" into "found it, please tell me the return type."

The reason the cast is still needed lives in how ponyc emits the function into DWARF. Every Pony method becomes a C++ method nested inside the receiver type's DW_TAG_structure_type. DW_AT_name is the short Pony name (add). DW_AT_linkage_name is the symbol name (Adder_box_add_iii). DW_AT_type points at the correct return type, and the formal parameters are typed. The DWARF itself is fine. The codegen sits in src/libponyc/codegen/genfun.c (calls LLVMDIBuilderCreateMethod) and the wrapper in src/libponyc/codegen/gendebug.cc (which calls DIBuilder::createMethod).

lldb's symbol layer has the full type. image lookup -n Adder_box_add_iii -v reports compiler_type = "int (int, int)" and types every parameter, including this as Adder *. The expression evaluator is what gets stuck. It looks up Adder_box_add_iii as a C++ identifier at global scope. The DWARF entity with that linkage name has C++ name add and lives inside class Adder. A global identifier Adder_box_add_iii does not bind to a method called add on a class. lldb falls back to the bare symbol-table entry, which carries an address but no type, and out comes the "cast it" message.

I checked the same lldb against a plain C function compiled with clang. int cadd(int, int) is callable with no cast: call cadd(40, 2) returns (int) 42, no warning. The difference is that C emits DW_AT_name, DW_AT_linkage_name, and the ELF symbol all the same string, at compile-unit scope.

Two side notes from the dump:

• ponyc emits DWARF version 4 with the old .debug_pubnames / .debug_pubtypes. No .debug_names. lldb ignores pubnames and builds its own index, so the outcome doesn't change, but the accelerator we emit is stale.
• The compile unit's source language is already DW_LANG_C_plus_plus. The original report speculated the language identifier might be wrong. It isn't.

Three paths forward as I see it:

1. Emit Pony functions as compile-unit-scope free functions named by their mangled name, the way C does. Mechanically, swap LLVMDIBuilderCreateMethod for a createFunction call, scope it at the compile unit, name it m->full_name. Backtraces already show the linkage name, so they don't change. The C counterfactual makes me think this fixes the cast requirement, but I haven't prototyped it.

2. Document the "cast to the return type" workaround and close this. The original complaint is resolved. What's left is a papercut in lldb's expression evaluator, not really a ponyc bug.

3. Full Pony language support in lldb, which is what the original report aspirationally pointed at. That's a real plugin project, not something to take on casually.

I lean toward 1 if anyone has appetite to prototype it, otherwise 2.

[SeanTAllen]

New URL for LLDB documentation: https://lldb.llvm.org/resources/addinglanguagesupport.html