avr-gcc-list
[Top][All Lists]
Advanced

[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: Joerg Wunsch
Subject: Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags
Date: Wed, 5 Sep 2012 10:04:47 +0200 (MET DST)

In article <address@hidden> you write:

>If you introduce a compatibility check then any usage of libgcc or
>AVR-Libc will trigger a diagnose because these libraries are build
>with the default ABI and none of these options is a multilib option.

Which, in turn, I think would be a really good idea. ;-)

I always thought specifying that -ffoobar nonsense is a poor idea from
the beginning: "char", "signed char", and "unsigned char" must never
be mixed in portable code anyway, so the code should work the same
regardless of any -f option.  (For small integer numbers rather than
printable characters, using C99 uint8_t/int8_t is much preferrable.)
Short enums should be declared by the respective attribute rather than
implying them by a compiler option.  Structure packing is a no-op on
the AVR as it only requires an 8-bit alignment for everything anyway.

So yes, I think encoding them in the object format, and make the
linker warn about mixing differently encoded object modules is a nice
idea.  Of course, object files produced without any of the -f options
should have the respective bits cleard (indicating the default
behaviour), so any old object file that has been compiled using the
default behaviour would not be marked incompatible with a future
object module.
-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

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



reply via email to

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