[NativeAOT] Linux/ARM bring-up (3/n)

[filipnavara]

Some smoke tests pass:

Time [secs] | Total | Passed | Failed | Skipped | Assembly Execution Summary
============================================================================
      0.192 |     1 |      1 |      0 |       0 | nativeaot.CustomMain.XUnitWrapper.dll
      0.190 |     1 |      1 |      0 |       0 | nativeaot.GenerateUnmanagedEntryPoints.XUnitWrapper.dll
     24.809 |    15 |     12 |      3 |       0 | nativeaot.SmokeTests.XUnitWrapper.dll
      0.200 |     1 |      1 |      0 |       0 | nativeaot.StartupHook.XUnitWrapper.dll
----------------------------------------------------------------------------
     25.391 |    18 |     15 |      3 |       0 | (total)

To do:

• Fix MUSL builds
• Fix DWARF method lookup w.r.t. thumb bit
• IMAGE_REL_BASED_THUMB_MOV32_PCREL relocation causing corrupted pointers after linking
• GC / STW thread hijacking is unimplemented/broken
• Exclude DwarfTest or ensure that llvm-dwarpdump is downloaded from NuGet to correct location
• Investigate segmentation fault in UnitTests and DynamicGenerics smoke tests (uncatchable in QEMU debugger)

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Some smoke tests pass:

Time [secs] | Total | Passed | Failed | Skipped | Assembly Execution Summary
============================================================================
      0.180 |     1 |      1 |      0 |       0 | nativeaot.CustomMain.XUnitWrapper.dll
      0.183 |     1 |      1 |      0 |       0 | nativeaot.GenerateUnmanagedEntryPoints.XUnitWrapper.dll
      5.847 |    15 |     11 |      4 |       0 | nativeaot.SmokeTests.XUnitWrapper.dll
----------------------------------------------------------------------------
      6.210 |    17 |     13 |      4 |       0 | (total)

To do:

• GC / STW thread hijacking is unimplemented/broken.
• Dehydration sometimes results in corrupted method tables (shifted by 4 bytes). Curiously, it doesn't happen for -no-pie executables, or if the hydrated section is renamed to .bss.hydrated and merged by the linker into regular BSS. LLDB also handles the symbol name demangling in the regular BSS section but doesn't handle it for the custom section.
• TBD

Author:	filipnavara
Assignees:	-
Labels:	community-contribution, area-NativeAOT-coreclr
Milestone:	-

[MichalStrehovsky]

if the hydrated section is renamed to .bss.hydrated

We can place this into .bss section. I don't remember why I made it a separate section.

[filipnavara]

We can place this into .bss section. I don't remember why I made it a separate section.

Generally speaking I think it's a good idea, at least for the improved LLDB debugging experience. I'd still like to understand the errors I am seeing though.

[filipnavara]

I'd still like to understand the errors I am seeing though.

I was wrong about the offset in dehydrated data being off by 4. It's actually off by 0x10000 in the linked executable. It uses the MOVW/MOVT instructions to load the address which each loads a 16-bit word. I'm following through with the investigation, but I am not fully ruling out a linker bug (*).

(*) Already found one related to the thumb bit (lowest bit) in MOVW/MOVT. For that one it's quite obvious how it happens and why no one hit it before - other compilers don't produce inline addend with Thumb bit. This one seems like a tougher nut to crack.

[filipnavara]

I traced back another issue to the off-by-0x10000 relocation into the BSS sections. This time with frozen objects. :-/

[filipnavara]

I'm now >90% sure that there's a bug in LLD with handling of the MOVW/MOVT relocations. I built the mold linker with eh_frame patch and it doesn't produce the corrupted binaries. For example, the Reflection_FromUsage smoke test successfully passed.

[filipnavara]

I found the issue that causes the data corruption. Relocation.PutThumb2Mov32 takes a 32-bit addend and writes the upper half of the addend to the MOVT relocation. That's not how the ARM ELF relocations work though. They expect the addend to fit within 16-bits and be the same for both the MOVW and MOVT relocation. If the relative offset is something like 0x1c000a and the addend is -12 then the MOVW part has the addend applied correctly but the MOVT part is not (inline addend in the instruction code is 0 instead of -12 and it ends up off-by-one).

[filipnavara]

I don't remember why I made it a separate section.

I presume that the reason is to keep match the layout of the hydrated and dehydrated data in the node without interleaving of other things put into the BSS section. It makes sense to do that while producing the object file. We can tweak the final linked output to merge the sections but it's not really a big difference in the end. The concern I previously had about LLDB debugging experience was caused by the MOVT relocation issue, not the different section name.

[jkotas]

Thank you!