Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Disabling lin-thread.c module
@ 2000-04-10  5:37 Mark Kettenis
  2000-04-11  4:16 ` Eli Zaretskii
  0 siblings, 1 reply; 2+ messages in thread
From: Mark Kettenis @ 2000-04-10  5:37 UTC (permalink / raw)
  To: gdb; +Cc: msnyder

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: <OFED5E6862.05164227-ON802568BD.005330B7@risccores.com>
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


^ permalink raw reply	[flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-04-11  4:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-04-10  5:37 Disabling lin-thread.c module Mark Kettenis
2000-04-11  4:16 ` Eli Zaretskii

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox