Thursday, 23 July 2020

Re: [gccsdk] New SharedLibs incompatibility

On 23/07/2020 16:05, Chris Johns wrote:
> I'd better get compiling.
>
> However, if I build it again the new libs I assume it won't work with
> the older ones?

In theory, we might get away with it, but only if I change
__pthread_cond again. The original one was:

struct __pthread_cond
{
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};

and the new one:

struct __pthread_cond
{
/* Absolute (CLOCK_REALTIME) or relative (CLOCK_MONOTONIC) clock? */
clockid_t clock_id;
/* Linked list of threads that are blocked on this condition var. */
struct __pthread_thread *waiting;
};

In hind sight, I should have placed "clock_id" *after* "waiting". The
code in python is attempting to access "waiting", but getting "clock_id"
instead, hence the value of 1 being used as an address. A rebuild
against the new pthread.h will fix this but not for old libraries.

I will swap the order of "clock_id" and "waiting" now.

If python is then compiled against this new pthread.h and run using an
old unixlib, then it will allocate an object larger than necessary
(which is OK) and "waiting" will be in the right place.

Lee.

_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

No comments:

Post a Comment