<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: Correct return values for _Objects_Get_class()?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Okay, that makes sense. I will patch our 4.6.0 tree accordingly (and add<BR>
this to the case for migrating at least to 4.7).<BR>
<BR>
Thanks, Joel!<BR>
<BR>
-Phil<BR>
<BR>
-----Original Message-----<BR>
From: Joel Sherrill [<A HREF="mailto:joel.sherrill@oarcorp.com">mailto:joel.sherrill@oarcorp.com</A>]<BR>
Sent: Wed 24-Oct-07 6:48 AM<BR>
To: Phil Torre<BR>
Cc: RTEMS User List<BR>
Subject: Re: Correct return values for _Objects_Get_class()?<BR>
<BR>
Joel Sherrill wrote:<BR>
> Phil Torre wrote:<BR>
> <BR>
>> I have a question about the _Objects_Get_class() utility function.<BR>
>><BR>
>> (RTEMS 4.6.0, on powerpc 8xx, custom BSP)<BR>
>><BR>
>> This comes up during a call to pthread_getspecific(). If called in the<BR>
>> context of a classic API task, _Objects_Get_class() returns 1. If<BR>
>> called from a POSIX thread, it returns 2. These seem to be in conflict<BR>
>> with the definition of type Object_APIs, which maps classic to 2 and<BR>
>> POSIX to 3. Which one is correct, or is there a subtle "off by one"<BR>
>> that is supposed to be there?<BR>
>><BR>
>> The reason I noticed is that when pthread_key_create() is called, it<BR>
>> allocates an array of key values for each API, and the size of each<BR>
>> array is taken from the current "maximum" value for that API. When<BR>
>> those allocations are made, they look correct. If I have 50 classic<BR>
>> tasks configured, I get ((50+1)*4) bytes of workspace allocated and<BR>
>> pointed to by the_key->Values[2]. It seems that pthread_key_create()<BR>
>> and pthread_getspecific() are in disagreement about the "class" part<BR>
>> of the object IDs.<BR>
>><BR>
>> Does anyone know why that is?<BR>
>> <BR>
>> <BR>
> Looks like an off by 1 case. Both set and get specific<BR>
> need to subtract 1 from the number returned by<BR>
> _Objects_Get_API from what I can tell at 6am.<BR>
> <BR>
I am wrong. The allocation does this to set the<BR>
pointer to the keys:<BR>
<BR>
the_key->Values[ the_api ] = table;<BR>
<BR>
where the_api = 1..OBJECTS_API_LAST. So the code<BR>
in get/set specific should directly use _Objects_Get_API.<BR>
<BR>
I believe the current code in CVS and RTEMS 4.7 is correct.<BR>
The code for get/set specific in 4.6 is using class where it<BR>
should be using API.<BR>
> If you are looking at a version that uses _Objects_Get_class<BR>
> instead of _Objects_Get_API, then that is even more broken.<BR>
> I see a log that I fixed that much in Nov 2006.<BR>
> <BR>
Apparently this was fixed between 4.6 and 4.7 and was<BR>
not back ported to the 4.6 branch. For sure this is<BR>
NOT correct in 4.6.0. You could be suffering from other<BR>
bugs as well with 4.6.0 since we made it all the way<BR>
to 4.6.6. :-D<BR>
<BR>
--joel<BR>
> --joel<BR>
><BR>
><BR>
><BR>
> <BR>
>> Thanks much,<BR>
>> -Phil<BR>
>><BR>
>> <BR>
>> <BR>
><BR>
> _______________________________________________<BR>
> rtems-users mailing list<BR>
> rtems-users@rtems.com<BR>
> <A HREF="http://rtems.rtems.org/mailman/listinfo/rtems-users">http://rtems.rtems.org/mailman/listinfo/rtems-users</A><BR>
> <BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>