[avr-libc-dev] Debug information; IO register information

[Joerg Wunsch]

I committed a number of changes regarding debug information during the
past days.

The first is a new configure option, --with-debug-information.  It
accepts an argument of either "stabs", "dwarf-2", or "dwarf-4".  The
default is "no", meaning no debugging information will be generated
when compiling the library.  This is in particularly suitable for any
party who wants to distribute binary versions of the library where the
users don't have the source code installed, so any debugging
information pointing to the original source code makes no sense at
all.

The "stabs" argument makes the compiler (and assembler) generate stabs
debugging information.  This is mostly historical now, suitable for
older debuggers including the VMlab software (through the avr-coff
converter patch for binutils), and old AVR-GDB versions.

"dwarf-2" and "dwarf-4" are for more modern debuggers who understand
DWARF version 2 or 4, respectively.


The second change is something I always wanted to have, but never
really tracked it down to any usable implementation.  It adds
debugging information for each AVR's IO registers (and for the EEPROM
as well), so they can be accessed through their names from within
debuggers.  Many thanks to Knut Schwichtenberg for being insistive on
the matter ;-), for tinkering with certain ideas how to implement it.
Even though we ended up not using one of his ideas, his input and
testing was very valuable.

The implementation works by synthesizing one DWARF-2 symbol for each
IO register.  As the only file that is always available on a per-CPU
basis is crt*.o, this DWARF-2 information gets included into the
crt*.o files.  That way, any application linking the librarie's
startup code automatically benefits from it.

The DWARF-2 information itself is generated by first running an XSL
transform on the Atmel Studio 6.x device XML file, yielding a list of
IO registers and their addresses.  (The XSL stylesheet for this can be
found under devtools/findreg.xsl.)  Then, the script devtools/ioreg.pl
picks up that list, and synthesizes one DWARF-2 Debug Information
Entry (DIE) for each IO register.  The output of this script is
supposed to be stored in a file crt1/iosym/$devname.S, from where
gcrt1.S will pick it up when being assembled.  Since we are not
allowed to store the original Atmel Studio XML files in our tree, we
instead store the generated .S files.  That's no problem, because only
developers who add support for a new device do have a need to
regenerate the $devname.S file for their new device.  If, for whatever
reason, there is no XML file available for some device (like, for
older AT90* devices which are not supported by Atmel Studio 6), a file
named crt1/iosym/template.S can be copied over to $device.S as a
placeholder.  This is just so gcrt1.S can pick up that placeholder
file, and doesn't complain.  No debug information is generated in that
case.

The synthesized debug information has been thoroughly crafted to not
reference any souce file or directory, so debuggers won't start to
query the user for the "new location" of a source file.

IO registers are named as their names appear in the datasheet.
Registers consisting of two (or more) bytes just get their basename,
like TCNT1 for the combined TCNT1H/TCNT1L register.  For Xmega
devices, the long, non-structured form of the name is supported, like
USARTC0_DATA (rather than USARTC0.DATA).

The EEPROM is defined as one array of uint8_t of the appropriate
length, with the name __eeprom[].
-- 
cheers, Joerg               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/
Never trust an operating system you don't have sources for. ;-)