Re: [avr-gcc-list] [Fwd: building gcc/g++]

[Peter Jansen]

Hi Marek,


> Good work, thanks.  But - please check the latest CVS tree (not the
> GCC 3.0.x stable branch), I'm now slowly adding the missing pieces to
> support all these newly released devices...


Excellent.


> > Also attached is a new piece of startup code, and linker script.
>
> Linker scripts are auto-generated and I'd like to do them once for
> all new devices, in the hope to not have to do this too often...
> Besides C++ support, one thing I'd like to add is a new ".noinitdata"
> section, above BSS, for global variables that are not initialized by
> C startup code (for data to survive across external or WDT reset).


I don't have any problems with that and it sounds like a good idea. As 
for the new devices its only the small script inputs that need creating, 
fixing the script it self is quite easy.


> Some comments about the C++ changes - I don't know much about C++ so
> please don't get too angry at me ;)
>
>  - would it be OK to call __do_global_ctors from the main() function
>    prologue, after stack initialization, without changing gcrt1.S,
>    and do it only for C++ compilation?  I think C++ support shouldn't
>    bloat ordinary C programs, or force people using only C to upgrade
>    everything (gcc, binutils, libc) at once...  Mostly a support
>    issue - I'm still getting bug reports about latest avr-libc not
>    working with gcc 2.95.2, people only read docs if all else fails ;)


When the main function is created its like all other functions as far as 
the compiler is concerned, the only thing that makes it special is that 
its called from crtx so I cant get the compiler to put a call to the 
constructors only in the main function.

Could I have 4 bytes in the startup code to support C++, something like

;; Call any C++ constructors
        CALL _U(__do_global_ctors)
        .weak _U(__do_global_ctors)

;; Call Main function


>  - no need to use RAMPZ (I'd like to make this code work on all
>    devices, not just ATmega128) - just put these tables at the lowest
>    addresses in the linker script (above ".init" section) so they will
>    fit within the lower 64K of program memory.  GCC already does this
>    with jump tables for "switch", in section ".progmem.gcc_sw_table".
>    The whole upper 64K can still be used for normal executable code,
>    without any of these inefficient 3-byte addresses...


Is the RAMPZ avaliable on all avr5 devices?

I was going to put some more if's around this for other devices.

The addresses in the table are 16 bit program space word addresses.

The .init and .ctors sections would have to be in the lower 64K which 
might be ok, but can we if around the to make it work properly for 
anything above 64K?


>  - since we have no shared libraries, the ctor tables could be marked
>    as read only, they are in flash anyway.  Or does it cause problems?


An over sight on my part, its was like that in the code I copied this from.


>  - do we need to support destructors too?  AVR program never exits,
>    main() ends with an infinite loop, where is __do_global_dtors called?


This is always a problem with exit functions in embedded code.

__do_global_dtors should be called from the exit code, I have not put 
this in because its not needed in an embedded system, I was going to 
clean this up some more, I was just happy that I got it working to start 
with :-)


>  - GCC maintainers generally like small patches, one patch for each
>    logical change.  This makes things a lot easier...


Ok, Ill get the CVS, make a patch for the mega128 and then a patch for 
the C++ support. This work affects binutils, gcc, and your avr-libc.

Regards,

--
Peter Jansen
Smart Container
Level 1, NIC Building
Eveleigh
NSW       1430
AUSTRALIA


avr-gcc-list at http://avr1.org