Correct return values for _Objects_Get_class()?
joel.sherrill at oarcorp.com
Wed Oct 24 08:48:41 CDT 2007
Joel Sherrill wrote:
> Phil Torre wrote:
>> I have a question about the _Objects_Get_class() utility function.
>> (RTEMS 4.6.0, on powerpc 8xx, custom BSP)
>> This comes up during a call to pthread_getspecific(). If called in the
>> context of a classic API task, _Objects_Get_class() returns 1. If
>> called from a POSIX thread, it returns 2. These seem to be in conflict
>> with the definition of type Object_APIs, which maps classic to 2 and
>> POSIX to 3. Which one is correct, or is there a subtle "off by one"
>> that is supposed to be there?
>> The reason I noticed is that when pthread_key_create() is called, it
>> allocates an array of key values for each API, and the size of each
>> array is taken from the current "maximum" value for that API. When
>> those allocations are made, they look correct. If I have 50 classic
>> tasks configured, I get ((50+1)*4) bytes of workspace allocated and
>> pointed to by the_key->Values. It seems that pthread_key_create()
>> and pthread_getspecific() are in disagreement about the "class" part
>> of the object IDs.
>> Does anyone know why that is?
> Looks like an off by 1 case. Both set and get specific
> need to subtract 1 from the number returned by
> _Objects_Get_API from what I can tell at 6am.
I am wrong. The allocation does this to set the
pointer to the keys:
the_key->Values[ the_api ] = table;
where the_api = 1..OBJECTS_API_LAST. So the code
in get/set specific should directly use _Objects_Get_API.
I believe the current code in CVS and RTEMS 4.7 is correct.
The code for get/set specific in 4.6 is using class where it
should be using API.
> If you are looking at a version that uses _Objects_Get_class
> instead of _Objects_Get_API, then that is even more broken.
> I see a log that I fixed that much in Nov 2006.
Apparently this was fixed between 4.6 and 4.7 and was
not back ported to the 4.6 branch. For sure this is
NOT correct in 4.6.0. You could be suffering from other
bugs as well with 4.6.0 since we made it all the way
to 4.6.6. :-D
>> Thanks much,
> rtems-users mailing list
> rtems-users at rtems.com
More information about the rtems-users