PPC Versions of Glibc and GCC Status

PPC Versions of Glibc and GCC Status

[Jeffrey Hawkins]

Frank,

I am currently utilizing your current versions of GCC
2.95.3-2c and GLIB2.1.3-15d for my development.  Thanks
for all the hard work....

I am experiencing a few issues with LinuxThreads, which upon
querying the GNU developers/lists, I have found the issues
may have been fixed in the 2.1.9x and 2.2-beta versions.
The required fixes are in the LinuxThreads Library, as well
as, in other Libraries.

Are you currently integrating/migrating your
2.1.3 versions with 2.1.9x or 2.2.x ?  If you are not
planning on doing this, have the changes you have made,
or the changes by other LinuxPPC Developers, both to the
GCC and GLIBs, been submitted and incorporated in the GNU
running changes ?

I am just starting the process of going through the Source
for 2.1.91 and checking the differences with the 2.1.3-15d.
I am querying you on your efforts, and others, so that I don't
waste time duplicating what has already been done.  I was
hoping to use GLIB 2.1.91 off the shelf, but I know this
will probably not be the case.

Any feedback, or tips on things to look out for (such as
Libraries/Modules you had to make extensive updates to, #ifdefs
and #defines that need to be added for PowerPC), would be
appreciated.  I will be making the Source Tarballs and RPMs
available once I have completed this task.



Jeff

--
********************************************************

Jeffrey Hawkins

Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering

Address: DEPT:  DQ525
         MS:    IL-02-1055A
         1301 East Algonquin Road
         Schaumburg, IL 60196

Phone:   (847)576-7463
FAX:     (847)576-7737

********************************************************

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Versions of Glibc and GCC Status

[Jeffrey Hawkins]

Franz,

I noticed after sending you the e-mail, that I addressed
you as Frank, rather than Franz.  My apologies, I guess
I have Frank on the brain, since I work closely with a
Frank...

Jeff


Jeffrey Hawkins wrote:
>
> Frank,
>
> I am currently utilizing your current versions of GCC
> 2.95.3-2c and GLIB2.1.3-15d for my development.  Thanks
> for all the hard work....
>
> I am experiencing a few issues with LinuxThreads, which upon
> querying the GNU developers/lists, I have found the issues
> may have been fixed in the 2.1.9x and 2.2-beta versions.
> The required fixes are in the LinuxThreads Library, as well
> as, in other Libraries.
>
> Are you currently integrating/migrating your
> 2.1.3 versions with 2.1.9x or 2.2.x ?  If you are not
> planning on doing this, have the changes you have made,
> or the changes by other LinuxPPC Developers, both to the
> GCC and GLIBs, been submitted and incorporated in the GNU
> running changes ?
>
> I am just starting the process of going through the Source
> for 2.1.91 and checking the differences with the 2.1.3-15d.
> I am querying you on your efforts, and others, so that I don't
> waste time duplicating what has already been done.  I was
> hoping to use GLIB 2.1.91 off the shelf, but I know this
> will probably not be the case.
>
> Any feedback, or tips on things to look out for (such as
> Libraries/Modules you had to make extensive updates to, #ifdefs
> and #defines that need to be added for PowerPC), would be
> appreciated.  I will be making the Source Tarballs and RPMs
> available once I have completed this task.
>
> Jeff
>
> --
> ********************************************************
>
> Jeffrey Hawkins
>
> Senior Staff Software Engineer
> Motorola Wireless Data Solutions Engineering
>
> Address: DEPT:  DQ525
>          MS:    IL-02-1055A
>          1301 East Algonquin Road
>          Schaumburg, IL 60196
>
> Phone:   (847)576-7463
> FAX:     (847)576-7737
>
> ********************************************************
>

--
********************************************************

Jeffrey Hawkins

Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering

Address: DEPT:  DQ525
         MS:    IL-02-1055A
         1301 East Algonquin Road
         Schaumburg, IL 60196

Phone:   (847)576-7463
FAX:     (847)576-7737

********************************************************

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Versions of Glibc and GCC Status

[Kevin B. Hendricks]

Hi,

There is a mutex bug in the glibc 15d rpms that Blackdown found and sent to
the libc-alpha list.  It prevented linuxthread 15c and 15d rpms from
working correctly.  Please try with Franz's glibc-2.1.3-5a rpms, they work
fine for the jdk.  I will pass the patch along to Franz and hopefully there
will be a 15e rpm set out that should work fine for you (it does for the
JDK anyway).

I have attached the patch which you can use to make your own 15e rpm until
Franz gets a chance.

Hope this helps.

Kevin

RCS file: /cvs/glibc/libc/linuxthreads/mutex.c,v
retrieving revision 1.9.2.4
diff -u -r1.9.2.4 mutex.c
--- mutex.c     2000/07/31 15:31:21     1.9.2.4
+++ mutex.c     2000/08/09 21:43:57
@@ -109,8 +109,8 @@
 {
   switch (mutex->__m_kind) {
   case PTHREAD_MUTEX_FAST_NP:
-    __pthread_unlock(&mutex->__m_lock);
     mutex->__m_owner = NULL;
+    __pthread_unlock(&mutex->__m_lock);
     return 0;
   case PTHREAD_MUTEX_RECURSIVE_NP:
     if (mutex->__m_count > 0) {


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Versions of Glibc and GCC Status

[Kevin B. Hendricks]

Hi,

In case you were wondering, that patch has now (just today) been officially
added to the glibc 2.1 branch of the official glibc cvs tree.  The patch in
question prevents a race in setting the onwer to null on a mutex that
resulting in tests in condvar.c to fail about the owner of the mutex not
being the same as the caller of the thread (when it actually was).

With this in place, the JDK native threads now seem to work well.

Please let me know if this sodesn't fix your problems (I am always
interested in the linuxthreads library when tracking down jdk failures).

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Versions of Glibc and GCC Status

[Jeffrey Hawkins]

Kevin,

Thanks for the update...

However, my Thread Problem is not related to the recent fixes
discussed on the LinuxPPC List.  The Thread Problem I am having
is that when a Child Process attempts to create a Thread, the
Thread is created and executes, but the Child Process hangs in
the "pthread_create" (NOTE: Only the Child Process is creating
threads, not the Main Application Parent).  I don't really like
how this Application Package functions, but I don't have much
choice, since it is a 3rd Party Application Package that we
are using, that I am porting from AIX to LinuxPPC.  I have
modified this first Application executable to be
a single process with multiple threads - Everything works.
But, there are several other executables that have the
same Child Process with Threads Architecture, which I
just don't have the Project time to change (since the
changes ripple through other Package areas).  Thus,
I am turning to the updates and fixes to GLIB, which are
suppose to correct this issue, as well as, other issues.


Can I infer from your statement about the committal of your
changes to the GLIBC CVS Tree that GNU GLIBC 2.1.91 Version
should be PowerPC compatible ?  I must admit, I have not
kept up to date on the current Processors that the GNU
GCC and GLIBs are said to fully support.  Looking through
some of the archived mailings on this List, there would
seem to be some contention to GCC and GLIB full support,
or GNU Org's willingness to work on support, of PowerPC.



Jeff


"Kevin B. Hendricks" wrote:
>
> Hi,
>
> In case you were wondering, that patch has now (just today) been officially
> added to the glibc 2.1 branch of the official glibc cvs tree.  The patch in
> question prevents a race in setting the onwer to null on a mutex that
> resulting in tests in condvar.c to fail about the owner of the mutex not
> being the same as the caller of the thread (when it actually was).
>
> With this in place, the JDK native threads now seem to work well.
>
> Please let me know if this sodesn't fix your problems (I am always
> interested in the linuxthreads library when tracking down jdk failures).
>
> Thanks,
>
> Kevin

--
********************************************************

Jeffrey Hawkins

Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering

Address: DEPT:  DQ525
         MS:    IL-02-1055A
         1301 East Algonquin Road
         Schaumburg, IL 60196

Phone:   (847)576-7463
FAX:     (847)576-7737

********************************************************

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: PPC Versions of Glibc and GCC Status

[Jeffrey Hawkins]

Kevin,

Your suggestions paid off.  I found in my Application that the
LIBC "fork" functions were being called instead of the "fork"
Wrapper Functions that are provided by LinuxThreads.  This
was due to the fact that in my LINK Specification I had the
LIBC (-lc) prior to LinuxThreads (-lpthread) in the Library
Search Order.  I modified the LINK Specification for LinuxThreads
to be the first Library, and now things are working !!!!!

Thanks a lot --- You saved me much time and grief !!!!!

I still plan on working on the migration of the latest
LinuxThreads and GLIB to PPC.  This is due to the bugs, and
corresponding fixes, that I have seen identified on the GNU
and LinuxPPC Development Lists.  I am going to run into the
bugs eventually, so I might as well address them now...

Once again, THANKS !!!!!

Jeff




Jeffrey Hawkins wrote:
>
> Kevin,
>
> FYI... Below is a response from one of the GNU Developers who has
> fixed a number of "fork" and "lock" issues in GLIB 2.1.3.  Although,
> the response was a little off in some areas as it pertains to my
> particular Threads Issue, the information is stil relevant, and I
> thought it might be of some interest to yourself, Franz, and others.
> The Developer is Kaz Kylheku, kaz@ashi.footprints.net.
>
> As far as my next steps, I will investigate your suggestions,
> as well as, attempt to migrate the latest GLIB LinuxThreads
> into LinuxPPC GLIB-2.1.3-15d+ (along with your latest fixes).
> After that, if things still are not working well, then I will
> continue with my adaption of the latest 2.1.x - 2.2.x GLIBs
> to PowerPC (rather than waste my time making major changes
> to this 3rd Party Package that is eventually going to be
> eliminated).  So, maybe I can help you guys out with speeding
> up your adaption of GLIB to PPC - my need for this is ASAP...
> I have the latest BINUTILS, MAKE, and the latest GCC from
> Franz's FTP.
>
> Thanks for the help...
>
> RESPONSE:
> On Wed, 09 Aug 2000 13:32:26 -0500, Jeffrey Hawkins
> <Jeffrey.F.Hawkins@motorola.com> wrote:
> >Has anybody ran into a problem with trying to create
> >a Thread from a Child Process ?  I am currently adapting
> >a Software Package, that does this, from AIX to LinuxPPC.
> >I am encountering a problem where the Thread is created,
> >but the Pthread_Create Call never returns to the invoking
> >Child Process.
>
> Not long ago I did a code inspection to specifically look for fork()
> related
> problems in LinuxThreads and ended up fixing a bunch of bugs.  These
> bugfixes
> are not available in any glibc release (other than the 2.1.91 and 2.1.92
> beta
> test releases) but they probably fix the problem you are having.  The
> fixes
> address the global locks in libio, the pthread_atfork global lock itself
> and
> the lock used by pthread_once.  (Now, if a fork() occurs while a
> pthread_once
> callback is in progress, then in the child, the behavior will be as if
> that
> initialization never took place).
>
> The main problem in 2.1.3 and older is that some global locks are not
> taken
> care of correctly at fork() time so the child process can inherit
> certain locks
> in a bad state.  It is possible that your child process is deadlocking
> on one
> of these locks.  Or possibly, there is something wrong with the child's
> new
> thread manager.
>
> Note that according to POSIX, the child of a multithreaded process can
> only
> execute async-safe library functions, so strictly speaking, what you are
> doing
> is not well-defined. However, it is *intended* to work and so it is a
> bug
> if it does not.
>
> >I am currently running a 2.1.3 version of the GLIBC,
> >which has some other Threads Fixes, but nothing related
> >to my problem...
>
> Sadly, fork() and threads simply do not mix very well in glibc 2.1.3 and
> older.
> See if your problem goes away if you use the latest pre-2.2 test
> release. If
> not, then you should submit a bug report.
>



"Kevin B. Hendricks" wrote:
>
> Hi,
>
> >However, my Thread Problem is not related to the recent fixes
> >discussed on the LinuxPPC List.  The Thread Problem I am having
> >is that when a Child Process attempts to create a Thread, the
> >Thread is created and executes, but the Child Process hangs in
> >the "pthread_create" (NOTE: Only the Child Process is creating
> >threads, not the Main Application Parent).  I don't really like
> >how this Application Package functions, but I don't have much
> >choice, since it is a 3rd Party Application Package that we
> >are using, that I am porting from AIX to LinuxPPC.  I have
> >modified this first Application executable to be
> >a single process with multiple threads - Everything works.
> >But, there are several other executables that have the
> >same Child Process with Threads Architecture, which I
> >just don't have the Project time to change (since the
> >changes ripple through other Package areas).  Thus,
> >I am turning to the updates and fixes to GLIB, which are
> >suppose to correct this issue, as well as, other issues.
>
> I saw that fork was wrappered in the glibc linuxthreads library.  Have you
> looked at the wrappering to see what it does?  Also, you might want to put
> a breakpoint there to check if the wrappered fork is being invoked at all
> if the first thread related thing being done is that a child is making all
> the threads.  Perhaps, it is calling the fork in glibc and not the fork
> inside linuxthreads.  The first call to a linuxthreads routine should
> initialize things in the pthread library.  As a hack you might want to try
> creating and destroying a mutex or a thread in the parent process before
> the fork to make sure the wrappered fork is actually being done properly.
>
> >Can I infer from your statement about the committal of your
> >changes to the GLIBC CVS Tree that GNU GLIBC 2.1.91 Version
> >should be PowerPC compatible ?
>
> It will be eventually but right now I can not get glibc 2.1.92 to pass make
> check (also had to upgrade to make 3.79.1 just to get it to build.  I don't
> think it is ready for prime time on ppc yet, but Franz, and Jack, and I
> will probably be looking at it soon.  Franz did mention that you need the
> very latest binutils (H.J.Lu's versions) and Franz's latest gcc to even get
> it to compile properly.
>
> Take care,
>
> Kevin

--
********************************************************

Jeffrey Hawkins

Senior Staff Software Engineer
Motorola Wireless Data Solutions Engineering

Address: DEPT:  DQ525
         MS:    IL-02-1055A
         1301 East Algonquin Road
         Schaumburg, IL 60196

Phone:   (847)576-7463
FAX:     (847)576-7737

********************************************************

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/