Re: crash fails to build with gcc-4.5

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

 



----- "Troy Heber" <troy.heber@xxxxxx> wrote:

> When trying to build crash with gcc-4.5 on x86-64 you get:
> 
>   unwind_x86_32_64.c:50:2: error: initializer element is not constant
>   unwind_x86_32_64.c:50:2: error: (near initialization for 'reg_info[7].offs')
>   unwind_x86_32_64.c:50:2: error: initializer element is not constant
>   unwind_x86_32_64.c:50:2: error: (near initialization for 'reg_info[8].offs')
>   unwind_x86_32_64.c:50:2: error: initializer element is not constant
>   ...
> 
> When you start to dig into this you quickly end up playing with lots
> of really fun macros from unwind_x86_64.h. Eventually, you end up
> playing with this one:
> 
> 	#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
> 
> If you pull this macro out and play with it by itself it seems to
> work fine with both gcc-4.5 and gcc < 4.5. It is only when it is used in
> combinations with the other macro expression that gcc-4.5 fails to
> evaluate it and I have no clue why. 
> 
> When looking at the BUILD_BUG_ON_ZERO macro upstream in
> include/linux/kernel.h we can see it has been replaced with this
> version:
> 
> 	#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
> 
> It turns out that gcc-4.5 is perfectly happy with the updated version!
> 
> 
>   This was done in commit: 8c87df457cb58fe75b9b893007917cf8095660a0
> 
>   BUILD_BUG_ON(): fix it and a couple of bogus uses of it 
> 
>   gcc permitting variable length arrays makes the current construct used for
>   BUILD_BUG_ON() useless, as that doesn't produce any diagnostic if the
>   controlling expression isn't really constant.  Instead, this patch makes
>   it so that a bit field gets used here.  Consequently, those uses where the
>   condition isn't really constant now also need fixing.
> 
>   Note that in the gfp.h, kmemcheck.h, and virtio_config.h cases
>   MAYBE_BUILD_BUG_ON() really just serves documentation purposes - even if
>   the expression is compile time constant (__builtin_constant_p() yields
>   true), the array is still deemed of variable length by gcc, and hence the
>   whole expression doesn't have the intended effect.
> 
> It looks like this could end up being a potential bug in gcc. I'll
> file a bug with gcc and try to provide them with a simplified test
> case. However, since this macro changed upstream and acts as a
> workaround for the issue I would propose making the update in crash 
> as well.
> 
> Troy

I've been tempted to just rip out unwind_x86_32_64.c, unwind_x86_64.h
and unwind_x86.h since they're pretty much useless.  The unwind code
in those files is only used if explicitly requested by "set unwind on"
*and* if the kernel supports it (which it hasn't since Jan Beulich's
x86/x86_64 temporary DWARF/unwind stuff was pulled).

But thanks for digging this out -- queued for the next release.

Dave


> 
> ---
> diff --git a/unwind_x86_64.h b/unwind_x86_64.h
> index a79c2d5..52fcf7a 100644
> --- a/unwind_x86_64.h
> +++ b/unwind_x86_64.h
> @@ -61,7 +61,7 @@ extern void free_unwind_table(void);
>  #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
>  #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>  #define BUILD_BUG_ON(condition) ((void)sizeof(char[1 -
> 2*!!(condition)]))
> -#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
> +#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>  #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
>  #define get_unaligned(ptr) (*(ptr))
>  //#define __get_user(x,ptr) 
> __get_user_nocheck((x),(ptr),sizeof(*(ptr)))
> 
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility

[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux