From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: gdb@sourceware.cygnus.com Cc: msnyder@cygnus.com Subject: Disabling lin-thread.c module Date: Mon, 10 Apr 2000 05:37:00 -0000 Message-id: <200004101237.OAA29849@landau.wins.uva.nl> X-SW-Source: 2000-04/msg00030.html Since glibc-2.1.3 was released with a bogus definition for prfpregset_t (at least for Linux/i386[1]), we'll have to take some measures to make sure that GDB-5.0 will work with glibc-2.1.3. I see three possibilities: 1. Disable the lin-thread.c module by default, and provide a switch --enable-thread-db to enable the module, such that people can build the module if the headers have been fixed (for example when glibc-2.1.4 has been installed). 2. Provide the same switch, but use an autoconf test to check whether the prfpregset_t type is broken, and enable the module based on the result of that test. 3. Use an autoconf test to check whether the prfpregset_t type is broken, and let GDB work around it. I'm inclined to implement option 3, since that means that the lin-thread.c code will be somewhat more thoroughly tested, but there may be some drawbacks: * A libthread_db built with the bogus prfpregset_t definition has a minor problem: If the floating-point registers could not be fetched, the structure isn't completely zeroed out. * I need to add some uglification of GDB's code to make this work. * Since nobody did a lot of testing of GDB with multithreaded programs, it's largely unknown whether there are cases that lin-thread.c can handle and linux-thread.c cannot handle, and the other way around. I know that lin-thread.c cannot handle exiting threads, but linux-thread.c seems to mishandle those too. Both modules pass the regression tests once the prfpregset_t problem is fixed. Mark [1] I'm not sure about the status of Linux/alpha. >From Mark_Farr/ARC@arccores.com Mon Apr 10 08:57:00 2000 From: Mark_Farr/ARC@arccores.com To: gdb@sourceware.cygnus.com Cc: Stephane.Bihan@arccores.com Subject: Makefile setting Date: Mon, 10 Apr 2000 08:57:00 -0000 Message-id: X-SW-Source: 2000-04/msg00031.html Content-length: 628 Dear All, We are trying to use functions defined in a file stored in the gdb directory for our simulator ( /sim/arc/ ). These functions are also used by the remote target. We have undefined symbols when building libsim.a. For example, gdb_register_names[ ] is used by the simulator. When defined as extern the symbol is still undefined. A work-around is to insert a special toggle (#ifdef) in remote-sim.c in function gdbsim_open( ), instead of sim_open( ) in our simulator. This isn't particularly elegant - but is this acceptable if we want to release the sources. Do you have any ideas of a nicer solution? Thanks, Mark