Re: GDB problem with statically linked application

Re: GDB problem with statically linked application

[David Highley]

"Ajay Patel wrote:"
> 
>  
> > We still see multiple pid's for static linked applications and not for
> > dynamically linked applications. We are now in the process of rebuilding
> > and running tests on our applications.
> 
> I also saw this. I did not investigated much.
> I think this may be glibc bug. This shows up
> when you use linux-threads.  If you use NPTL
> it does go away.

The insidious part of this is our small test code will execute even if
you use the incorrect "-lpthread" flag with dynamic linking. So the
remaining question to be figured out is whether the thread model is the
same between the static and dynamic links. Do we get NPTL threads in
both cases? We might be able to tell with the nm command.

> 
> Thanks
> Ajay
> 
> 
> 


-- 


Regards,

David Highley		      Phone: (206) 669-0081
Highley Recommended, Inc.	FAX: (253) 838-8509
2927 SW 339th Street	      Email: dhighley@highley-recommended.com
Federal Way, WA 98023-7732	WEB: http://www.highley-recommended.com

Re: GDB problem with statically linked application

[Daniel Jacobowitz]

On Tue, Sep 20, 2005 at 12:52:49PM -0700, David Highley wrote:
> "Ajay Patel wrote:"
> > 
> >  
> > > We still see multiple pid's for static linked applications and not for
> > > dynamically linked applications. We are now in the process of rebuilding
> > > and running tests on our applications.
> > 
> > I also saw this. I did not investigated much.
> > I think this may be glibc bug. This shows up
> > when you use linux-threads.  If you use NPTL
> > it does go away.
> 
> The insidious part of this is our small test code will execute even if
> you use the incorrect "-lpthread" flag with dynamic linking. So the
> remaining question to be figured out is whether the thread model is the
> same between the static and dynamic links. Do we get NPTL threads in
> both cases? We might be able to tell with the nm command.

For the second or third time: this is not the appropriate list to
discuss this particular problem.  It is completely dependent upon your
distributor, not the GNU toolchain.

In general, most distributions which ship both ship LinuxThreads
(because it is more portable) as the static default.  They also publish
in their documentation instructions on how to statically link with
NPTL.  The distributor's documentation is your best reference.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: GDB problem with statically linked application

[Daniel Jacobowitz]

On Tue, Sep 20, 2005 at 12:08:03PM -0700, David Highley wrote:
> I see that you have fallen into the same compiler trap we have just
> discovered. It appears to never be correct to use the flag "-lpthread"
> when using the compiler. You should always use "-pthread". This flag is
> used in the preprocessor to turn on different code generation and the
> reentrancy options. But....

Sorry, but welcome to the modern world.  On most platforms -pthread
does nothing useful except -lpthread.  It also defines -D_REENTRANT,
and on GNU/Linux this flag does nothing at all.

On some other operating systems (Solaris maybe?) it does more.  In that
case using -pthread is correct, or defining the relevant options (found
in the system documentation) yourself.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: GDB problem with statically linked application

[David Highley]

"Ajay Patel wrote:"
> 
> Hi Daniel,
> 
> Here is the summary/Problem report.
> 
> I compile gdb with gdb-6.3-orig + patches from gdb_6.3-6.diff for
> both powerpc and i686.
> 
> Using this gdb on respective arch, I ran different tests
> on a simple test program. (Program attached).
> I normally comile this program through 
> "gcc -g -static -o pthread_test pthread_test.c -lpthread"
> or through cross compilation.

I see that you have fallen into the same compiler trap we have just
discovered. It appears to never be correct to use the flag "-lpthread"
when using the compiler. You should always use "-pthread". This flag is
used in the preprocessor to turn on different code generation and the
reentrancy options. But....

What about the case where you do a two step build?
g++ -c -pthread thread.cpp
g++ -o thread ???? thread.o

Above we use the compiler to help with setting up the startup code for
the linker. We, I just, finished a test where I did a one step build and
then did both options for the two step build of using "-pthread" or
"-lpthread". I ran a cmp on the executables and found that the
executables are created differently if you use the "-lpthread" for
linking. You can run with -v and --save-temps and compare the results
without finding a difference.

I will be submitting a bug report to the gcc project to trap this option
as invalid as I can not see a case from testing where it would ever be
valid to use "-lpthread" with the compiler. This is the kind of issue
that can really tank alot of time to discover.

We still see multiple pid's for static linked applications and not for
dynamically linked applications. We are now in the process of rebuilding
and running tests on our applications.

> 
> On All tests, I setup a breakpoint in run_thread1.
> As soon as breakpoint is encountered in non-main thread,
> the program terminates with following message.
> "Program terminated with signal SIGTRAP, Trace/breakpoint trap".
> 
> Test 1 on PowerPC (Apple's EMAC)
>   Kernel Version-2.6.11.2 (from kernel.org), Glibc 2.3.5 (with NPTL).
>   Program terminated with signal SIGTRAP, Trace/breakpoint trap
> 
> Test 2 on PowerPC (Apple's EMAC)
>   Kernel Version-2.6.11.2 (from kernel.org), Glibc 2.3.4 (with NPTL).
>   Program terminated with signal SIGTRAP, Trace/breakpoint trap
> 
> Test 3 on i686 (Dell optiplex)
>   Kernel Version-2.6.13.2 (from kernel.org), glibc 2.3.4 (with NPTL).
>   Program terminated with signal SIGTRAP, Trace/breakpoint trap
> 
> Test 4 on i686 (Dell optiplex)
>   Kernel Version-2.6.13.2 (from kernel.org), glibc 2.3.3 (Linux threads)
>   Program terminated with signal SIGTRAP, Trace/breakpoint trap
> 
> If you need more info please let me know.
> 
> Thanks for your help.
> 
> Thanks
> Ajay
> 
> 
> 
> ------=WEBMAIL_ATT_0.095466501386003
> Content-Type: application/octet-stream;
> 	name="pthread_test.c"
> Content-Transfer-Encoding: base64
> 
> LyogJE9wZW5CU0Q6IHB0aHJlYWRfdGVzdC5jLHYgMS40IDIwMDMvMDcvMzEgMjE6NDg6MDUgZGVy
> YWFkdCBFeHAgJCAqLwovKiBQVUJMSUMgRE9NQUlOIE9jdCAyMDAyIDxtYXJjQHNuYWZ1Lm9yZz4g
> Ki8KCiNpbmNsdWRlIDxzaWduYWwuaD4KI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDx1bmlz
> dGQuaD4KI2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8cHRocmVhZC5oPgojaW5jbHVkZSA8
> c3RkaW8uaD4KI2luY2x1ZGUgPHN5cy9mY250bC5oPgojaW5jbHVkZSA8c3lzL3R5cGVzLmg+CiNp
> bmNsdWRlIDxzeXMvdGltZS5oPgojaW5jbHVkZSA8ZXJybm8uaD4KI2luY2x1ZGUgPHVuaXN0ZC5o
> PgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNsdWRlIDxzeXMvdHlwZXMuaD4KI2luY2x1ZGUgPHN5
> cy9zb2NrZXQuaD4KI2luY2x1ZGUgPHN0cmluZy5oPgoKCnZvaWQgKiBydW5fdGhyZWFkMSAodm9p
> ZCAqYXJnKQp7CiAgICBwcmludGYgKCJTdGFydGluZyBUSFJFQUQxXG4iKTsKICAgIHdoaWxlICgx
> KSB7CglzbGVlcCg0KTsKICAgIAlwcmludGYgKCJUSFJFQUQxIGlzIGdvaW5nIGJhY2sgdG8gc2xl
> ZXBcbiIpOwogICAgfQp9CgoKdm9pZCAqIHJ1bl90aHJlYWQyICh2b2lkICphcmcpCnsKICAgIHBy
> aW50ZiAoIlN0YXJ0aW5nIFRIUkVBRDJcbiIpOwogICAgd2hpbGUgKDEpIHsKCXNsZWVwKDQpOwog
> ICAgCXByaW50ZiAoIlRIUkVBRDIgaXMgZ29pbmcgYmFjayB0byBzbGVlcFxuIik7CiAgICB9Cn0K
> CmludAptYWluIChpbnQgYXJnYywgY2hhciAqKmFyZ3YpCnsKICAgIGludCBpOwogICAgcHRocmVh
> ZF90IHRocmVhZDE7CiAgICBwdGhyZWFkX3QgdGhyZWFkMjsKCiAgICBwdGhyZWFkX2NyZWF0ZSAo
> JnRocmVhZDEsIE5VTEwsIHJ1bl90aHJlYWQxLCBOVUxMKTsKICAgIHB0aHJlYWRfY3JlYXRlICgm
> dGhyZWFkMiwgTlVMTCwgcnVuX3RocmVhZDIsIE5VTEwpOwogICAgc2xlZXAgKDEpOwoKICAgIHdo
> aWxlICgxKSB7CglzbGVlcCg0KTsKICAgIAlwcmludGYgKCJNYWluIHRocmVhZCBpcyBnb2luZyBi
> YWNrIHRvIHNsZWVwXG4iKTsKICAgIH0KfQo=
> 
> ------=WEBMAIL_ATT_0.095466501386003--
> 


-- 


Regards,

David Highley		      Phone: (206) 669-0081
Highley Recommended, Inc.	FAX: (253) 838-8509
2927 SW 339th Street	      Email: dhighley@highley-recommended.com
Federal Way, WA 98023-7732	WEB: http://www.highley-recommended.com

GDB problem with statically linked application

[Ajay Patel]

[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]

Hi Daniel,

Here is the summary/Problem report.

I compile gdb with gdb-6.3-orig + patches from gdb_6.3-6.diff for
both powerpc and i686.

Using this gdb on respective arch, I ran different tests
on a simple test program. (Program attached).
I normally comile this program through 
"gcc -g -static -o pthread_test pthread_test.c -lpthread"
or through cross compilation.

On All tests, I setup a breakpoint in run_thread1.
As soon as breakpoint is encountered in non-main thread,
the program terminates with following message.
"Program terminated with signal SIGTRAP, Trace/breakpoint trap".

Test 1 on PowerPC (Apple's EMAC)
  Kernel Version-2.6.11.2 (from kernel.org), Glibc 2.3.5 (with NPTL).
  Program terminated with signal SIGTRAP, Trace/breakpoint trap

Test 2 on PowerPC (Apple's EMAC)
  Kernel Version-2.6.11.2 (from kernel.org), Glibc 2.3.4 (with NPTL).
  Program terminated with signal SIGTRAP, Trace/breakpoint trap

Test 3 on i686 (Dell optiplex)
  Kernel Version-2.6.13.2 (from kernel.org), glibc 2.3.4 (with NPTL).
  Program terminated with signal SIGTRAP, Trace/breakpoint trap

Test 4 on i686 (Dell optiplex)
  Kernel Version-2.6.13.2 (from kernel.org), glibc 2.3.3 (Linux threads)
  Program terminated with signal SIGTRAP, Trace/breakpoint trap

If you need more info please let me know.

Thanks for your help.

Thanks
Ajay



[-- Attachment #2: pthread_test.c --]
[-- Type: application/octet-stream, Size: 1052 bytes --]

/* $OpenBSD: pthread_test.c,v 1.4 2003/07/31 21:48:05 deraadt Exp $ */
/* PUBLIC DOMAIN Oct 2002 <marc@snafu.org> */

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <pthread.h>
#include <stdio.h>
#include <sys/fcntl.h>
#include <sys/types.h>
#include <sys/time.h>
#include <errno.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>


void * run_thread1 (void *arg)
{
    printf ("Starting THREAD1\n");
    while (1) {
	sleep(4);
    	printf ("THREAD1 is going back to sleep\n");
    }
}


void * run_thread2 (void *arg)
{
    printf ("Starting THREAD2\n");
    while (1) {
	sleep(4);
    	printf ("THREAD2 is going back to sleep\n");
    }
}

int
main (int argc, char **argv)
{
    int i;
    pthread_t thread1;
    pthread_t thread2;

    pthread_create (&thread1, NULL, run_thread1, NULL);
    pthread_create (&thread2, NULL, run_thread2, NULL);
    sleep (1);

    while (1) {
	sleep(4);
    	printf ("Main thread is going back to sleep\n");
    }
}