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

[Joel Sherrill]

Till Straumann wrote:
> 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:
>
I'm sorry.  This was the patch which was in my queue.  This is a
perfectly reasonable way of doing this.

It makes sense that the return argument(s) in the TCB be a union
of whatever primitive types make sense.  You most often need
some type of integer and/or a pointer.
> 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
>>>>   
>>>
>>
>
`