This is an archive of the discontinued LLVM Phabricator instance.

[MSP430] Enable some basic support for debug information
ClosedPublic

Authored by atrosinenko on Jun 9 2020, 10:55 AM.

Details

Summary

This commit technically permits LLVM to emit the debug information for ELF files for MSP430 architecture. Aside from this, it only defines the register numbers as defined by part 10.1 of MSP430 EABI specification (assuming the 1-byte subregisters share the register numbers with corresponding full-size registers).

This commit was basically tested by me with TI-provided GCC 8.3.1 toolchain by compiling an example program with clang (please note manual linking may be required due to upstream clang not yet handling the -msim option necessary to run binaries on the GDB-provided simulator) and then running it and single-stepping with msp430-elf-gdb like this:

$sysroot/bin/msp430-elf-gdb ./test -ex "target sim" -ex "load ./test"
(gdb) ... traditional GDB commands follow ...

While this implementation is most probably far from completeness and is considered experimental, it can already help with debugging MSP430 programs as well as finding issues in LLVM debug info support for MSP430 itself.

One of the use cases includes trying to find a point where UBSan check in a trap-on-error mode was triggered.

The expected debug information format is described in the MSP430 Embedded Application Binary Interface specification, part 10.

Diff Detail

Event Timeline

atrosinenko created this revision.Jun 9 2020, 10:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 9 2020, 10:55 AM

Can this be tested by checking assembler output?

aprantl accepted this revision.Jun 19 2020, 9:49 AM
aprantl added inline comments.
llvm/test/DebugInfo/MSP430/dwarf-basics.ll
115

please remove all non-essential attributes (everything in quotes is a good start). They make tests difficult to maintain.

This revision is now accepted and ready to land.Jun 19 2020, 9:49 AM

Thanks! I have dropped the entire #0 and #1 attribute lists - that did not change the output. All the debug information nodes, on the other hand, were left intact (just in case) apart from omitting some parts of the producer string.

The patch was re-uploaded as two commits (that information was accidentally lost during previous update via web interface).

Meanwhile, is it acceptable that byte-sized and word-sized registers share the same DWARF register numbers such as r12 (16 bit) and r12b (8 bit) in this example?

Meanwhile, is it acceptable that byte-sized and word-sized registers share the same DWARF register numbers such as r12 (16 bit) and r12b (8 bit) in this example?

These kinds of decisions are supposed to be specified by the ABI document for the platform (not in the DWARF standard), so you'd have to direct this question to whatever consortium defines the ABI for MSP430.

Meanwhile, is it acceptable that byte-sized and word-sized registers share the same DWARF register numbers such as r12 (16 bit) and r12b (8 bit) in this example?

These kinds of decisions are supposed to be specified by the ABI document for the platform (not in the DWARF standard), so you'd have to direct this question to whatever consortium defines the ABI for MSP430.

Thank you for the explanation! The MSP430 EABI document released in 2013, part "10.1 DWARF Register Names", mentions R0-R15 register numbers only. Recent msp430-gcc v8.3.1 does recognize

cpp
char g(void) {
  register char y asm("r6");
  return y;
}

but does not recognize asm("r6b"). So, maybe R*B are more of LLVM internal abstractions.

Unit test failure here is expected because D82055: [DebugInfo] Explicitly permit addr_size = 0x02 when parsing DWARF data have to be landed before.

asl accepted this revision.Jun 22 2020, 3:13 AM

LGTM, thanks!

This revision was automatically updated to reflect the committed changes.