From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com
Cc: msnyder@cygnus.com
Subject: Disabling lin-thread.c module
Date: Mon, 10 Apr 2000 05:37:00 -0000 [thread overview]
Message-ID: <200004101237.OAA29849@landau.wins.uva.nl> (raw)
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
next reply other threads:[~2000-04-10 5:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-04-10 5:37 Mark Kettenis [this message]
2000-04-11 4:16 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200004101237.OAA29849@landau.wins.uva.nl \
--to=kettenis@wins.uva.nl \
--cc=gdb@sourceware.cygnus.com \
--cc=msnyder@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox