OK, I tracked down the crash to the point where the compiler tries to emit unaligned data longer than one byte. The normal course of operations is to decompose the unaligned value into a series of smaller, hopefully aligned values. Ultimately, this breaks down to emitting a series of individual bytes. That's where the trouble begins.

I had previously forbade the compiler from allowing subreg expressions which resulted in byte values. This was done in order to support the bytewise instructions. In this case, the code emitter (in varasm.c) has no other strategy to fall back on, and fails an assertion, crashing the compiler.

I was able to get around this by defining fake data types to handle these cases. This beat the compiler into submission enough to output an object file with Dwarf2 info. Unfortunately, it's terrible. The compiler is adding 4-byte relocations for a machine with 2-byte addresses. The assembler choked on that one. Also, the emitted byte order is little-endian which is not helpful either.

By default, GCC is using ".2byte" directives to embed a two byte value. This is the opposite endianness of TI's "data" directive. This results in Dwarf sections which are utter jibberish. I manually swapped the bytes for some test sections, and that seems to result in a properly-formatted section. Now I have to find a way to decompose all dwarf values into "data" and "byte" values. This may be tricky, since only some of the dwarf generating code can be overridden by the target definition in tms9900.h

It looks like the TARGET_ASM_INTEGER macro can be defined to let us take over the job of emitting integer data. In fact here are a couple other machines which need special attention in this area. So I shamelessly stole some ideas from them. So now the data is the right endianless and nothing is crashing, but tms9900-objdump is complaining about malformed debug sections. Ugh.