[Top][All Lists]

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

Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags

From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags
Date: Thu, 06 Sep 2012 16:26:26 +0200
User-agent: Thunderbird (Windows/20100228)

Weddington, Eric:
Joerg Wunsch:
Of course, it would have been nice if people wouldn't have started
using these ABI-incompatibility options in the first place, but they do. Yes, I'm partially guilty for spreading them around :) by not thoroughly thinking about what has once been distributed with Mfile. I feel quite sorry for that.

Oh, geez, then we're both guilty of doing that 10 years ago. That's why I asked if this was even a real problem; 10 years and no complaints or issues about this area. (Pretty good track record, IMHO.)

We might perhaps concentrate on the more severe of those flags (-mint8 [cough, cough]

:-P (When can we get rid of it?.....)

It's just been fixed to operate again.  It would be embarrassing to
remove an option because it is broken, better repair it and then
remove it with heads held high.

and -fshort-enums immediately come to mind, as they affect the size
of certain objects).

Point. Should we compile avr-libc with -fshort-enums?

I don't think.  That's an ABI change.  The defaults for these options
are determined by the ABI.  Because there was never a proper ABI
document, the GCC default is used.

Does AVR-Libc expose enums, for example in FILE?

I don't think we should change the ABI too often (if at all).

If a user changes the ABI it's up to him to ensure that everything works
well.  The more ABI aspects he clobbers, the more likely he will run
into problems.  And I still think it's a bug if a IDE sets options that
change the ABI per *default* and without user interaction.  That's rude.

That one is a useful flag. I know that -fpack-struct is a nop. And
-funsigned-char just kind of levels the playing field for those users
who aren't used to using <stdint.h>.

We have currently 16 multilib variants:

$ avr-gcc -print-multi-lib

Every new multilib switch like on/off -f/-fno- will double that number.

If one of these options is *really* needed to be properly supported,
then the only reasonable approach is to promote the option to a
multilib option -- Reasonable modulo the number of multilibs.
Notice that libgcc comes with 1e3..1e4 support functions.

Anything else will flood users with zillions of warnings because the
ABI is changed per option, and I don't see a reason why to flood
users that write code that complies to the ABI by turning the libs

The only solution to avoid these warnings is to support compatibility,
i.e. inflate the number of multilibs again and again.

The only reasonable additional multilib options are IMO -mint8 and
-fno-short-double, maybe -Os/-Ospeed, but they are pointless at the
moment because AVR-Libc does not support them, except -Os in the C
bits.  Moreover, each multilib option like -msp8 has to be hard
coded in AVR-Libc, because its build machinery does not depict
the multilib layout from gcc, AFAIK.


reply via email to

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