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