[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Alpha testers wanted...

From: Joerg Wunsch
Subject: [avr-gcc-list] Alpha testers wanted...
Date: Tue, 29 Apr 2003 18:06:07 +0200
User-agent: Mutt/1.2.5i

...for my patch to the GNU binutils.

The patch is going to implement the frequently requested item of
producing AVR (extended) COFF that is needed for COFF consumers like
AVR Studio and VMLAB.  All the currently available tools for doing
this failed so far, due to lack of maintenance, and also due to taking
the IMHO wrong approach of trying to implement everything from
scratch, when most of the infrastructure is already available as part
of the GNU binutils (ELF handling, most of the required generic COFF
handling, stabs parser, proven BFD framework, well-proven command-line
tools like objdump and objcopy).  That's why i instead started over,
and taught the GNU binutils to handle the COFF format as defined by

COFF itself is a known item for GNU binutils, there are currently
already more than two dozens of different COFF formats supported.
That's not such a big surprise, given that COFF has historically been
the object file format of UNIX SVR3.  So it wasn't too hard to adapt
one of the existing COFF backends to basically support the AVR version
(though Atmel has been leaving the generic COFF path on a number of
occasions, probably because they simply didn't even look around first,
and thus re-invented some wheels).  The harder part of the task
required to convert the stabs debugging information in our ELF files
into that <censored> oldish COFF debugging format they've chosen at
Atmel.  Fortunately, objcopy already offers a --debugging option that
converts stabs (or any other recognized debugging information from the
input file) into a generic internal debugging tree, so a i didn't have
to handle that, but could concentrate on writing the COFF debugging

The job is done by about maybe 90 % now.  The remaining TODO items on
my personal list involve things like completing struct debugging
support (so far, the supplied struct debugging information is
understood, the generated symbols indicate struct types, but no
information about the struct types itself is generated), writing enum
debug support (not even understood by AVR Studio 4, but similar enough
to structs so it should not be much work).  So i'd now like to ask for
some more alpha testers who'd be willing to give all this a try in
their daily work.

I'd like to thank Markus Assfalg for all his input from the first
alpha tests that were done so far.  I'd also like to publically thank
Svenn-Ivar Svendsen from Atmel Norway, who willingly answered my
questions regarding Atmel's COFF specs, and sent me some updated DLLs
for AVR Studio 4 that fix/improve the handling of the COFF files
produced by the patched GNU binutils.  I should be able to pass his
(inofficial) fixed DLLs on to anybody who wants to alpha test all
this.  (There's one bugfix in them that handles COFF files that don't
have the expected section order, and one improvement where COFF files
that are marked as being produced by GNU binutils will have their
.data contents loaded into the simulator flash right after .text, so
the initialization will work.  Note that all this will only work with
AVR Studio 4, and is completely meaningless unless used in combination
with the binutils patch.)

Prerequisites: be prepared to compile the GNU binutils yourself, so
you can apply new patches. I cannot create Windows binaries myself, so
this is currently necessary.  If anybody is serious about this, he'll
certainly get Erics support for questions regarding what is required
to do this compilation.

Needless to say, anybody who's going to do this should have some basic
knowledge how to call a command-line tool (most notably avr-objcopy in
this case), either from the command-line itself, or within a Makefile
of their own.

Once alpha tests are successful, and the remaining TODO issues are
resolved, i expect Eric to also provide some publically available
Windows binaries for beta testers.

Again, serious alpha testers are welcome, anybody who just wants to
give it a try should rather wait for public betas though.
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]