Correct return values for _Objects_Get_class()?

[Joel Sherrill]

Phil Torre wrote:
>
> Okay, that makes sense.  I will patch our 4.6.0 tree accordingly (and add
> this to the case for migrating at least to 4.7).
>

And remember that incremental versions along a branch are
supposed to be pain-free and bug fix only.  So stopping
at 4.6.0 means you missed > one bug fix. :-D

--joel
>
>
> Thanks, Joel!
>
> -Phil
>
> -----Original Message-----
> From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Sent: Wed 24-Oct-07 6:48 AM
> To: Phil Torre
> Cc: RTEMS User List
> Subject: Re: Correct return values for _Objects_Get_class()?
>
> 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[2].  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
>
> --joel
> > --joel
> >
> >
> >
> >  
> >> Thanks much,
> >> -Phil
> >>
> >>  
> >>    
> >
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >  
>
>