Re: Shared libraries on Linux

Re: Shared libraries on Linux

[H . J . Lu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 37928 bytes --]

On Tue, Feb 08, 2000 at 05:01:49PM -0500, Jim Kingdon wrote:
> OK, I'm going to try to review the situation:
> 
> I'm using http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130 as
> the key bug/limitation that *I* want to fix but of course one of the
> things which is making this confusing is that people keep switching
> topics between various bugs (current and past).
> 

This is a new patch. Please ignore the previous ones.



H.J.
----
Tue Feb  8 18:19:22 2000  H.J. Lu  <hjl@gnu.org>

	Based on patches from Sam Lantinga (slouken@devolution.com):

	* solib.c (verify_solib): New function. Reload list of shared
	objects when they are added or deleted and dump symbols from
	unloaded shared objects.
	(solib_add): Call it.

Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.3
diff -u -p -r1.1.1.3 solib.c
--- solib.c	1999/11/19 23:38:54	1.1.1.3
+++ solib.c	2000/02/09 02:18:55
@@ -194,6 +198,8 @@ static int solib_map_sections PARAMS ((P
 
 #ifdef SVR4_SHARED_LIBS
 
+static void verify_solib PARAMS ((void));
+
 static CORE_ADDR
   elf_locate_base PARAMS ((void));
 
@@ -951,6 +957,69 @@ open_symbol_file_object (arg)
 }
 #endif /* SVR4_SHARED_LIBS */
 
+#ifdef SVR4_SHARED_LIBS
+/*
+  
+LOCAL FUNCTION
+
+	verify_solib -- check solib list consistency and dump symbols
+			from unloaded shared objects
+
+SYNOPSIS
+
+	void verify_solib (void)
+
+DESCRIPTION
+
+	This module is called whenever we hit a dynamic linker
+	breakpoint and allows us to check the consistency of our shared 
+	object list and unload objects which are no longer valid in the
+	in the inferior. Without this, dynamic unlinking of objects
+	could crash us.
+
+AUTHOR
+	Sam Lantinga <hercules@lokigames.com>
+ */
+
+static void
+verify_solib (void)
+{
+  struct objfile *current;
+
+  if (debug_base)
+    {
+      read_memory (debug_base, (char *) &debug_copy,
+		   sizeof (struct r_debug));
+      /* If the shared object state is consistent, we can reload our
+	 list */
+      if ( debug_copy.r_state == RT_CONSISTENT )
+	clear_solib();
+   }
+
+  for (current = symfile_objfile; current; current = current->next)
+    {
+      struct so_list *so;
+      char *bfd_filename;
+      for (so = so_list_head; so; so = so->next)
+	{
+	  if (so->abfd)
+	    {
+	      bfd_filename = bfd_get_filename (so->abfd);
+	      if (bfd_filename 
+	          && strcmp(bfd_filename, current->name) == 0)
+		break;
+            }
+        }
+      if ((current != symfile_objfile) && (so == NULL))
+	{
+	  /*printf("Freeing objfile: %s\n", current->name);*/
+	  free_objfile(current);
+	  break;
+	}
+    }
+}
+#endif	/* SVR4_SHARED_LIBS */
+
 /*
 
    LOCAL FUNCTION
@@ -1165,6 +1234,8 @@ solib_add (arg_string, from_tty, target)
   int old;
 
 #ifdef SVR4_SHARED_LIBS
+  verify_solib ();
+
   /* If we are attaching to a running process for which we 
      have not opened a symbol file, we may be able to get its 
      symbols now!  */
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: Dependence on config.status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bem9u49sh.fsf@rtl.cygnus.com>
References: <200002280657.BAA27090@indy.delorie.com> <38BCCA84.74A4143E@cygnus.com>
X-SW-Source: 2000-q1/msg00481.html
Content-length: 816

> > Why does GDB need to be dependent on config.status, in addition to
> > config.h?
> 
> I don't know and yes I agree with you.  I think it is just history.

Well, if memory serves, if you re-ran configure in such a way that
tm.h started linking to a different file, then the config.status
dependency was the only way to force a rebuild.  I think that is still
true (at least, I glanced through the Makefile.in and configure.in and
that's what it looked like).

Having said that, there is sometimes a tradeoff between having
dependencies correct and having them useful.  Making people type "make
clean" in certain obscure situations may not be all that bad (although
it tends to be pretty confusing as you usually don't realize what is
going on until GDB is acting in strange and inexplicable ways).
From tgl@sss.pgh.pa.us Sat Apr 01 00:00:00 2000
From: Tom Lane <tgl@sss.pgh.pa.us>
To: law@cygnus.com
Cc: Daniel Berlin <dan@cgsoftware.com>, gdb-testers@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release 
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <27939.949983325@sss.pgh.pa.us>
References: <4046.949979695@upchuck>
X-SW-Source: 2000-q1/msg00157.html
Content-length: 4251

Jeffrey A Law <law@cygnus.com> writes:
>> I don't know what architecture H.J. is using, but I can tell you that
>> shared lib debugging is completely nonfunctional on HPPA (HPUX 10.20).
>> Can't even get a backtrace when execution is stopped in a shlib...

> Testcases please?  If it's busted, it's news to me.  This stuff was rock
> solid when I stopped working on the PA port regularly a few years ago.

OK, the case that's really biting my rear at the moment is that I can't
get a backtrace from a corefile that has committed harakiri via abort().
I'm using gcc-2.95.2 and binutils-2.9.1:

$ cat die.c
#include <stdlib.h>

int main(int argc, char* argv)
{
  abort();
  return 0;
}

$ gcc -v -g -O2 die.c
Reading specs from /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Dhppa -Dhp9000s800 -D__hp9000s800 -Dhp9k8 -DPWB -Dhpux -Dunix -D__hppa__ -D__hp9000s800__ -D__hp9000s800 -D__hp9k8__ -D__PWB__ -D__hpux__ -D__unix__ -D__hppa -D__hp9000s800 -D__hp9k8 -D__PWB -D__hpux -D__unix -Asystem(unix) -Asystem(hpux) -Acpu(hppa) -Amachine(hppa) -D__OPTIMIZE__ -g -D__hp9000s700 -D_PA_RISC1_1 -D_HPUX_SOURCE -D_HIUX_SOURCE -D__STDC_EXT__ die.c /var/tmp/ccOM2dGl.i
GNU CPP version 2.95.2 19991024 (release) (hppa)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/../../../../hppa2.0-hp-hpux10.20/include
 /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/../../../../include/g++-3
End of omitted list.
 /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/cc1 /var/tmp/ccOM2dGl.i -quiet -dumpbase die.c -g -O2 -version -o /var/tmp/ccWcvHuE.s
GNU C version 2.95.2 19991024 (release) (hppa2.0-hp-hpux10.20) compiled by GNU C version 2.95.2 19991024 (release).
 /usr/local/hppa2.0-hp-hpux10.20/bin/as -o /var/tmp/ccC0G25b.o /var/tmp/ccWcvHuE.s /usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2/collect2 -L/lib/pa1.1 -L/usr/lib/pa1.1 -z -u main /usr/ccs/lib/crt0.o -L/usr/local/lib/gcc-lib/hppa2.0-hp-hpux10.20/2.95.2 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/local/lib /var/tmp/ccC0G25b.o -lgcc -lc -lgcc

$ ./a.out
Abort(coredump)

$ gdb a.out core
GNU gdb 20000117
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa2.0-hp-hpux10.20"...
Core was generated by `a.out'.
Program terminated with signal 6, Aborted.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

Reading symbols from a.out...done.
Reading symbols from /usr/lib/libc.1...done.
Reading symbols from /usr/lib/libdld.1...done.
#0  0xc0141120 in ?? () from /usr/lib/libc.1
(gdb) bt
#0  0xc0141120 in ?? () from /usr/lib/libc.1
#1  0xc00aa744 in ?? () from /usr/lib/libc.1
#2  0xc008c258 in ?? () from /usr/lib/libc.1
#3  0xc0086c84 in ?? () from /usr/lib/libc.1
Cannot access memory at address 0x0
(gdb)


If I compile without either -O2 or -O, I get

(gdb) bt
#0  0xc0141120 in ?? () from /usr/lib/libc.1
#1  0xc00aa744 in ?? () from /usr/lib/libc.1
#2  0xc008c258 in ?? () from /usr/lib/libc.1
#3  0xc0086c84 in ?? () from /usr/lib/libc.1
#4  0x2270 in main (argc=1, argv=0x7b03a5a0 "{\003 ") at die.c:5
#5  0xc00656bc in ?? () from /usr/lib/libc.1
(gdb) f 4
#4  0x2270 in main (argc=1, argv=0x7b03a5a0 "{\003 ") at die.c:5
5         abort();
(gdb)

which is still not very helpful as far as the shlib goes, but at least
I can find out where the heck the abort is.  In any case, I thought
gdb claimed to be able to debug optimized code.

I'm running a fairly recent patchlevel of libc, HP's ld, dld, etc.
If you need an exact patch set list, or any other info, let me know.

			regards, tom lane
From scottb@netwinder.org Sat Apr 01 00:00:00 2000
From: Scott Bambrough <scottb@netwinder.org>
To: karuottu@freenet.hut.fi
Cc: "Lim, Sung-taek" <totohero@poppy.snu.ac.kr>, crossgcc mailinglist <crossgcc@sourceware.cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: Breakpoint problem when running on gdb-4.18 arm/thumb simulator target
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <387DE3A6.A2BCAB58@netwinder.org>
References: <001401bf5db1$10157720$8f742e93@snu.ac.kr> <387DB7E5.E479256B@freenet.hut.fi>
X-SW-Source: 2000-q1/msg00028.html
Content-length: 1732

Kai Ruottu wrote:
> 
> "Lim, Sung-taek" wrote:
> >
>  Generally for the ARM-target it would be better to try the GDB snapshots. I don't
> remember this phenomen from my gdb-4.18.x's, but perhaps I had updated some ARM-stuff
> from the snapshots before building my first GDB for arm-elf...

This is true.  After the merge of the ARM Linux code, the number of testsuite
failures has fallen according to the last reports I got from Stan.

>  Some targets had their 'opcodes' changed for the simulated 'breakpoint' instruction,
> perhaps ARM was one of these. Anyway the synchronization between the binutils, GCC and
> GDB hasn't been the best, and one must try more than one release before getting the
> toolset to work. For arm-elf the '991130' and newer binutils seem to be broken. The
> linked executables will not load into older or current GDBs (like Insight).

ARM CPU's currently have no hardware support for breakpoints that I know of. 
GDB uses two approaches for breakpoints on ARM systems.  On systems such as ARM
Linux the OS has support for breakpoints in the kernel via a software
interrupt.  The instruction where the breakpoint occurs is replaced by a
software interrupt call into the kernel.  In embedded systems, with no such
kernel support, an undefined  instruction is used and GDB provides a handler for
the undefined instruction trap.  See the comments in tm-arm.h in the latest
snapshot for more detail.

> > the  patch can be found at:
> > http://poppy.snu.ac.kr/~totohero/arm-linux/gdb-4.18-dal-patch

The current snapshot should build and work fine for most things from what I
understand.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: New file gdb/CONTRIBUTE guidelins for the contributor
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <bg0v08f69.fsf@rtl.cygnus.com>
References: <38A3780F.2FE7A510@cygnus.com>
X-SW-Source: 2000-q1/msg00215.html
Content-length: 1051

> In terms of content, this really is a direct lift of GCC's
> how-to-contribute page.

There is already such a lift at
http://sourceware.cygnus.com/gdb/submit.html

Although it does express things which need to be said (for the most
part), I wanted to write something else which does more to encourage
people (the submit.html page has way too many "don'ts" and not enough
"dos"), so I wrote http://sourceware.cygnus.com/gdb/contribute.html

(None of this is all that new, I've been checking in to GDB web pages
since well before the Red Hat-Cygnus merger).

The web pages are in CVS, people should be able to get them with some
variation of

  cvs -d :ext:kingdon@sourceware.cygnus.com:/cvs/gdb co htdocs

That is, how you get GDB but with the appropriate changes to the
root/module names.

So having said all that, do you still want submit.html or equivalent
in the distribution?  Having it both places seems like kind of a
maintenance pain and seems to me that having the distribution point to
the web site probably works.
From toddpw@windriver.com Sat Apr 01 00:00:00 2000
From: Todd Whitesel <toddpw@windriver.com>
To: gdb@sourceware.cygnus.com (GDB Developers)
Subject: win32 native-process GDB target?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003152347.PAA13106@alabama.wrs.com>
X-SW-Source: 2000-q1/msg00714.html
Content-length: 574

I have a local request here for a GDB that can debug a win32 native process.
More specifically, ELF objects dynamically loaded into a straight MSVC app.
(It is better for me NDA-wise if I don't give any details beyond that.)

Am I correct in assuming that the cygwin GDB requires its debuggee to also
be cygwin? If so, then does anyone know the status of win32 native process
target stuff? Unless it's recent, I'm pretty sure I haven't seen anything
claiming to be such in the sources yet, so I'm afraid our guy may be out
of luck.

-- 
Todd Whitesel
toddpw @ windriver.com
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: ac131313@cygnus.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: [MAINT/RFC] Start devolving maintenance responsibility
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003051810.NAA09213@devserv.devel.redhat.com>
References: <38BC81A0.17D25C8@cygnus.com> <bbt4y3s8k.fsf@rtl.cygnus.com> <38BE146B.46ED6E4D@cygnus.com> <200003021446.JAA31093@devserv.devel.redhat.com> <38C22262.FFA0191@cygnus.com>
X-SW-Source: 2000-q1/msg00548.html
Content-length: 36

> Try this:

That looks fine to me.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: hjl@lucon.org, kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <389F7168.67D263F1@cygnus.com>
References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> <bog9tj5y3.fsf@rtl.cygnus.com> <20000207093417.A10546@lucon.org> <200002072148.WAA08590@soliton.wins.uva.nl>
X-SW-Source: 2000-q1/msg00147.html
Content-length: 1301

Mark Kettenis wrote:
> 
>    Date: Mon, 7 Feb 2000 09:34:17 -0800
>    From: "H . J . Lu" <hjl@lucon.org>
> 
>    gdb 4.17.0.14 has one patch from Sam to deal with shared libraries.
>    People who want to debug shared libraries may not want to use gdb
>    in CVS. As you have mentioned above, it is not that unusual nowdays.
>    We have patches and they seem to work. We can make gdb 5.0 to work
>    with shared libraries. If we continue ignoring the working patches
>    without providing an alternative, we are sending the wrong signals
>    to those contributors.
> 
> Yes we should try to act on bug-reports and look at the fixes we get
> from people.  However, we should keep an eye on the long-term
> maintainability of GDB.  Adding new hooks like Sam's patch does, is
> not improving maitainability and contrary to the current direction
> that GDB development is heading for: supporting multiple architectures
> in one GDB binary.  The patch is very useful though for establishing
> what exactly is wrong, and how to fix this properly, which is what I
> intend to do.  It is possible that this doesn't happen before GDB 5.0
> however.

This sounds like a situtation where the best thing to do is contribute
the test case (assuming that such a test isn't already present).

	enjoy,
		Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: shebs@apple.com, gdb@sourceware.cygnus.com
Subject: Re: Status
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38ACF5C3.E1A85C05@cygnus.com>
References: <38A34041.B443DAFB@apple.com> <bitzw8fvy.fsf@rtl.cygnus.com> <38A46C5C.F8301644@apple.com> <200002112037.PAA02309@devserv.devel.redhat.com>
X-SW-Source: 2000-q1/msg00335.html
Content-length: 4048

Jim Kingdon wrote:

> But I guess the GCC system makes sense to me.  If something is enough
> of an issue to be a "technical controversy" in the sense of something
> people would escalate to the chief technical maintainer/team, you kind
> of want to get people on board as much as possible.  Because if you
> proceed without _some_ level of consensus (not among the whole world,
> but at least among a small group of people most involved), then it
> creates various kinds of pain.

I think the GCC system grew out of somewhat unusual (and very political)
circumstances.

In the case of GDB I think it is fair to say that the problem has been
far simpler: Cygnus (a Red Hat company) (1) didn't keep up with the
changing world and was slow (2) in moving the GDB repository to a public
locale.  That in turn both frustrated non Cygnus developers and created
the persecption (real or otherwize) that Cygnus was hogging GDB.


> I mean, there is almost always a way out (e.g. make it an option or
> something, if there really a demand for both solutions).
> 
> One thing I don't want to be single-string is the process of making
> checkins which are believed to be relatively uncontroversial.  Right
> now there is a big problem when the person listed in MAINTAINERS for a
> particular file gets busy or is on vacation or whatever.  Or to put it
> another way, being a maintainer should grant you the right to overrule
> other people but it shouldn't grant you the right to stop things in
> their tracks.  Or something like that.

In this regard, you'll notice that I've followed through the suggestion
(from Eric Bachelo) that there be more than one person listed in under
each problem domain. So far I've seen no comments.


Returning to the actual committee (yes I've been put forward as a
potential member).  Quoting the GCC committee's page
http://gcc.gnu.org/steering.html :

``Membership in the steering committee is a personal membership.
Affiliations are listed for identification purposes only; steering
committee members do not represent their employers or academic
institutions.''

``Generally speaking, committee members were chosen to represent the
interests of communities (e.g. Fortran users, embedded systems
developers, kernel hackers), not companies.''

I would argue that one key aspect the GCC stearing committee's success
is that it has ensured that the committee members are considered
individuals and are expected to ensure that any decisions made are both
transparent and independant.  This ain't no IOC :-)


Following on from this, the GCC's committee's primary purpose was:

``to make major decisions in the best interests of the GCC project and
to ensure that the project adheres to its fundamental principles found
in the project's mission statement.'' (see
http://gcc.gnu.org/gccmission.html ).

and this points to the committees' second success.  I being less
concerned with direct technical issues it has allowed the GCC
maintainers to persue GCC's development with rigor while still retaing
coheasion within the project.


As for what I think GDB should do?

There is long term benefit in having a small, largely symbolic, group
that ensure the independance of the maintainers.  Such a group being
selected using a criteria very similar to that of GCC (being truely
independant and only having GDB's interests first).

While such a group is being formed (is it a year now?) I think GDB
should continue with the status-quo - a notional head maintainer but
work delegated to problem domain maintainers.  The main thing to ensure
is that this group demonstrates technical independance when making
day-to-day decisions.

With regard to architectural and stategic problems I think they should
continue to be debated and deveoped in a public forum.  The criteria for
debate being strictly technical.  A committee might have a role but not
as one that directly sets the development agenda.

	enjoy,
		Andrew

(1) Sorry about this
(2) Public CVS repositories are relatively recent phenomina when
compared to the age of GDB :-)
From eliz@delorie.com Sat Apr 01 00:00:00 2000
From: Eli Zaretskii <eliz@delorie.com>
To: hjl@valinux.com
Cc: gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A patch for ia32 hardware watchpoint.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200003081132.GAA16847@indy.delorie.com>
References: <20000307132613.B20282@valinux.com>
X-SW-Source: 2000-q1/msg00597.html
Content-length: 1455

> > @@ -5500,13 +5513,13 @@ watch_command_1 (arg, accessflag, from_t
> >     in hardware return zero.  */
> >  
> >  #if !defined(TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT)
> > -#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(BYTE_SIZE) \
> > -    ((BYTE_SIZE) <= (REGISTER_SIZE))
> > +#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL) \
> > +    (TYPE_LENGTH (VALUE_TYPE (VAL)) <= (REGISTER_SIZE))
> >  #endif
> >  
> >  #if !defined(TARGET_REGION_OK_FOR_HW_WATCHPOINT)
> > -#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(ADDR,LEN) \
> > -     TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(LEN)
> > +#define TARGET_REGION_OK_FOR_HW_WATCHPOINT(VAL) \
> > +     TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(VAL)
> >  #endif
> 
> These are IMHO wrong: the number of debug registers required for a
> particular region is a function of the address, not only size (e.g., a
> single x86 debug register cannot watch a 32-bit region that isn't
> aligned on 4-byte boundary).  If Linux, for some reason, doesn't need
> the address (although I cannot see how could this be right, at least
> for native debugging), please define a platform-specific macro instead
> of overwriting system-wide defaults.

Sorry, I talked too soon.  These changes supply all the required info,
since they pass the entire struct value to the macro.  So they are
okay with me.

I'm terribly sorry for jumping the gun for no reason.

The rest of my comments about these patches are still valid, though.
From gzp@gzp.org.hu Sat Apr 01 00:00:00 2000
From: "Gabor Z. Papp" <gzp@gzp.org.hu>
To: gdb@sourceware.cygnus.com
Subject: gdb cvs
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <20000302204824.B18856@gzp.org.hu>
References: <200003021924.e22JO4U19747@mail.gzp.org.hu>
X-SW-Source: 2000-q1/msg00513.html
Content-length: 5091

| cvs server: Updating gdb
| U gdb/CONTRIBUTE

[...]

| U gdb/vx-share/xdr_rdb.h
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/texinfo
| cvs server: ignoring module src/texinfo
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/bfd
| cvs server: ignoring module src/bfd
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/opcodes
| cvs server: ignoring module src/opcodes
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/readline
| cvs server: ignoring module src/readline
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/libiberty
| cvs server: ignoring module src/libiberty
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/mmalloc
| cvs server: ignoring module src/mmalloc
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/include
| cvs server: ignoring module src/include
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/sim
| cvs server: ignoring module src/sim
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/utils
| cvs server: ignoring module src/utils
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/.cvsignore
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/COPYING
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/COPYING.LIB
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ChangeLog
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/Makefile.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/README
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/config
| cvs server: ignoring module src/config
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config-ml.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.guess
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.if
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/config.sub
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/configure
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/configure.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/etc
| cvs server: ignoring module src/etc
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/install-sh
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ltconfig
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ltmain.sh
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/makefile.vms
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/missing
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mkdep
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mkinstalldirs
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/move-if-change
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-README
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-build.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-config.in
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-configure
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/mpw-install
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/setup.com
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/symlink-tree
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src
| cvs server: ignoring module src/ylwrap
| cvs server: existing repository /cvs/src/src/gdb does not match /cvs/src/src/intl
| cvs server: ignoring module src/intl

Is this correct?
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: "Lim, Sung-taek" <totohero@poppy.snu.ac.kr>
Cc: gdb mailinglist <gdb@sourceware.cygnus.com>
Subject: Re: How can I generate exceptions for arm-elf-gdb simulator target?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38AA4995.6FF8DF90@cygnus.com>
References: <003801bf6630$d9c9af00$8f742e93@snu.ac.kr>
X-SW-Source: 2000-q1/msg00305.html
Content-length: 193

"Lim, Sung-taek" wrote:
> 
> I want to test my FIQ exception handlers in arm-elf-gdb simulator target.
> How can I invoke such exceptions?

Did anyone have an answer to this question?

	Andrew
From shebs@shebs.cnchost.com Sat Apr 01 00:00:00 2000
From: Stan Shebs <shebs@shebs.cnchost.com>
To: Kevin_Hendricks <khendricks@admin.ivey.uwo.ca>
Cc: gdb@sourceware.cygnus.com, patl@cag.lcs.mit.edu
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A0465C.DFF30C60@shebs.cnchost.com>
References: <200002081520.KAA19603@hood.cnchost.com>
X-SW-Source: 2000-q1/msg00168.html
Content-length: 3139

Kevin_Hendricks wrote:

> And while you are at it, why not fix gdb to actually work with ppc and actually
> really and truly support a major platform (ppc) RIGHT_OUT_OF_THE_BOX god forbid!

If the author of the patches doesn't want to put them in as-is, I for one am not
going to override him...

> I am so tired of fighting with non-working gdb on ppc that gdb has become next
> to useless.  I am now getting hangs with wierd thread errors when debugging
> programs with Franz Sirl's gdb (and his is the *best* one I have found on ppc so
> far).

Now you know why we don't want to just hack in patches, eh?

>  2. patches need to be in the right FSF format or we can't except them
>     (what bullshit)

Depends on the project.  GCC is usually much tougher about patches than GDB,
so it surprises me you think it's easier to get a patch in there.

>  3. we can't use your patch you have not signed a damn release
>     (again why do none of the other FSF project require this).

This is simply not true.  *Every* FSF project requires this.  It may be
that some maintainers are being sloppy (in which case they'll hear from
RMS), and of course very small patches don't need an assignment.  Note that
the Linux kernel is not an FSF project, and they don't have any such
rule.

> Why is gdb so different?

I'm most familiar with GCC, and one big difference between GCC and GDB is that
GCC has more maintainers.  I've been recruiting people to be GDB maintainers
for years, and yet the list of people in gdb/MAINTAINERS is still very short,
which sucks - it means that the few available people have to do all the work.
We really do need more people to take up the responsibility for maintenance;
Cygnus/Red Hat can't do it all.

> Why can't it open up it process of getting patches in?

If by "open up", you mean "lower the standards", then no, we don't want to do
that.  I know for instance that GCC has not lowered its standards, and indeed
GDB has been criticized for having lower standards than some other projects.

If you mean, "provide quicker feedback" on patches, yes, that is a known
problem area.  See my comment on the number of maintainers available.

> Why is gdb development not geared to support Linux (any architecture) in any
> reasonable manner?

What do you mean by this?  I don't see the development as being "geared" in any
way - the development is driven by maintainers and contributors, all of whom we
know by name.  So if something is happening or not happening, it's because
particular people are or are not working on it.  If you mean "why is Kevin Buettner
not working on PowerPC GDB enough" :-), you can ask him that directly.

> So now we will have yet another new major gdb release without things working on
> powerpc (expected!) or even x86 linux???.

Last fall I said that one of the goals for 5.0 should be to support PowerPC Linux.

I still think that should be a goal, but timing will be driven by the people who
are actually doing the work, and by the amount of work, which, judging by your
comments above, is more than I had thought.  So it's going to take some committed
effort to make it happen.

Stan
From fnasser@cygnus.com Sat Apr 01 00:00:00 2000
From: Fernando Nasser <fnasser@cygnus.com>
To: Grant Edwards <grante@visi.com>
Cc: Fernando Nasser <fnasser@redhat.com>, gdb@sourceware.cygnus.com
Subject: Re: RDI target broken in 000215 snapshot
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38B58DAE.9CAA0A59@cygnus.com>
References: <20000221104541.A28578@visi.com> <38B2AD14.7B0B4A4E@redhat.com> <20000224124726.A663@visi.com> <38B58292.3B11D622@cygnus.com> <20000224134607.A6354@visi.com>
X-SW-Source: 2000-q1/msg00404.html
Content-length: 1476

Grant Edwards wrote:
> 
> Another interesting bit of info.  The new snapshot is apparently not
> detecting the endianness of the target (both the sessions below were
> with a Samsung SNDS evel board (big-endian):
> 

I guess you got it.

Can you set the endianess and do the load after that?

Please let me know if it worked.

In the meanwhile I will check for differences (my build is still going on :-)

Thanks,
Fernando





> $ arm-elf-gdb
> GNU gdb 4.18
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr  1 1998 at 00:43:57
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently big endian)
> 
> 
> $ ~/gdb-000222/gdb/gdb
> GNU gdb 000222
> [...]
> This GDB was configured as "--host=i586-pc-linux-gnu --target=arm-elf".
> (gdb) target rdi /dev/ttyS1
> EmbeddedICE Manager (ADP, ARM7TDI) 2.07 (Advanced RISC Machines SDT 2.11a)
> Rebuilt on Apr  1 1998 at 00:43:57
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) show endian
> The target endianness is set automatically (currently little endian)
> 
> --
> Grant

-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
From kingdon@redhat.com Sat Apr 01 00:00:00 2000
From: Jim Kingdon <kingdon@redhat.com>
To: gdb@sourceware.cygnus.com
Subject: Re: GDB configure problem in the new repository...
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <b3dqvkfru.fsf@rtl.cygnus.com>
References: <38A41C50.F4E522DD@netwinder.org> <38A42322.90819896@netwinder.org> <38A7D838.185888FC@cygnus.com>
X-SW-Source: 2000-q1/msg00265.html
Content-length: 608

> The only problem with all this is that it is putting real pressure on
> gdb/configure.in and gdb/Makefile.in (to be honest it's a bit of a
> mess).

Yeah, Someone (you know, Someone, that mythical volunteer) needs to
come up with some kind of module system (like Apache or the linux
kernel, probably, in that modules can either be linked in at run time
or build time).  There would be a variety of ways to set this up (some
simpler than others) but it should be obvious that we need a general
mechanism rather than the current ad hoc Insight and TUI bits in
gdb/configure.in and gdb/Makefile.in.
From jimb@zwingli.cygnus.com Sat Apr 01 00:00:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Jim Kingdon <kingdon@redhat.com>
Cc: Mark Kettenis <kettenis@wins.uva.nl>, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: A revised patch for dlclose
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <npwvndaxzu.fsf@zwingli.cygnus.com>
References: <20000307120800.A27315@valinux.com> <200003080058.e280wga00453@delius.kettenis.local> <bzosakrpu.fsf@rtl.cygnus.com>
X-SW-Source: 2000-q1/msg00622.html
Content-length: 537

> I do agree with HJ about one thing, though, which is that this issue
> is rather important.  I'm trying to put my money where my mouth is by
> writing code but I'll have to admit that JimB's message left me a
> little unsure about where to turn.

You mean the vague "I don't understand the logic" comment?  I concede
that it's not especially constructive criticism.  But it was the
truth.  :)

I think I've got some idea of how to fix this, but you know how these
things go --- don't let that stop you from thinking about it yourself.
From tromey@cygnus.com Sat Apr 01 00:00:00 2000
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: problems with gdb
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <87u2j8y822.fsf@cygnus.com>
References: <38A47E89.3F4674B3@mozilla.org> <npael3tqk6.fsf@zwingli.cygnus.com> <38AB2DC4.FA9A3C71@redhat.com> <38AB3457.6902@cup.hp.com>
X-SW-Source: 2000-q1/msg00318.html
Content-length: 729

>>>>> ">" == Srikanth  <srikanth@cup.hp.com> writes:

>> 	The difficulty here is that a name lookup could be
>> based on either a  demangled name or a mangled name. So unless we
>> sort the table by both we will have to do linear search. Sorting
>> the table by both involves heavy penalty at startup, as that
>> entail three sorts with different keys (PC, demangled name and
>> mangled name). We eliminated one of the keys : the demangled name
>> and do a double sort. 

By eliminating this key don't you eliminate a valuable gdb feature?

Anyway, you can avoid the sort penalty by using a hash table instead.
You construct the hash table as you read the symbols.  (That's what my
patch does, as I recall.)

Tom
From alain.borlethote@free.fr Sat Apr 01 00:00:00 2000
From: "Alien" <alain.borlethote@free.fr>
To: <gdb@sourceware.cygnus.com>
Subject: r_debug protocol
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <003f01bf71a5$d5e28d00$a355fea9@borlethote>
X-SW-Source: 2000-q1/msg00134.html
Content-length: 222

Hello! Where can I find some information 
about r_debug protocol
(link.h, struct link_map) concerning shared library 
support? Thanks,                                         
Alain

Re: Shared libraries on Linux

[Jim Kingdon]

> Tue Feb  8 18:19:22 2000  H.J. Lu  <hjl@gnu.org>

Well, this one does work for me.

Based on reading the code (I didn't actually step through it), it
looks to me like the way it works is in the relevant case it calls
clear_solib, dumps all symbols, and then reloads them (even for
libraries which are still loaded).  That seems slow so I wonder why
the code was written that way.
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: [Maint] Second testsuite maintainer
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38D84B37.B90E15AB@cygnus.com>
X-SW-Source: 2000-q1/msg00767.html
Content-length: 282

Another addition:

Add Fernando to list of testsuite maintainers.

testsuite	 	Stan Shebs		shebs@apple.com
			Fernando Nasser		fnasser@cygnus.com
  hp tests (gdb.hp)	*Jimmy Guo	 adl-debugger-wdb-merge-guru@cup.hp.com
  Java tests (gdb.java)	Anthony Green 		green@cygnus.com

Andrew
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: "Daniel Berlin" <dan@cgsoftware.com>
To: shebs@shebs.cnchost.com
Cc: dan@cgsoftware.com, muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com
Subject: Re: Status of submitted patches? Pascal language addition patch.
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <200002021720.JAA19067@propylaea.anduin.com>
X-SW-Source: 2000-q1/msg00096.html
Content-length: 1603

>
>Daniel Berlin wrote:
>> 
>> >   Apart from a few comments just after my email, I never got any
>> >constructive answer about the patch itself.
>> I must say, this isn't the first time this has happened.
>> I think we have no official maintainer.
>
>The list in gdb/MAINTAINERS lists specific areas of responsibility.
>For new things that don't fall in an existing area, I would either
>evaluate things myself or assign to the closest plausible person -
>which in this case is David Taylor, who's already responded.

I was reading through the website. Never thought to actually look at 
that file. Doh.

>
>
>That would be great.  In general, because an incautious checkin can
>cause huge amounts of chaos, it's better to take charge of a limited
>area and see how that goes.  I know that in the past we've talked 
about
>you taking over C++ support, and that still seems to me like a good
>starting point.

Works for me.

>
>> If we have a maintainer, no offense, but um, considering i haven't 
seen
>> any comments on any patches on gdb-patches in a while, and no sign 
of
>> them being integrated, you need to get on the ball.
>
>I agree.  To make excuses, maintenance is in an awkward situation 
right
>now, what with my life in major transition, Cygnus maintainers 
probably
>preoccupied with the Red Hat merger, and the GDB steering committee
>still unformed.  This should be sorted out in a couple of weeks 
though.
Oh, i understand all of this, I just see people who submit patches 
starting to get annoyed at the lack of response, and wanted to offer my 
help in any way possible.  

>
>Stan
From dan@cgsoftware.com Sat Apr 01 00:00:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: hjl@lucon.org, gdb@sourceware.cygnus.com
Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10002071657110.9999-100000@propylaea.anduin.com>
References: <200002080051.e180pit26400@delius.kettenis.local>
X-SW-Source: 2000-q1/msg00144.html
Content-length: 731

> 
> I bet debugging apps that dlopen() a shared object, then dlclose() it
> and then dlopen() a different shared object won't work under BeOS
> either (if that is possible under BeOS at all), but other than that,
> I'm not aware of any deficiencies.

No, they work fine.
You don't dlopen, you use load_add_on and unload_add_on, but it's
basically they same thing (you can emulate dlopen/dlclose perfectly with
it).
I just get notification of image (executable/shared library/etc)
createion/deletion from the debugger nub, and handle it there.

 > 
> HJ, are you really aware of problems with debugging shared objects
> that don't involve a dlclose() somehow?  If you are, could you *please*
> provide a testcase.
> 
> Mark
> 
> 

Re: Shared libraries on Linux

[Mark Kettenis]

   Date: Thu, 10 Feb 2000 16:26:40 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   On Wed, Feb 09, 2000 at 11:39:49PM -0500, Jim Kingdon wrote:
   > > Tue Feb  8 18:19:22 2000  H.J. Lu  <hjl@gnu.org>
   > 
   > Well, this one does work for me.
   > 
   > Based on reading the code (I didn't actually step through it), it
   > looks to me like the way it works is in the relevant case it calls
   > clear_solib, dumps all symbols, and then reloads them (even for
   > libraries which are still loaded).  That seems slow so I wonder why
   > the code was written that way.

   I believe there are 2 problems Sam tried to fix:

   1. Restart the problem when you have breakpointers set in a DSO
   which can be a shared library or loded in via dlopen.
   2. You have DSOs loaded/unloced via dlopen/dlclose. "info shared"
   may be wrong.

And again, I ask you for proof of 1.  As far as my experience goes,
restarting after setting a breakpoint in a shared object works
flawlessly.

   Sam's patch may not be the best. But it addresses those 2 problems.
   If there are no better alternatives, I don't see why we cannot use
   it even if it is slow.

I don't know if anybody uses remote debugging with systems that use
solib.c, but that could become really painful if it's done over a slow
link.

Otherwise, we might want to add the patch to the release branch once
that's been created, but I think a FIXME should be added.  Also people
should expect some regressions at the moment we really try to fix
things.  This "solution" has the potential of hiding bugs that might
be uncovered if a more intelligent solution is found.

Mark