Can't build CVS rtems-4-7-branch

Till Straumann strauman at slac.stanford.edu
Tue Feb 6 23:17:47 UTC 2007


Joel Sherrill wrote:
> Till Straumann wrote:
>> Joel Sherrill wrote:
>>> I think I have fixed all the message queue compilation error issues 
>>> in 4.7 and 4.8.  I
>>> can compile for sparc/leon2 now anyway.
>>>
>>>   
>> Shouldn't we fix that ugly    void*  <-> uint32_t cast (by means
>> of a union) ?
coremsgsubmit.c / coremsgseize.c:

If a sender/submitter has to block  because the  message  queue is full
then it stores the message size in  return_argument_1 (declared void*)

return_argument_1 = (void *)size;

When a receiver comes along and dequeues the first message it also
composes and queues a new message 'on behalf' of the first blocked
sender, retrieving the size from blocked sender's return_argument_1:

the_message->Contents.size = (uint32_t)the_thread->Wait.return_argument_1;

The situation could be cleaned up and the cast eliminated by declaring

thread.h:
...
union {
   void     *p;
   uint32_t s;
} return_argument_1;
...

and letting the receivers ('normal' use) use return_argument_1.p
and the senders use return_argument_1.s.

-- T.
> The problems I was fixing were from Ralf (correctly) changing the 
> arguments to the message
> queue services in the core and various APIs to size_t for message 
> sizes and uint32_t for
> number of messages.

>
> I didn't see any void * <-> uint32_t casts.  What code are you 
> referring to?
>
> FWIW I do see what I think are new warnings on the mvme2100 but 
> haven't looked into
> those yet.
>>
>> T.
>>> There is still a warning on the posix message queue code about 
>>> losing a const.
>>> Probably the core message queue insert prototype should take a 
>>> constant pointer
>>> but I haven't checked that yet.
>>>
>>> --joel
>>>
>>> Joel Sherrill wrote:
>>>  
>>>> Ralf Corsepius wrote:
>>>>     
>>>>> On Mon, 2007-02-05 at 15:49 -0800, Till Straumann wrote:
>>>>>           
>>>>>> You might want to double-check Ralf's post from
>>>>>> over the week-end.
>>>>>>                   
>>>>> Yes, it's related to it. I've started to commit changes related to
>>>>> declarations, to provoke the bug I am suspecting and plan to 
>>>>> commit more
>>>>> similar changes in near future (probably today).
>>>>>
>>>>>           
>>>>>> He probably changed the declaration of _CORE_message_queue_Seize
>>>>>> but you still pick up an old header that's in your build tree
>>>>>>
>>>>>> ../../cpukit/../../../mvme2100/lib/include/rtems/score/coremsg.h:
>>>>>>                   
>>>>> May-be, may-be I missed something. I thought, I was carefully 
>>>>> checking
>>>>> not to break something, but ... may-be I did - To be investigated.
>>>>>
>>>>>             
>>>> It also looks like librtems++ does not compile.  I just committed 
>>>> changes
>>>> to get that to compile but it looks like the librtems++ test needs 
>>>> tweaking
>>>> also.
>>>>
>>>> I will try to compile some more and see if I can fix that.
>>>>
>>>> --joel
>>>>     
>>>>> Ralf
>>>>>  
>>>>>
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.com
>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>>             
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.com
>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>       
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>   
>>
>




More information about the users mailing list