[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: Vidya Praveen
Subject: Re: [avr-gcc-list] EF_AVR_LINKRELAX_PREPARED bit in e_flags
Date: Thu, 06 Sep 2012 13:18:16 +0530
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120824 Thunderbird/15.0

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 

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.


reply via email to

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