[NativeAOT] DWARF symbols for shared libraries produce invalid DW_AT_decl_file/DW_AT_decl_line

[thefex]

Description

When building NativeAOT shared library (.so/.dylib) produced DWARF symbols contain invalid entries for DW_AT_decl_file/DW_AT_decl_line - which has following impact:

• difficult to set breakpoints via native debugger, ex. lldb breakpoint set FileName.cs:LineNumber does not work
  Even though function symbol names are properly generated (DW_at_name) - the file/line number is not.

This bug exists on all linux-bionic/ios target types (i.e. linux-bionic-arm64, ios-arm64), on both net9 & net10.

Reproduction Steps

Check this repro solution:
https://github.com/thefex/ReproduceNativeAOTDwarfBug

• you can build using publish_droid.sh on OSX if you have NDK 28.1.13356709 installed (or you can change NDK path in script)

• build manually via dotnet publish ..

• extract: libRepro-arm64-debug-dwarfinfo.txt.zip manually - this is dwarfdump for bin/net10/linux-bionic-arm64/publish/libRepro.so.dbg

Check that all DW_.._file points to:

DW_AT_decl_file	("/_/crypto/src/x509/SubjectPublicKeyInfoFactory.cs")
DW_AT_decl_line	(1)

Expected behavior

DWARF symbols DW_AT_decl_file/line points to valid file/line number.

Actual behavior

DW_AT_decl_file	("/_/crypto/src/x509/SubjectPublicKeyInfoFactory.cs")
DW_AT_decl_line	(1)

-> most symbols point to invalid file

Regression?

No, it exists in net9.0 as well.

Known Workarounds

n/a

Configuration

It has been built with .NET 10.0.100-preview.4.

It has been verified that bug also exists on:
version: 9.0.101
Commit: dotnet/sdk@eedb237
Workload version: 9.0.101.2
MSBuild version: 17.12.12+1cce77968

It seems issue is affecting all nativeaot target frameworks - even though I only checked ios-..-arm64, linux-bionic-arm/arm64...

Other information

No response

[MichalStrehovsky]

Looks like this is hardcoded to 1/1 when we emit this:

runtime/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/ObjectWriter/Dwarf/DwarfInfo.cs

Lines 328 to 329 in 58c9bad

	// DW_AT_decl_file, DW_AT_decl_line
	writer.Write([1, 1]);

I'm not fully clear why we emit a DW_AT_decl_file/DW_AT_decl_line here anyway - sequence points within the method body and the corresponding line numbers are stored elsewhere. I wonder if we could just stop emitting this part.

[thefex]

Can this be supported ?
I think, lldb b CSharpFile.cs:LineNumber syntax wont work without that?

Otherwise, devs have to manually nm -C debugSymbols.

Or maybe it will work if thats stored elsewhere ? (But invalid emit break it?)

[SingleAccretion]

ex. lldb breakpoint set FileName.cs:LineNumber does not work

It is surprising to me that it doesn't work. This should be driven by .debug_line data.

I wonder if we could just stop emitting this part.

Agree, but it would need careful testing. I recall seeing code in LLDB which checks hasDeclLine() to decide whether we're looking at a definition or declaration. It may not matter for the DWARF shape that ILC emits.

[agocke]

It seems issue is affecting all nativeaot target frameworks

By that do you mean, linux-x64, linux-arm64, etc?

[thefex]

It seems issue is affecting all nativeaot target frameworks

By that do you mean, linux-x64, linux-arm64, etc?

Thats for sure - confirmed.
Am afraid other targets - windows and rest that are nativeaot supported too - as seems this part might be shared between platforms

[agocke]

Windows doesn't use DWARF, so it seems unlikely that will be affected.

[thefex]

Windows doesn't use DWARF, so it seems unlikely that will be affected.

Ok my bad, have not developed anything @ windows for ~8y 😅

So for sure:
All linux and ios targets are affected. Others - unknown

[MichalStrehovsky]

I'm not able to repro a problem with this. I do see the DW_AT_decl_file, DW_AT_decl_line hardcoded to 1 but b SomeFile.cs:123 seems to work because as SingleAccretion wrote above, debuggers are expected to use .debug_line data.

Could you confirm:

• The debugger can actually see the debug info. We place debug information into a sidecar file. The quickest way to retest this would be to dotnet publish -p:StripSymbols=false to disable the stripping - the debugger should be able to find the info that way for sure because it will be embedded in the .so file.
• The line numbers you were trying with were not optimized away. Debugging optimized code is touch and go - even when attempting stepping through the code line by line, the execution is not actually line by line. The best way would be to dotnet publish -c Debug (and make sure to use the binaries from the Debug subdirectory, not Release).

So try dotnet publish -p:StripSymbols=false -c Debug.

If that doesn't work, try setting breakpoint on RhpNewFast just to really confirm this is not about lack of symbol information (execute b RhpNewFast in LLDB - it should bind to a symbol - this symbol backs the new keyword and every .NET native AOT app will have it).

[thefex]

Could you confirm:

• The debugger can actually see the debug info. We place debug information into a sidecar file. The quickest way to retest this would be to dotnet publish -p:StripSymbols=false to disable the stripping - the debugger should be able to find the info that way for sure because it will be embedded in the .so file.
• The line numbers you were trying with were not optimized away. Debugging optimized code is touch and go - even when attempting stepping through the code line by line, the execution is not actually line by line. The best way would be to dotnet publish -c Debug (and make sure to use the binaries from the Debug subdirectory, not Release).

So try dotnet publish -p:StripSymbols=false -c Debug.

If that doesn't work, try setting breakpoint on RhpNewFast just to really confirm this is not about lack of symbol information (execute b RhpNewFast in LLDB - it should bind to a symbol - this symbol backs the new keyword and every .NET native AOT app will have it).

1. Debugger has symbols. I pointed Android Studio lldb to look into folder with .dbg.
   I was able to set breakpoints via function symbol located via nm -C .so.dbg and step through file.

I was using Debug builds with Optimize=false csproj flag.

2. I will recheck with StripSymbols=false later again today/tomorrow

3. Maybe it's Android Studio LLDB debugger bug and not really .NET?

4. Should lldb b FileName.cs:LineNumber work or something more complex like

lldb b SubDirectories/Path/InProject/FileName.cs:Line?

[thefex]

I did another test round, this time using iOS build (which also have invalid Dw_file..)

Lldb via Xcode worked alright and I can set breakpoint to file directly.

Perhaps its Android Studio bug with lldb. Therefore I can close the issue as it has no impact on debugging experience.

Just let me know if you do not need this issue anymore (does DW_line/file impact you in other way)

[MichalStrehovsky]

I think we can close then. Thank you for checking!