Disabling lin-thread.c module

Disabling lin-thread.c module

[Mark Kettenis]

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

Re: Disabling lin-thread.c module

[Eli Zaretskii]

> 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:

I suggest option 3, but I also suggest to activate that autoconf test
and the entire feature only if the package is configured with
--enable-thread-db.  I think this is the right approach for an
experimental/dangerous feature which wasn't tested well enough.
From kettenis@wins.uva.nl Tue Apr 11 04:48:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: gdb@sourceware.cygnus.com, msnyder@cygnus.com
Subject: Re: Disabling lin-thread.c module
Date: Tue, 11 Apr 2000 04:48:00 -0000
Message-id: <200004111148.NAA00978@landau.wins.uva.nl>
References: <200004101237.OAA29849@landau.wins.uva.nl> <200004111116.HAA03833@indy.delorie.com>
X-SW-Source: 2000-04/msg00039.html
Content-length: 1043

   Date: Tue, 11 Apr 2000 07:16:40 -0400 (EDT)
   From: Eli Zaretskii <eliz@delorie.com>

   I suggest option 3, but I also suggest to activate that autoconf test
   and the entire feature only if the package is configured with
   --enable-thread-db.  I think this is the right approach for an
   experimental/dangerous feature which wasn't tested well enough.

Well, the alternative to the libthread_db assisted threads debugging
code isn't that much better tested.  In both cases, the
threads-related tests in the testsuite are passed.  I haven't seen any
evidence of people doing more thread-related testing with gdb
snapshots on Linux/i386.

Anyway, the --enable-thread-db option is completely orthogonal to the
autoconf test.  I'd really like to see the libthread_db assisted code
being used, otherwise we'll never learn about problems with it.
Looks like Michael Snyder feels the same way.  But if there are more
people who think disabling the code by default and adding
--enable-thread-db is a good idea, I'll be happy to add it.

Mark
From hjl@lucon.org Tue Apr 11 07:53:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com, msnyder@cygnus.com
Subject: Re: Disabling lin-thread.c module
Date: Tue, 11 Apr 2000 07:53:00 -0000
Message-id: <20000411075259.B4776@lucon.org>
References: <200004101237.OAA29849@landau.wins.uva.nl> <200004111116.HAA03833@indy.delorie.com> <200004111148.NAA00978@landau.wins.uva.nl>
X-SW-Source: 2000-04/msg00040.html
Content-length: 1427

On Tue, Apr 11, 2000 at 01:48:46PM +0200, Mark Kettenis wrote:
>    Date: Tue, 11 Apr 2000 07:16:40 -0400 (EDT)
>    From: Eli Zaretskii <eliz@delorie.com>
> 
>    I suggest option 3, but I also suggest to activate that autoconf test
>    and the entire feature only if the package is configured with
>    --enable-thread-db.  I think this is the right approach for an
>    experimental/dangerous feature which wasn't tested well enough.
> 
> Well, the alternative to the libthread_db assisted threads debugging
> code isn't that much better tested.  In both cases, the
> threads-related tests in the testsuite are passed.  I haven't seen any
> evidence of people doing more thread-related testing with gdb
> snapshots on Linux/i386.
> 
> Anyway, the --enable-thread-db option is completely orthogonal to the
> autoconf test.  I'd really like to see the libthread_db assisted code
> being used, otherwise we'll never learn about problems with it.
> Looks like Michael Snyder feels the same way.  But if there are more
> people who think disabling the code by default and adding
> --enable-thread-db is a good idea, I'll be happy to add it.

People are using gdb for real work. They shouldn't second guess
about gdb. I vote for disable libthread_db by default for 5.0
and turn it on in CVS. People who use the public release won't
get libthread_db by default. But they will test libthread_db if
they use CVS or snapshot.


H.J.
From jlarmour@redhat.co.uk Tue Apr 11 08:10:00 2000
From: Jonathan Larmour <jlarmour@redhat.co.uk>
To: gdb@sourceware.cygnus.com
Subject: gdb weekly snapshots
Date: Tue, 11 Apr 2000 08:10:00 -0000
Message-id: <38F3407B.774A55CE@redhat.co.uk>
X-SW-Source: 2000-04/msg00041.html
Content-length: 731

The "weekly" snapshots haven't happened for a while - March 13th
specifically. If they are done by cron jobs, perhaps they need some
kicking? I know the snapshots that include dejagnu are done more
frequently, but I'd prefer to point people at smaller downloads if they
aren't going to run the testsuite. 

If it's considered better just to drop the non-dejagnu snapshots, can those
instead be made the gdb.tar.bz2/insight.tar.bz2 hard links in whatever the
script is (those names make for easier URLs to point people at), and remove
the old snapshots please?

Thanks,

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault
From scottb@netwinder.org Tue Apr 11 08:19:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Documentation build problem in GDB 5 branch...
Date: Tue, 11 Apr 2000 08:19:00 -0000
Message-id: <38F341AF.B615A276@netwinder.org>
X-SW-Source: 2000-04/msg00042.html
Content-length: 1293

I get the following problem doing a `make info` in the doc directory of my gdb
build tree in the branch.  It seems to work fine in the main line.  I know
nothing about info so I'm punting...

Scott

makeinfo -o gdbint.info ../../../src/gdb/doc/gdbint.texinfo
../../../src/gdb/doc/gdbint.texinfo:1700: Cross reference to nonexistent
node `Using Different Target and Host Data Representations'.
../../../src/gdb/doc/gdbint.texinfo:1696: Cross reference to nonexistent
node `Using Different Target and Host Data Representations'.
../../../src/gdb/doc/gdbint.texinfo:1692: Cross reference to nonexistent
node `Using Different Target and Host Data Representations'.
../../../src/gdb/doc/gdbint.texinfo:1688: Cross reference to nonexistent
node `Using Different Target and Host Data Representations'.
../../../src/gdb/doc/gdbint.texinfo:1684: Cross reference to nonexistent
node `Using Different Target and Host Data Representations'.
../../../src/gdb/doc/gdbint.texinfo:1680: Cross reference to nonexistent
node `Using Different Target and Host Data Representations'.
makeinfo: Removing output file `gdbint.info' due to errors; use --force to
preserve.
make: *** [gdbint.info] Error 2

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From msnyder@cygnus.com Tue Apr 11 10:26:00 2000
From: Michael Snyder <msnyder@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: eliz@is.elta.co.il, gdb@sourceware.cygnus.com
Subject: Re: Disabling lin-thread.c module
Date: Tue, 11 Apr 2000 10:26:00 -0000
Message-id: <38F35FE5.660@cygnus.com>
References: <200004101237.OAA29849@landau.wins.uva.nl> <200004111116.HAA03833@indy.delorie.com> <200004111148.NAA00978@landau.wins.uva.nl>
X-SW-Source: 2000-04/msg00043.html
Content-length: 1269

Mark Kettenis wrote:
> 
>    Date: Tue, 11 Apr 2000 07:16:40 -0400 (EDT)
>    From: Eli Zaretskii <eliz@delorie.com>
> 
>    I suggest option 3, but I also suggest to activate that autoconf test
>    and the entire feature only if the package is configured with
>    --enable-thread-db.  I think this is the right approach for an
>    experimental/dangerous feature which wasn't tested well enough.
> 
> Well, the alternative to the libthread_db assisted threads debugging
> code isn't that much better tested.  In both cases, the
> threads-related tests in the testsuite are passed.  I haven't seen any
> evidence of people doing more thread-related testing with gdb
> snapshots on Linux/i386.
> 
> Anyway, the --enable-thread-db option is completely orthogonal to the
> autoconf test.  I'd really like to see the libthread_db assisted code
> being used, otherwise we'll never learn about problems with it.
> Looks like Michael Snyder feels the same way. 

Moreover, we HAVE to start using it, because the older method
simply isn't going to continue working indefinitely, as LIBC
development moves forward.  The thread-db method was developed
for a reason: it helps to separate GDB from dependancy on 
knowledge of the internal details of implementation in libthread.
From eliz@delorie.com Tue Apr 11 11:55:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Completing for file names
Date: Tue, 11 Apr 2000 11:55:00 -0000
Message-id: <200004111855.OAA04253@indy.delorie.com>
X-SW-Source: 2000-04/msg00044.html
Content-length: 189

I think the following GDB commands should use the file-name completer
function when the user presses a TAB:

  attach
  make
  set history filename
  set remotelogfile
  shell
  
Comments?
From jtc@redback.com Tue Apr 11 12:04:00 2000
From: jtc@redback.com (J.T. Conklin)
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Completing for file names
Date: Tue, 11 Apr 2000 12:04:00 -0000
Message-id: <5mhfd8a28r.fsf@jtc.redback.com>
References: <200004111855.OAA04253@indy.delorie.com>
X-SW-Source: 2000-04/msg00045.html
Content-length: 386

>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
Eli> I think the following GDB commands should use the file-name completer
Eli> function when the user presses a TAB:
Eli>
Eli>   attach
Eli>   make
Eli>   set history filename
Eli>   set remotelogfile
Eli>   shell
  
Eli> Comments?

Doesn't attach take a process id, not a file?

        --jtc

-- 
J.T. Conklin
RedBack Networks
From jimb@zwingli.cygnus.com Tue Apr 11 15:30:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Daniel Berlin <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: Reducing memory usage
Date: Tue, 11 Apr 2000 15:30:00 -0000
Message-id: <npem8cmfsm.fsf@zwingli.cygnus.com>
References: <Pine.LNX.4.10.10004091445001.31585-100000@propylaea.anduin.com>
X-SW-Source: 2000-04/msg00046.html
Content-length: 1633

> For starters, we don't try to not duplicate type info when reading dwarf2.
> I've fixed this.
> Doing this takes gdb, with all of it's symbols read in, from this:
> Statistics for '/usr/local/gdb/src/gdb/gdb':
>   Number of "stab" symbols read: 290212
>   Number of "minimal" symbols read: 10600
>   Number of "partial" symbols read: 160442
>   Number of "full" symbols read: 237611
>   Number of "types" defined: 129044
>   Space used by a.out string tables: 974998
>   Total memory used for psymbol obstack: 8017943
>   Total memory used for psymbol cache: 948776
>   Total memory used for symbol obstack: 24542604
>   Total memory used for type obstack: 19411848
> 
> to this:
> 
> Statistics for '/usr/local/gdb/src/gdb/./gdb':
>   Number of "stab" symbols read: 290212
>   Number of "minimal" symbols read: 10600
>   Number of "partial" symbols read: 160442
>   Number of "full" symbols read: 155649
>   Number of "types" defined: 105366
>   Space used by a.out string tables: 974998
>   Total memory used for psymbol obstack: 8017943
>   Total memory used for psymbol cache: 948776
>   Total memory used for symbol obstack: 18510936
>   Total memory used for type obstack: 12585708
> 
> A savings of about 13 meg (and in percentages, we save 45% of the type
> obstack, 25% of the symbol stack).
> 
> This only helps for dwarf2, stabs and whatnot were already doing something
> similar.
> 
> I used the hashtable implementation libiberty now provides, rather than
> introduce yet another gdb hashtable type.
> 
> Not too shabby, methinks.

Yep --- pretty darn good, actually.  If you send me the patches, I'll
look them over.
From ac131313@cygnus.com Tue Apr 11 17:17:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Scott Bambrough <scottb@netwinder.org>
Cc: GDB Mailing List <gdb@sourceware.cygnus.com>
Subject: Re: Documentation build problem in GDB 5 branch...
Date: Tue, 11 Apr 2000 17:17:00 -0000
Message-id: <38F3BFF6.6C575BE8@cygnus.com>
References: <38F341AF.B615A276@netwinder.org>
X-SW-Source: 2000-04/msg00047.html
Content-length: 1387

Scott Bambrough wrote:
> 
> I get the following problem doing a `make info` in the doc directory of my gdb
> build tree in the branch.  It seems to work fine in the main line.  I know
> nothing about info so I'm punting...
> 
> Scott
> 
> makeinfo -o gdbint.info ../../../src/gdb/doc/gdbint.texinfo
> ../../../src/gdb/doc/gdbint.texinfo:1700: Cross reference to nonexistent
> node `Using Different Target and Host Data Representations'.
> ../../../src/gdb/doc/gdbint.texinfo:1696: Cross reference to nonexistent
> node `Using Different Target and Host Data Representations'.
> ../../../src/gdb/doc/gdbint.texinfo:1692: Cross reference to nonexistent
> node `Using Different Target and Host Data Representations'.
> ../../../src/gdb/doc/gdbint.texinfo:1688: Cross reference to nonexistent
> node `Using Different Target and Host Data Representations'.
> ../../../src/gdb/doc/gdbint.texinfo:1684: Cross reference to nonexistent
> node `Using Different Target and Host Data Representations'.
> ../../../src/gdb/doc/gdbint.texinfo:1680: Cross reference to nonexistent
> node `Using Different Target and Host Data Representations'.
> makeinfo: Removing output file `gdbint.info' due to errors; use --force to
> preserve.
> make: *** [gdbint.info] Error 2

I know (its hard to miss it - it stops the snapshots).  JimB cooked up a
patch in devo and I'm now importing it to the branch.

	Andrew
From ac131313@cygnus.com Tue Apr 11 23:02:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.co.uk>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb weekly snapshots
Date: Tue, 11 Apr 2000 23:02:00 -0000
Message-id: <38F410D4.63F2C883@cygnus.com>
References: <38F3407B.774A55CE@redhat.co.uk>
X-SW-Source: 2000-04/msg00048.html
Content-length: 1436

Jonathan Larmour wrote:
> 
> The "weekly" snapshots haven't happened for a while - March 13th
> specifically. If they are done by cron jobs, perhaps they need some
> kicking? I know the snapshots that include dejagnu are done more
> frequently, but I'd prefer to point people at smaller downloads if they
> aren't going to run the testsuite.

FYI,  the last few days snapshots have been barfing (build problem) but
beyond that they appear to be working ok.  I'm currently pushing through
a snapshot by hand.

I suspect you've been fooled by the old dejagnu and gdb-only snapshots
that are still lying around, time to delete.

> If it's considered better just to drop the non-dejagnu snapshots, can those
> instead be made the gdb.tar.bz2/insight.tar.bz2 hard links in whatever the
> script is (those names make for easier URLs to point people at), and remove
> the old snapshots please?

At present gdb+dejagnu.tar.bz2 and insight+dejagnu.tar.bz2 snapshots are
being created.  The names best reflect what is really in the archive.

Also of interest is the weekly *-CVS-* file.  It contains a full CVS
checkout (although right now it is a checkout of the GDB-5.0 branch).

With respect to pointing gdb.tar.bz2 -> gdb+dejagnu.tar.bz2.  The mirror
sites probably won't like it.  Like a separate gdb.tar.bz2 archive
(which is what I was doing) it would just increase the amount of mirror
data being shipped out each night.

enjoy,

	Andrew
From eliz@delorie.com Wed Apr 12 01:25:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Completing for file names
Date: Wed, 12 Apr 2000 01:25:00 -0000
Message-id: <200004120825.EAA05112@indy.delorie.com>
References: <200004111855.OAA04253@indy.delorie.com> <5mhfd8a28r.fsf@jtc.redback.com>
X-SW-Source: 2000-04/msg00049.html
Content-length: 96

> Doesn't attach take a process id, not a file?

According to the docs, it can take either one.
From eliz@delorie.com Wed Apr 12 01:27:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Completing for file names
Date: Wed, 12 Apr 2000 01:27:00 -0000
Message-id: <200004120827.EAA05121@indy.delorie.com>
References: <200004111855.OAA04253@indy.delorie.com>
X-SW-Source: 2000-04/msg00050.html
Content-length: 229

> I think the following GDB commands should use the file-name completer
> function when the user presses a TAB:
> 
>   attach
>   make
>   set history filename
>   set remotelogfile
>   shell

Sorry, I forgot another one: "run".
From rearnsha@arm.com Wed Apr 12 04:00:00 2000
From: Richard Earnshaw <rearnsha@arm.com>
To: gdb@sourceware.cygnus.com
Cc: rearnsha@arm.com
Subject: Finding runtest
Date: Wed, 12 Apr 2000 04:00:00 -0000
Message-id: <200004121100.MAA17801@cam-mail2.cambridge.arm.com>
X-SW-Source: 2000-04/msg00051.html
Content-length: 789

gdb comes with dejagnu as part of the distribution (to ensure we use one 
with the correct features).  Most of the time, the make system will pick 
this up automatically and use it in preference to any version that is 
installed on the path.  Unfortunately, this is not the case when checking 
dejagnu itself.  In this case, it will only work using a version that has 
already been installed.

The effect of this is that "make check" will fail when trying to check 
dejagnu if dejagnu has not been previously installed on the path.

I'm not entirely convinced that it is correct for a test program to be 
testing itself, but the current behaviour is a bit inconsistent.

Sorry no patch at the moment (I only came across this at home last night) 
and haven't had chance to fix it yet.

R.