[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Serious Bug All Targets -- Please Read
- Date: Tue, 03 Mar 2009 09:26:58 +0100
- From: ralf.corsepius at rtems.org (Ralf Corsepius)
- Subject: Serious Bug All Targets -- Please Read
Till Straumann wrote:
> Ralf Corsepius wrote:
>> Till Straumann wrote:
>>> Ralf Corsepius wrote:
>>>> Till Straumann wrote:
>>>>> Hmm - AFAIK, c99 doesn't specify the exact representation
>>>>> of 'bool' / '_Bool'. It only says that
>>>>> "An object declared as type _Bool is large enough to store the
>>>>> values 0 and 1"
>>>>> Hence, there is no really safe way to access such
>>>>> an object from assembly code.
>>>>> I wonder if it wouldn't be better to change the
>>>>> type of _Context_Switch_necessary & friends
>>>>> to a type of known width.
>>>> IMO, no.
>>>> We should change to code into something which doesn't need to know
>>>> the size of a type, rsp. automatically gets it right.
>>> So how would you do that given the requirement
>>> that these variables need to be available to
>>> assembly code, maybe w/o a stack available?
>> E.g. by rewriting the code in question in C
> That's what the new PPC framework does.
>> w/ inline asm. This isn't always possible, but is possible on many
>> occasions, even when stack is not available.
> w/o stack I'm not sure...
You can do something like this (Pseudo-C code):
extern bool var;
asm( ENTRY_SYMBOL(foo) );
asm( PROCESS(var) );
asm( RETURN );
I.e. to use a C-function wrapper/stub and insert asm-functions inside of
this function. It's a dirty hack, but it works quite well.
A real world example based on this approach in RTEMS can be found in
>> It also somewhat (not always) helps to catch such size mismatches early.
>> Another possibility would be not to use _Bool for them (Which is the
>> type GCC interally uses), but to use an "int"
> Well - that's what I originally proposed (int32_t actually).
> IMO changing the type of these critical variables from bool -> int32_t
> is least intrusive and probably the best solution for a 4.9.2
The problem with this is: Some rtems < 4.9 targets have used short