Re: [avr-libc-dev] Re: Patches to add mega325-3250-645-6450 to binutils and gcc.

[Marek Michalkiewicz]

On Tue, Mar 15, 2005 at 09:57:03AM -0700, E. Weddington wrote:

> What if the library doesn't exist? Would it error? Or just silently 
> continue?

There would be a linker error, just like when you specify -lfoo when
libfoo.a doesn't exist.

> Because if it just silently continues, then one can add the change to 
> LIB_SPEC for all devices, and then if we need them at a later point we 
> could create them later without any errors.

The library must exist if -mmcu=... is specified, so we can't easily
have backwards compatibility - new avr-gcc requires new avr-libc.

I'm also thinking about possibly separating selection of device type
(-mmcu) from architecture (-march=... as supported by other targets).
Generic (not per-device) library code would be compiled without -mmcu
and -march would then decide which multilib variant to use.

> I would heartily agree to this. IIRC WinAVR doesn't work to well on 
> Win95, which is no longer supported by MS anyway. So we're dealing with 
> Win98 and forward, all of which AFAIK have long filename support. We're 
> building GCC for a Windows (MinGW) host, not for DJGPP. So I'm all for 
> dropping 8.3 filename support.

And, I think recent DJGPP and FreeDOS have LFN support too.

> Could you give a little more detail in how/where the spec strings could 
> be simplified?

See CRT_BINUTILS_SPECS in gcc/config/avr/avr.h - many rules which
basically say which crt*.o to use for which device, and currently
every known device type is listed there because of these shortened
names.  Instead, %* as part of the filename would expand to the
device name (as specified in -mmcu=...).

> If you don't have much time, have you considered seeing if there can be 
> another AVR maintainer for GCC? You've been the one comitting patches 

It is good to see more people contributing code, and yes - it is
quite possible we may have another maintainer soon.  For now,
committing patches is no big problem for me, but I rely on other
people to test them properly (my own testing is limited).

The time problem comes mainly when many big changes have to be made
to all of binutils, gcc and avr-libc at the same time (like when
adding new architectures), so that things are broken for the shortest
possible time.  Also, I don't see supporting larger than 16-bit
pointers realistic anytime soon, so ATmega256x support may remain
limited for a long time.

> recently. Denis doesn't seem to be doing a whole lot on the port. If 

Recently he has been helpful on a few difficult bugs (he understands
GCC internals better than I do).

Marek