Early draft of DWARF standard

[johnwbyrd]

Greetings all, it's Byrd from over at your friendly https://www.llvm-mos.org project. We've gotten our ELF specification more or less firmed up, at least to the point that the llvm-mos project is able to support a couple dozen targets with it. ELF, as you know, is an Executable and Linkable Format file, which can be baked into all the various 65xx binary formats that people want to run. A high-level overview of that spec is here: https://llvm-mos.org/wiki/ELF_overview

Anyway, over the past few months I've been turning my attention to the DWARF standard: https://dwarfstd.org/. Certainly, 65xx developers want a way to be able to do consistent source-level debugging, across assembler and C and a bunch of other languages. What I'm thinking about, is a generic standard, that you can use to provide or receive source-level debugging for your favorite 65xx platform, presumably but not exclusively in conjunction with the ELF format.

I care about your opinion, because a lot of compiler and platform designers screw DWARF up by making bad assumptions; and those bad assumptions get baked into ABIs and platforms forever and ever. Specifically, I have biased this design into extreme forward compatibility, to allow for all the wacky stuff that you 65xx guys may want to debug in the future.

I have an early working draft here: https://llvm-mos.org/wiki/DWARF_specification But, it's still very early days, and I'd love to have anyone interested in source-level debugging, to help me think through the ramifications of a forward-thinking DWARF specification for our common goals. Feel free to comment here, or e-mail me directly at johnwbyrd at gmail dot com .

[BigEd]

This seems like a good thing! Unfortunately, I have nothing to contribute. But I hope the endeavour goes well.

[rudla.kudla]

Here are some of my suggestions/questions.
Be warned, that me being not familiar with the DWARF system, they may not be very insightful

Formal suggestions
------
The table "Chipset registers" start with row
31 Chipset Flag Always 1 Identifies chipset space

It would be more readable, if the table "Processor register formats" started with similar line.
------
Chapter "Format selection by family" would fit better as subsection of "Processor register formats". The question of how we will determine the proper format suck in my mind until i found that paragraph and that was too long

Technical questions
---------
Would not it be better to split families to two subsets by range - defining format in future proof way? As it is currently defined, any tool written now has no way of supporting future families without recompilation.
---------
For 6502 Type 0x03: RS imaginary registers (16-bit)

128 registers are supported. However you can use 16 bit value at any position in zero page, so there are hypothetically 255 of two byte registers. Do i miss something? how are these registers supposed to be used?

[barrym95838]

rudla.kudla wrote:

... so there are hypothetically 255 of two byte registers ...

Hypothetically 256, because $FF wraps to $00, right?

[BigDumbDinosaur]

johnwbyrd wrote:

We've gotten our ELF specification more or less firmed up, at least to the point that the llvm-mos project is able to support a couple dozen targets with it. ELF, as you know, is an Executable and Linkable Format file, which can be baked into all the various 65xx binary formats that people want to run. A high-level overview of that spec is here: https://llvm-mos.org/wiki/ELF_overview...

From the ELF overview page:

Quote:

This is a specification to extend the Executable and Linking Format (ELF) to encompass the MOS family of processors and their relatives. These include, but are not limited to, the MOS 6502, the MOS 65816, and comparable processors.

There is no such a thing as a “MOS 65816”.    That should say “WDC 65C816” so it will correctly show up in search engines.

[johnwbyrd]

Quote:

There is no such a thing as a “MOS 65816”.    That should say “WDC 65C816” so it will correctly show up in search engines.

Fixed, thank you.

[johnwbyrd]

Quote:

Would not it be better to split families to two subsets by range - defining format in future proof way? As it is currently defined, any tool written now has no way of supporting future families without recompilation.

I think that's a tautology. If you don't know the meaning of a future DWARF register then by definition you can't write code to deal with it.

Quote:

128 registers are supported. However you can use 16 bit value at any position in zero page, so there are hypothetically 255 of two byte registers. Do i miss something? how are these registers supposed to be used?

Imaginary registers are not assigned a specific location in memory until linking is completed. The register numbering remains fixed while the location of the registers may change. See also https://llvm-mos.org/wiki/Imaginary_registers .

[johnwbyrd]

I will further mention that I have an implementation which gives rich debugging information for C programs. We're going to be releasing this over the next few months, and it should provide a lot more visibility into 6502 development than what most people are used to.