This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB problem with statically linked application


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]