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

[Vidya Praveen]

On 9/6/2012 12:52 AM, Weddington, Eric wrote:

>> 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.  
> 
> It's a nice idea, but is it a solution looking for a problem? We haven't
> had any (to my knowledge) issues reported about users linking together 
> incompatible modules. For the most part, an application is built
> altogether at the same time, using the same compiler flags. Rarely do 
> one set of modules, compiled with one set of compiler flags, get linked
> to another set of modules, compiled with a different, incompatible set 
> of compiler flags.
> Let's make sure we're solving real problems, rather than made-up ones.
> If we start including those compiler flags, where does it end? How many
> should we include and check for?

I agree that there's no end to it if we start adding bits for the options.
But I was thinking more in terms of certain characteristics than the options
that drive it.

I first noticed some incompatibility problem reported by a user when he tried
linking to a library - enum xyz as formal parameter causing bad stack, caused by
-mshort-enum used by the user but not by the library. I think such
incompatibility issues will remain to be a problem for people who build 
libraries.

I agree it's not so common that a user uses different flags for different
modules. But that will question why we encode the ISA variation (-march) in the
e_flags (the only use that we have is allowing cross compatibility among archs),
Though I could presume it's because bfd_arch_info_type requires a routine that
checks for compatibility.

Regards
VP