Re: PPC Versions of Glibc and GCC Status

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
[off-list ref] wrote:

quoted

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.

quoted

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,

quoted

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.

quoted

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/