Assume solib.h

Assume solib.h

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

Joseph, Kevin,

The attached patch illustrates the minimum needed to enable solibs for 
Solaris.  It just needs to be filled out so that other systems are 
updated like I did for PPC linux (hint, hint ;-)

Once this is in place we can follow through with other cleanups - much 
will fall out!

There's just one non-technical nit.

It means breaking non solib.[hc] shared library systems.  Kevin 
indicated that there were two - AIX and HP/UX remaining.  I think we can 
live with that - we've patiently waited for what, more than two years 
for nothing to happen, so it is now time to give things that gentle push.

What do each of you think,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 11169 bytes --]

 
	* config/powerpc/ppc-sim.mt (TDEPFILES): Remove solib.o.
	* config/powerpc/ppc-eabi.mt (TDEPFILES): Remove solib.o.
	* config/powerpc/linux.mt (TDEPFILES): Remove solib.o.
	* config/tm-linux.h: Don't include "solib.h".
	* symfile.c, stack.c, remote.c, infrun.c: Include "solib.h".
	* infcmd.c, fork-child.c, corelow.c, breakpoint.c: Include "solib.h".
	* Makefile.in (COMMON_OBS): Add solib.o.  Update dependencies.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.652
diff -p -u -r1.652 Makefile.in
--- Makefile.in	31 Oct 2004 20:47:55 -0000	1.652
+++ Makefile.in	11 Nov 2004 19:23:12 -0000
@@ -925,6 +925,7 @@ COMMON_OBS = $(DEPFILES) $(YYOBJ) \
 	nlmread.o serial.o mdebugread.o top.o utils.o \
 	ui-file.o \
 	user-regs.o \
+	solib.o \
 	frame.o frame-unwind.o doublest.o \
 	frame-base.o \
 	gnu-v2-abi.o gnu-v3-abi.o hpacc-abi.o cp-abi.o cp-support.o \
@@ -1749,7 +1750,7 @@ breakpoint.o: breakpoint.c $(defs_h) $(s
 	$(gdb_string_h) $(demangle_h) $(annotate_h) $(symfile_h) \
 	$(objfiles_h) $(source_h) $(linespec_h) $(completer_h) $(gdb_h) \
 	$(ui_out_h) $(cli_script_h) $(gdb_assert_h) $(block_h) $(solist_h) \
-	$(observer_h) $(gdb_events_h)
+	$(observer_h) $(solib_h) $(gdb_events_h)
 bsd-kvm.o: bsd-kvm.c $(defs_h) $(cli_cmds_h) $(command_h) $(frame_h) \
 	$(regcache_h) $(target_h) $(value_h) $(gdbcore_h) $(gdb_assert_h) \
 	$(readline_h) $(bsd_kvm_h)
@@ -1792,7 +1793,7 @@ corefile.o: corefile.c $(defs_h) $(gdb_s
 corelow.o: corelow.c $(defs_h) $(arch_utils_h) $(gdb_string_h) $(frame_h) \
 	$(inferior_h) $(symtab_h) $(command_h) $(bfd_h) $(target_h) \
 	$(gdbcore_h) $(gdbthread_h) $(regcache_h) $(regset_h) $(symfile_h) \
-	$(exec_h) $(readline_h) $(observer_h) $(gdb_assert_h)
+	$(exec_h) $(readline_h) $(observer_h) $(gdb_assert_h) $(solib_h)
 core-regset.o: core-regset.c $(defs_h) $(command_h) $(gdbcore_h) \
 	$(inferior_h) $(target_h) $(gdb_string_h) $(gregset_h)
 cp-abi.o: cp-abi.c $(defs_h) $(value_h) $(cp_abi_h) $(command_h) $(gdbcmd_h) \
@@ -1910,7 +1911,7 @@ f-lang.o: f-lang.c $(defs_h) $(gdb_strin
 	$(valprint_h) $(value_h)
 fork-child.o: fork-child.c $(defs_h) $(gdb_string_h) $(frame_h) \
 	$(inferior_h) $(target_h) $(gdb_wait_h) $(gdb_vfork_h) $(gdbcore_h) \
-	$(terminal_h) $(gdbthread_h) $(command_h)
+	$(terminal_h) $(gdbthread_h) $(command_h) $(solib_h)
 frame-base.o: frame-base.c $(defs_h) $(frame_base_h) $(frame_h) \
 	$(gdb_obstack_h)
 frame.o: frame.c $(defs_h) $(frame_h) $(target_h) $(value_h) $(inferior_h) \
@@ -2081,7 +2082,7 @@ infcmd.o: infcmd.c $(defs_h) $(gdb_strin
 	$(symfile_h) $(gdbcore_h) $(target_h) $(language_h) $(symfile_h) \
 	$(objfiles_h) $(completer_h) $(ui_out_h) $(event_top_h) \
 	$(parser_defs_h) $(regcache_h) $(reggroups_h) $(block_h) \
-	$(gdb_assert_h)
+	$(gdb_assert_h) $(solib_h)
 inf-loop.o: inf-loop.c $(defs_h) $(inferior_h) $(target_h) $(event_loop_h) \
 	$(event_top_h) $(inf_loop_h) $(remote_h)
 inflow.o: inflow.c $(defs_h) $(frame_h) $(inferior_h) $(command_h) \
@@ -2097,7 +2098,7 @@ infrun.o: infrun.c $(defs_h) $(gdb_strin
 	$(inferior_h) $(breakpoint_h) $(gdb_wait_h) $(gdbcore_h) $(gdbcmd_h) \
 	$(cli_script_h) $(target_h) $(gdbthread_h) $(annotate_h) \
 	$(symfile_h) $(top_h) $(inf_loop_h) $(regcache_h) $(value_h) \
-	$(observer_h) $(language_h) $(gdb_assert_h)
+	$(observer_h) $(language_h) $(gdb_assert_h) $(infrun_c)
 inftarg.o: inftarg.c $(defs_h) $(frame_h) $(inferior_h) $(target_h) \
 	$(gdbcore_h) $(command_h) $(gdb_stat_h) $(observer_h) $(gdb_wait_h) \
 	$(inflow_h)
@@ -2382,7 +2383,7 @@ regset.o: regset.c $(defs_h) $(regset_h)
 remote.o: remote.c $(defs_h) $(gdb_string_h) $(inferior_h) $(bfd_h) \
 	$(symfile_h) $(target_h) $(gdbcmd_h) $(objfiles_h) $(gdb_stabs_h) \
 	$(gdbthread_h) $(remote_h) $(regcache_h) $(value_h) $(gdb_assert_h) \
-	$(event_loop_h) $(event_top_h) $(inf_loop_h) $(serial_h) \
+	$(solib_h) $(event_loop_h) $(event_top_h) $(inf_loop_h) $(serial_h) \
 	$(gdbcore_h) $(remote_fileio_h)
 remote-e7000.o: remote-e7000.c $(defs_h) $(gdbcore_h) $(gdbarch_h) \
 	$(inferior_h) $(target_h) $(value_h) $(command_h) $(gdb_string_h) \
@@ -2603,7 +2604,8 @@ stack.o: stack.c $(defs_h) $(gdb_string_
 	$(gdbtypes_h) $(expression_h) $(language_h) $(frame_h) $(gdbcmd_h) \
 	$(gdbcore_h) $(target_h) $(source_h) $(breakpoint_h) $(demangle_h) \
 	$(inferior_h) $(annotate_h) $(ui_out_h) $(block_h) $(stack_h) \
-	$(gdb_assert_h) $(dictionary_h) $(reggroups_h) $(regcache_h)
+	$(gdb_assert_h) $(dictionary_h) $(reggroups_h) $(regcache_h) \
+	$(solib_h)
 std-regs.o: std-regs.c $(defs_h) $(user_regs_h) $(frame_h) $(gdbtypes_h) \
 	$(value_h) $(gdb_string_h)
 stop-gdb.o: stop-gdb.c $(defs_h)
@@ -2612,7 +2614,7 @@ symfile.o: symfile.c $(defs_h) $(bfdlink
 	$(objfiles_h) $(source_h) $(gdbcmd_h) $(breakpoint_h) $(language_h) \
 	$(complaints_h) $(demangle_h) $(inferior_h) $(filenames_h) \
 	$(gdb_stabs_h) $(gdb_obstack_h) $(completer_h) $(bcache_h) \
-	$(hashtab_h) $(readline_h) $(gdb_assert_h) $(block_h) \
+	$(hashtab_h) $(readline_h) $(gdb_assert_h) $(block_h) $(solib_h) \
 	$(gdb_string_h) $(gdb_stat_h)
 symfile-mem.o: symfile-mem.c $(defs_h) $(symtab_h) $(gdbcore_h) \
 	$(objfiles_h) $(gdbcmd_h) $(target_h) $(value_h) $(symfile_h)
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.184
diff -p -u -r1.184 breakpoint.c
--- breakpoint.c	29 Oct 2004 20:23:04 -0000	1.184
+++ breakpoint.c	11 Nov 2004 19:23:13 -0000
@@ -51,7 +51,7 @@
 #include "block.h"
 #include "solist.h"
 #include "observer.h"
-
+#include "solib.h"
 #include "gdb-events.h"
 
 /* Prototypes for local functions. */
Index: corelow.c
===================================================================
RCS file: /cvs/src/src/gdb/corelow.c,v
retrieving revision 1.43
diff -p -u -r1.43 corelow.c
--- corelow.c	29 Oct 2004 20:23:05 -0000	1.43
+++ corelow.c	11 Nov 2004 19:23:13 -0000
@@ -45,6 +45,7 @@
 #include "readline/readline.h"
 #include "observer.h"
 #include "gdb_assert.h"
+#include "solib.h"
 
 #ifndef O_BINARY
 #define O_BINARY 0
Index: fork-child.c
===================================================================
RCS file: /cvs/src/src/gdb/fork-child.c,v
retrieving revision 1.23
diff -p -u -r1.23 fork-child.c
--- fork-child.c	30 Sep 2004 20:15:39 -0000	1.23
+++ fork-child.c	11 Nov 2004 19:23:13 -0000
@@ -33,7 +33,7 @@
 #include "terminal.h"
 #include "gdbthread.h"
 #include "command.h" /* for dont_repeat () */
-
+#include "solib.h"
 #include <signal.h>
 
 /* This just gets used as a default if we can't find SHELL.  */
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.124
diff -p -u -r1.124 infcmd.c
--- infcmd.c	29 Oct 2004 20:23:08 -0000	1.124
+++ infcmd.c	11 Nov 2004 19:23:13 -0000
@@ -45,6 +45,7 @@
 #include "block.h"
 #include <ctype.h>
 #include "gdb_assert.h"
+#include "solib.h"
 
 /* Functions exported for general use, in inferior.h: */
 
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.181
diff -p -u -r1.181 infrun.c
--- infrun.c	31 Oct 2004 17:38:15 -0000	1.181
+++ infrun.c	11 Nov 2004 19:23:13 -0000
@@ -45,6 +45,7 @@
 #include "observer.h"
 #include "language.h"
 #include "gdb_assert.h"
+#include "solib.c"
 
 /* Prototypes for local functions */
 
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.152
diff -p -u -r1.152 remote.c
--- remote.c	27 Oct 2004 20:03:50 -0000	1.152
+++ remote.c	11 Nov 2004 19:23:13 -0000
@@ -40,6 +40,7 @@
 #include "regcache.h"
 #include "value.h"
 #include "gdb_assert.h"
+#include "solib.h"
 
 #include <ctype.h>
 #include <sys/time.h>
Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.115
diff -p -u -r1.115 stack.c
--- stack.c	30 Oct 2004 21:16:10 -0000	1.115
+++ stack.c	11 Nov 2004 19:23:13 -0000
@@ -45,6 +45,7 @@
 #include "dictionary.h"
 #include "reggroups.h"
 #include "regcache.h"
+#include "solib.h"
 
 /* Prototypes for exported functions. */
 
Index: symfile.c
===================================================================
RCS file: /cvs/src/src/gdb/symfile.c,v
retrieving revision 1.144
diff -p -u -r1.144 symfile.c
--- symfile.c	23 Oct 2004 16:18:09 -0000	1.144
+++ symfile.c	11 Nov 2004 19:23:15 -0000
@@ -48,6 +48,7 @@
 #include "readline/readline.h"
 #include "gdb_assert.h"
 #include "block.h"
+#include "solib.h"
 
 #include <sys/types.h>
 #include <fcntl.h>
Index: config/tm-linux.h
===================================================================
RCS file: /cvs/src/src/gdb/config/tm-linux.h,v
retrieving revision 1.6
diff -p -u -r1.6 tm-linux.h
--- config/tm-linux.h	3 Sep 2004 17:13:47 -0000	1.6
+++ config/tm-linux.h	11 Nov 2004 19:23:15 -0000
@@ -31,5 +31,3 @@
 /* We need this file for the SOLIB_TRAMPOLINE stuff. */
 
 #include "config/tm-sysv4.h"
-
-#include "solib.h"		/* Support for shared libraries. */
Index: config/powerpc/linux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/linux.mt,v
retrieving revision 1.7
diff -p -u -r1.7 linux.mt
--- config/powerpc/linux.mt	13 Sep 2004 20:55:41 -0000	1.7
+++ config/powerpc/linux.mt	11 Nov 2004 19:23:15 -0000
@@ -1,5 +1,5 @@
 # Target: Motorola PPC on Linux
-TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o solib.o \
+TDEPFILES= rs6000-tdep.o ppc-linux-tdep.o ppc-sysv-tdep.o \
 	solib-svr4.o solib-legacy.o corelow.o
 DEPRECATED_TM_FILE= tm-linux.h
 
Index: config/powerpc/ppc-eabi.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/ppc-eabi.mt,v
retrieving revision 1.6
diff -p -u -r1.6 ppc-eabi.mt
--- config/powerpc/ppc-eabi.mt	13 Sep 2004 20:55:41 -0000	1.6
+++ config/powerpc/ppc-eabi.mt	11 Nov 2004 19:23:15 -0000
@@ -1,3 +1,3 @@
 # Target: PowerPC running eabi
-TDEPFILES= rs6000-tdep.o monitor.o dsrec.o ppcbug-rom.o dink32-rom.o ppc-bdm.o ocd.o remote-sds.o ppc-sysv-tdep.o solib.o solib-svr4.o
+TDEPFILES= rs6000-tdep.o monitor.o dsrec.o ppcbug-rom.o dink32-rom.o ppc-bdm.o ocd.o remote-sds.o ppc-sysv-tdep.o solib-svr4.o
 DEPRECATED_TM_FILE= tm-ppc-eabi.h
Index: config/powerpc/ppc-sim.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/powerpc/ppc-sim.mt,v
retrieving revision 1.6
diff -p -u -r1.6 ppc-sim.mt
--- config/powerpc/ppc-sim.mt	13 Sep 2004 20:55:41 -0000	1.6
+++ config/powerpc/ppc-sim.mt	11 Nov 2004 19:23:15 -0000
@@ -1,5 +1,5 @@
 # Target: PowerPC running eabi and including the simulator
-TDEPFILES= rs6000-tdep.o monitor.o dsrec.o ppcbug-rom.o dink32-rom.o ppc-bdm.o ocd.o remote-sds.o ppc-sysv-tdep.o solib.o solib-svr4.o
+TDEPFILES= rs6000-tdep.o monitor.o dsrec.o ppcbug-rom.o dink32-rom.o ppc-bdm.o ocd.o remote-sds.o ppc-sysv-tdep.o solib-svr4.o
 DEPRECATED_TM_FILE= tm-ppc-eabi.h
 
 SIM_OBS = remote-sim.o

Re: Assume solib.h

[Mark Kettenis]

   Date: Thu, 11 Nov 2004 14:38:08 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Joseph, Kevin,

   The attached patch illustrates the minimum needed to enable solibs for 
   Solaris.  It just needs to be filled out so that other systems are 
   updated like I did for PPC linux (hint, hint ;-)

   Once this is in place we can follow through with other cleanups - much 
   will fall out!

   There's just one non-technical nit.

   It means breaking non solib.[hc] shared library systems.  Kevin 
   indicated that there were two - AIX and HP/UX remaining.  I think we can 
   live with that - we've patiently waited for what, more than two years 
   for nothing to happen, so it is now time to give things that gentle push.

IIRC (and looking at the code I think I do remember it correctly) this
also breaks targets without shared library support.  I think that's
unacceptable.  Some simple tweaks to solib.c might be enough to fix
this, but please don't check in something like this without testing
this on some sort of embedded target, vax-dec-openbsd* or
vax-dec-ultrix4*.

Mark

Re: Assume solib.h

[Andrew Cagney]

Mark Kettenis wrote:
>    Date: Thu, 11 Nov 2004 14:38:08 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    Joseph, Kevin,
> 
>    The attached patch illustrates the minimum needed to enable solibs for 
>    Solaris.  It just needs to be filled out so that other systems are 
>    updated like I did for PPC linux (hint, hint ;-)
> 
>    Once this is in place we can follow through with other cleanups - much 
>    will fall out!
> 
>    There's just one non-technical nit.
> 
>    It means breaking non solib.[hc] shared library systems.  Kevin 
>    indicated that there were two - AIX and HP/UX remaining.  I think we can 
>    live with that - we've patiently waited for what, more than two years 
>    for nothing to happen, so it is now time to give things that gentle push.
> 
> IIRC (and looking at the code I think I do remember it correctly) this
> also breaks targets without shared library support.

I gave it a full test with PowerPC GNU/Linux and sniff test with 
powerpc-elf.  If there are other problems, I'm sure they'll be sorted out.

Andrew

Re: Assume solib.h

[Mark Kettenis]

   Date: Thu, 11 Nov 2004 16:46:54 -0500
   From: Andrew Cagney <cagney@gnu.org>

   Mark Kettenis wrote:
   >    Date: Thu, 11 Nov 2004 14:38:08 -0500
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    Joseph, Kevin,
   > 
   >    The attached patch illustrates the minimum needed to enable solibs for 
   >    Solaris.  It just needs to be filled out so that other systems are 
   >    updated like I did for PPC linux (hint, hint ;-)
   > 
   >    Once this is in place we can follow through with other cleanups - much 
   >    will fall out!
   > 
   >    There's just one non-technical nit.
   > 
   >    It means breaking non solib.[hc] shared library systems.  Kevin 
   >    indicated that there were two - AIX and HP/UX remaining.  I think we can 
   >    live with that - we've patiently waited for what, more than two years 
   >    for nothing to happen, so it is now time to give things that gentle push.
   > 
   > IIRC (and looking at the code I think I do remember it correctly) this
   > also breaks targets without shared library support.

   I gave it a full test with PowerPC GNU/Linux and sniff test with 
   powerpc-elf.  If there are other problems, I'm sure they'll be sorted out.

Really?

fork-child.c:fork_inferior() 
    ||
    \/
SOLIB_CREATE_INFERIOR_HOOK
    ||
    \/
solib.c:solib_create_inferior_hook()
    ||
    \/
TARGET_SO_SOLIB_CREATE_INFERIOR_HOOK
    ||
    \/
current_target_so_ops->solib_create_inferior_hook()

which, if you don't include any of:

   solib-aix5.c
   solib-frv.c
   solib-irix.c
   solib-osf.c
   solib-sunos.c
   solib-svr4.c

is a null pointer.

Sorry Andrew, but if you want this to go in, you'll have to fix it.
(Of course I might do that myself to get OpenBSD/mips64 working again).

Mark

Re: Assume solib.h

[Andrew Cagney]

Mark Kettenis wrote:
>    Date: Thu, 11 Nov 2004 16:46:54 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    Mark Kettenis wrote:
>    >    Date: Thu, 11 Nov 2004 14:38:08 -0500
>    >    From: Andrew Cagney <cagney@gnu.org>
>    > 
>    >    Joseph, Kevin,
>    > 
>    >    The attached patch illustrates the minimum needed to enable solibs for 
>    >    Solaris.  It just needs to be filled out so that other systems are 
>    >    updated like I did for PPC linux (hint, hint ;-)
>    > 
>    >    Once this is in place we can follow through with other cleanups - much 
>    >    will fall out!
>    > 
>    >    There's just one non-technical nit.
>    > 
>    >    It means breaking non solib.[hc] shared library systems.  Kevin 
>    >    indicated that there were two - AIX and HP/UX remaining.  I think we can 
>    >    live with that - we've patiently waited for what, more than two years 
>    >    for nothing to happen, so it is now time to give things that gentle push.
>    > 
>    > IIRC (and looking at the code I think I do remember it correctly) this
>    > also breaks targets without shared library support.
> 
>    I gave it a full test with PowerPC GNU/Linux and sniff test with 
>    powerpc-elf.  If there are other problems, I'm sure they'll be sorted out.
> 
> Really?

Really!  Please look again at the proposal.

> Sorry Andrew, but if you want this to go in, you'll have to fix it.
> (Of course I might do that myself to get OpenBSD/mips64 working again).

as in your earlier comment:

> please don't check in something like this without testing
> this on some sort of embedded target, vax-dec-openbsd* or
> vax-dec-ultrix4*.

I'm really really sorry here (and remember I also hack on *BSD, even 
down to kernel fixes - you're hardly a voice in the wilderness on this 
one).  We can't do this.

My change allows Code Sorcery to achieve their goal of getting Solaris 
10 support in GDB, while at the same time allow us to move forward with 
our objective of improving support for GNU, GNU/Linux and even the other 
mainstream Free and non-Free platform support.

We win - Code Sorcery Wins; we have a symbiotic relationship.

On the other hand, by effectively requiring that a contributor must 
first test/fix a change on marginal if not irrelevant systems such as 
vax-dec-ultrix4 (the suggestion also carried other less pleasant 
undertones), can only stall the host's (GDB's) development.  Isn't that 
called a parasitic relationship?

Andrew

 > 6 Platforms to Support
 > http://www.fsf.org/prep/maintain/html_node/Platforms.html#Platforms

Re: Assume solib.h

[Eli Zaretskii]

> Date: Fri, 12 Nov 2004 10:51:07 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: joseph@codesourcery.com, kevinb@redhat.com, gdb-patches@sources.redhat.com
> > please don't check in something like this without testing
> > this on some sort of embedded target, vax-dec-openbsd* or
> > vax-dec-ultrix4*.
> 
> I'm really really sorry here (and remember I also hack on *BSD, even 
> down to kernel fixes - you're hardly a voice in the wilderness on this 
> one).  We can't do this.
> 
> My change allows Code Sorcery to achieve their goal of getting Solaris 
> 10 support in GDB, while at the same time allow us to move forward with 
> our objective of improving support for GNU, GNU/Linux and even the other 
> mainstream Free and non-Free platform support.
> 
> We win - Code Sorcery Wins; we have a symbiotic relationship.
> 
> On the other hand, by effectively requiring that a contributor must 
> first test/fix a change on marginal if not irrelevant systems such as 
> vax-dec-ultrix4 (the suggestion also carried other less pleasant 
> undertones), can only stall the host's (GDB's) development.  Isn't that 
> called a parasitic relationship?

I'm with Mark on this one: a patch that potentially breaks a supported
platform doesn't get my vote.  If a platform is supported, it deserves
that we don't break it, and calling it ``marginal'' doesn't change
anything.

I don't see how any affiliation we might have with Code Sorcery
justifies that we do partial job when checking in a change.  If they
want Solaris support that badly, they can use your changes locally.

Re: Assume solib.h

[Kevin Buettner]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Fri, 12 Nov 2004 19:14:30 +0200
"Eli Zaretskii" <eliz@gnu.org> wrote:

> I'm with Mark on this one: a patch that potentially breaks a supported
> platform doesn't get my vote.  If a platform is supported, it deserves
> that we don't break it, and calling it ``marginal'' doesn't change
> anything.

Mark, Eli,

Would the addition of the attached file (solib-null.c) to Andrew's patch
address your concerns?  (Makefile.in has to change too; basically
solib-null.o is unconditionally built and linked into gdb.  I can post
a patch if desired...)

I've not been able to test it as thoroughly as I'd like, but it does
seem to get me past some solib related problems on remote targets which
lack shared library support.

Kevin

[-- Attachment #2: solib-null.c --]
[-- Type: text/plain, Size: 2288 bytes --]

/* Definitions for targets without shared libraries for GDB, the GNU Debugger.

   Copyright 2004
   Free Software Foundation, Inc.

   This file is part of GDB.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 2 of the License, or
   (at your option) any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 59 Temple Place - Suite 330,
   Boston, MA 02111-1307, USA.  */

#include "defs.h"
#include "solist.h"

static struct so_list *
null_current_sos (void)
{
  return NULL;
}

static void
null_special_symbol_handling (void)
{
}

static void
null_solib_create_inferior_hook (void)
{
}

static void
null_clear_solib (void)
{
}

static void
null_free_so (struct so_list *so)
{
  xfree (so->lm_info);
}


static void
null_relocate_section_addresses (struct so_list *so,
                                 struct section_table *sec)
{
}

static int
null_open_symbol_file_object (void *from_ttyp)
{
  return 0;
}

static int
null_in_dynsym_resolve_code (CORE_ADDR pc)
{
  return 0;
}

static struct target_so_ops null_so_ops;

extern initialize_file_ftype _initialize_null_solib; /* -Wmissing-prototypes */

void
_initialize_null_solib (void)
{
  null_so_ops.relocate_section_addresses = null_relocate_section_addresses;
  null_so_ops.free_so = null_free_so;
  null_so_ops.clear_solib = null_clear_solib;
  null_so_ops.solib_create_inferior_hook = null_solib_create_inferior_hook;
  null_so_ops.special_symbol_handling = null_special_symbol_handling;
  null_so_ops.current_sos = null_current_sos;
  null_so_ops.open_symbol_file_object = null_open_symbol_file_object;
  null_so_ops.in_dynsym_resolve_code = null_in_dynsym_resolve_code;

  /* Set current_target_so_ops to null_so_ops if not already set.  */
  if (current_target_so_ops == 0)
    current_target_so_ops = &null_so_ops;
}

Re: Assume solib.h

[Mark Kettenis]

   Date: Mon, 15 Nov 2004 14:32:17 -0700
   From: Kevin Buettner <kevinb@redhat.com>

   This is a multi-part message in MIME format.

   --Multipart=_Mon__15_Nov_2004_14_32_17_-0700_xcMRgDYW/T7vXH4.
   Content-Type: text/plain; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   On Fri, 12 Nov 2004 19:14:30 +0200
   "Eli Zaretskii" <eliz@gnu.org> wrote:

   > I'm with Mark on this one: a patch that potentially breaks a supported
   > platform doesn't get my vote.  If a platform is supported, it deserves
   > that we don't break it, and calling it ``marginal'' doesn't change
   > anything.

   Mark, Eli,

   Would the addition of the attached file (solib-null.c) to Andrew's patch
   address your concerns?  (Makefile.in has to change too; basically
   solib-null.o is unconditionally built and linked into gdb.  I can post
   a patch if desired...)

I think it would, although I've been working on a slightly more
complicated solution that's a bit more multi-arch.  I've attached an
initial patch, but this really needs a bit more work.

   I've not been able to test it as thoroughly as I'd like, but it does
   seem to get me past some solib related problems on remote targets which
   lack shared library support.

It looks good to me.  It can't really hurt things, and it'll serve as
a stopgap while I'm finishing up my multi-arch patch.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* solib.c: Update copyright year.  Include "gdbarch.h".
	(solib_data): New variable.
	(solib_init): New function.
	(solib_open, solib_map_sections, free_so, update_solib_list)
	(solib_add, clear_solib, solib_create_inferior_hook): Get shared
	library architecture operations from architecture; allow them to
	be unimplemented.
	* solist.h (TARGET_SO_RELOCATE_SECTION_ADDRESS)
	(TARGET_SO_FREE_SO, TARGET_SO_CLEAR_SOLIB)
	(TARGET_SO_SOLIB_CREATE_INFERIOR_HOOK)
	(TARGET_SO_SPECIAL_SYMBOL_HANDLING, TARGET_SO_CURRENT_SOS)
	(TARGET_SO_OPEN_SYMBOL_FILE_OBJECT)
	(TARGET_SO_IN_DYNSYM_RESOLVE_CODE)
	(TARGET_SO_FIND_AND_OPEN_SOLIB): Remove.

Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.68
diff -u -p -r1.68 solib.c
--- solib.c 11 Sep 2004 10:24:50 -0000 1.68
+++ solib.c 15 Nov 2004 23:26:54 -0000
@@ -1,7 +1,7 @@
 /* Handle shared libraries for GDB, the GNU Debugger.
 
    Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-   1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
+   1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
 
    This file is part of GDB.
 
@@ -21,6 +21,7 @@
    Boston, MA 02111-1307, USA.  */
 
 #include "defs.h"
+#include "gdbarch.h"
 
 #include <sys/types.h>
 #include <fcntl.h>
@@ -68,6 +69,29 @@ static char *solib_absolute_prefix = NUL
    symbol files.  This takes precedence over the environment variables PATH
    and LD_LIBRARY_PATH.  */
 static char *solib_search_path = NULL;
+\f
+
+/* Architecture-specific operations.  */
+
+/* Per-architecture data key.  */
+static struct gdbarch_data *solib_data;
+
+/* Return a default for the architecture-specific operations.  */
+
+static void *
+solib_init (struct obstack *obstack)
+{
+  struct target_so_ops *ops;
+
+  ops = OBSTACK_ZALLOC (obstack, struct target_so_ops);
+
+  /* FIXME: kettenis/20041112: This should be removed.  */
+  if (current_target_so_ops)
+    memcpy (ops, current_target_so_ops, sizeof (struct target_so_ops));
+
+  return ops;
+}
+\f
 
 /*
 
@@ -109,6 +133,7 @@ static char *solib_search_path = NULL;
 int
 solib_open (char *in_pathname, char **found_pathname)
 {
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
   int found_file = -1;
   char *temp_pathname = NULL;
   char *p = in_pathname;
@@ -169,9 +194,9 @@ solib_open (char *in_pathname, char **fo
                         &temp_pathname);
 
   /* If not found, try to use target supplied solib search method */
-  if (found_file < 0 && TARGET_SO_FIND_AND_OPEN_SOLIB != NULL)
-    found_file = TARGET_SO_FIND_AND_OPEN_SOLIB
-                 (in_pathname, O_RDONLY, &temp_pathname);
+  if (found_file < 0 && ops->find_and_open_solib)
+    found_file = ops->find_and_open_solib (in_pathname, O_RDONLY,
+					   &temp_pathname);
 
   /* If not found, next search the inferior's $PATH environment variable. */
   if (found_file < 0 && solib_absolute_prefix == NULL)
@@ -224,6 +249,7 @@ solib_open (char *in_pathname, char **fo
 static int
 solib_map_sections (void *arg)
 {
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
   struct so_list *so = (struct so_list *) arg;	/* catch_errors bogon */
   char *filename;
   char *scratch_pathname;
@@ -274,14 +300,13 @@ solib_map_sections (void *arg)
 
   for (p = so->sections; p < so->sections_end; p++)
     {
-      /* Relocate the section binding addresses as recorded in the shared
-         object's file by the base address to which the object was actually
-         mapped. */
-      TARGET_SO_RELOCATE_SECTION_ADDRESSES (so, p);
+      /* Relocate the section binding addresses as recorded in the
+         shared object's file by the base address to which the object
+         was actually mapped.  */
+      if (ops->relocate_section_addresses)
+	ops->relocate_section_addresses (so, p);
       if (strcmp (p->the_bfd_section->name, ".text") == 0)
-	{
-	  so->textsection = p;
-	}
+	so->textsection = p;
     }
 
   /* Free the file names, close the file now.  */
@@ -314,6 +339,7 @@ solib_map_sections (void *arg)
 void
 free_so (struct so_list *so)
 {
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
   char *bfd_filename = 0;
 
   if (so->sections)
@@ -330,7 +356,8 @@ free_so (struct so_list *so)
   if (bfd_filename)
     xfree (bfd_filename);
 
-  TARGET_SO_FREE_SO (so);
+  if (ops->free_so)
+    ops->free_so (so);
 
   xfree (so);
 }
@@ -402,15 +429,18 @@ symbol_add_stub (void *arg)
 static void
 update_solib_list (int from_tty, struct target_ops *target)
 {
-  struct so_list *inferior = TARGET_SO_CURRENT_SOS ();
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
+  struct so_list *inferior = NULL;
   struct so_list *gdb, **gdb_link;
 
+  if (ops->current_sos)
+    inferior = ops->current_sos ();
+
   /* 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!  */
-  if (attach_flag &&
-      symfile_objfile == NULL)
-    catch_errors (TARGET_SO_OPEN_SYMBOL_FILE_OBJECT, &from_tty, 
+  if (attach_flag && symfile_objfile == NULL && ops->open_symbol_file_object)
+    catch_errors (ops->open_symbol_file_object, &from_tty, 
 		  "Error reading attached process's symbol file.\n",
 		  RETURN_MASK_ALL);
 
@@ -561,6 +591,7 @@ update_solib_list (int from_tty, struct 
 void
 solib_add (char *pattern, int from_tty, struct target_ops *target, int readsyms)
 {
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
   struct so_list *gdb;
 
   if (pattern)
@@ -617,7 +648,8 @@ solib_add (char *pattern, int from_tty, 
 	   frameless.  */
 	reinit_frame_cache ();
 
-	TARGET_SO_SPECIAL_SYMBOL_HANDLING ();
+	if (ops->special_symbol_handling)
+	  ops->special_symbol_handling ();
       }
   }
 }
@@ -738,6 +770,8 @@ solib_address (CORE_ADDR address)
 void
 clear_solib (void)
 {
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
+
   /* This function is expected to handle ELF shared libraries.  It is
      also used on Solaris, which can run either ELF or a.out binaries
      (for compatibility with SunOS 4), both of which can use shared
@@ -771,7 +805,8 @@ clear_solib (void)
       free_so (so);
     }
 
-  TARGET_SO_CLEAR_SOLIB ();
+  if (ops->clear_solib)
+    ops->clear_solib ();
 }
 
 static void
@@ -799,7 +834,10 @@ do_clear_solib (void *dummy)
 void
 solib_create_inferior_hook (void)
 {
-  TARGET_SO_SOLIB_CREATE_INFERIOR_HOOK ();
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
+
+  if (ops->solib_create_inferior_hook)
+    ops->solib_create_inferior_hook ();
 }
 
 /* GLOBAL FUNCTION
@@ -821,7 +859,12 @@ solib_create_inferior_hook (void)
 int
 in_solib_dynsym_resolve_code (CORE_ADDR pc)
 {
-  return TARGET_SO_IN_DYNSYM_RESOLVE_CODE (pc);
+  struct target_so_ops *ops = gdbarch_data (current_gdbarch, solib_data);
+
+  if (ops->in_dynsym_resolve_code)
+    return ops->in_dynsym_resolve_code (pc);
+
+  return 0;
 }
 
 /*
@@ -878,6 +921,8 @@ _initialize_solib (void)
 {
   struct cmd_list_element *c;
 
+  solib_data = gdbarch_data_register_pre_init (solib_init);
+
   add_com ("sharedlibrary", class_files, sharedlibrary_command,
 	   "Load shared object library symbols for files matching REGEXP.");
   add_info ("sharedlibrary", info_sharedlibrary_command,
Index: solist.h
===================================================================
RCS file: /cvs/src/src/gdb/solist.h,v
retrieving revision 1.9
diff -u -p -r1.9 solist.h
--- solist.h 11 Mar 2004 17:04:40 -0000 1.9
+++ solist.h 15 Nov 2004 23:26:54 -0000
@@ -119,20 +119,4 @@ extern int solib_open (char *in_pathname
 /* FIXME: gdbarch needs to control this variable */
 extern struct target_so_ops *current_target_so_ops;
 
-#define TARGET_SO_RELOCATE_SECTION_ADDRESSES \
-  (current_target_so_ops->relocate_section_addresses)
-#define TARGET_SO_FREE_SO (current_target_so_ops->free_so)
-#define TARGET_SO_CLEAR_SOLIB (current_target_so_ops->clear_solib)
-#define TARGET_SO_SOLIB_CREATE_INFERIOR_HOOK \
-  (current_target_so_ops->solib_create_inferior_hook)
-#define TARGET_SO_SPECIAL_SYMBOL_HANDLING \
-  (current_target_so_ops->special_symbol_handling)
-#define TARGET_SO_CURRENT_SOS (current_target_so_ops->current_sos)
-#define TARGET_SO_OPEN_SYMBOL_FILE_OBJECT \
-  (current_target_so_ops->open_symbol_file_object)
-#define TARGET_SO_IN_DYNSYM_RESOLVE_CODE \
-  (current_target_so_ops->in_dynsym_resolve_code)
-#define TARGET_SO_FIND_AND_OPEN_SOLIB \
-  (current_target_so_ops->find_and_open_solib)
-
 #endif

Re: Assume solib.h

[Eli Zaretskii]

> Date: Mon, 15 Nov 2004 14:32:17 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> Would the addition of the attached file (solib-null.c) to Andrew's patch
> address your concerns?

Anything that prevents breaking of ports that currently work without
solib will address my concerns.

However, I admit that the intricacies of shared library support in GDB
is not something I consider myself an expert in, so Mark would be a
better person to answer this.

Re: Assume solib.h

[Andrew Cagney]

> I'm with Mark on this one: a patch that potentially breaks a supported
> platform doesn't get my vote.  If a platform is supported, it deserves
> that we don't break it, and calling it ``marginal'' doesn't change
> anything.

Eli, can you perhaphs explain what exactly you mean by "supported", how 
the GNU project benefits by expending already limited resources on 
continually fixing vax-ultrix - a non GNU system, and how my change 
breaks it?

Andrew

Re: Assume solib.h

[Daniel Jacobowitz]

On Mon, Nov 15, 2004 at 06:59:07PM -0500, Andrew Cagney wrote:
> 
> >I'm with Mark on this one: a patch that potentially breaks a supported
> >platform doesn't get my vote.  If a platform is supported, it deserves
> >that we don't break it, and calling it ``marginal'' doesn't change
> >anything.
> 
> Eli, can you perhaphs explain what exactly you mean by "supported", how 
> the GNU project benefits by expending already limited resources on 
> continually fixing vax-ultrix - a non GNU system, and how my change 
> breaks it?

Mark wrote:

>please don't check in something like this without testing                                              
>this on some sort of embedded target, vax-dec-openbsd* or                                              
>vax-dec-ultrix4*.                                                                                      

Vax is by no means an embedded target, so I think his meaning is fairly
clear - it's a sample target on which GDB does not support shared
libraries.  Please don't try to change the subject by fixating on the
Vax.

Could you explain what _you_ mean by supported?  My interpretation is
that a platform on which GDB works, deliberately by included code
rather than accidentally through support for some other platform, is
obviously "supported".  We've gone to some effort to add the support
and breaking it is a disservice to our users.

-- 
Daniel Jacobowitz

Re: Assume solib.h

[Eli Zaretskii]

> Date: Mon, 15 Nov 2004 18:59:07 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: mark.kettenis@xs4all.nl, joseph@codesourcery.com, kevinb@redhat.com,
>         gdb-patches@sources.redhat.com
> 
> 
> > I'm with Mark on this one: a patch that potentially breaks a supported
> > platform doesn't get my vote.  If a platform is supported, it deserves
> > that we don't break it, and calling it ``marginal'' doesn't change
> > anything.
> 
> Eli, can you perhaphs explain what exactly you mean by "supported"

Like Daniel, I consider "supported" any target for which GDB builds
and works, and which is not declared deprecated.

> how the GNU project benefits by expending already limited resources
> on continually fixing vax-ultrix - a non GNU system

The same way it benefits by expending already limited resources on
fixing other targets--by being useful to our users.

> and how my change breaks it?

This part I don't know the details about.  Mark said that it does
break, and I spoke on the assumption that you agree with the fact of
breakage, but don't consider it important.

Re: Assume solib.h

[Mark Kettenis]

   Date: Tue, 16 Nov 2004 06:57:57 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Mon, 15 Nov 2004 18:59:07 -0500
   > From: Andrew Cagney <cagney@gnu.org>
   > Cc: mark.kettenis@xs4all.nl, joseph@codesourcery.com, kevinb@redhat.com,
   >         gdb-patches@sources.redhat.com
   > 
   > 
   > > I'm with Mark on this one: a patch that potentially breaks a supported
   > > platform doesn't get my vote.  If a platform is supported, it deserves
   > > that we don't break it, and calling it ``marginal'' doesn't change
   > > anything.
   > 
   > Eli, can you perhaphs explain what exactly you mean by "supported"

   Like Daniel, I consider "supported" any target for which GDB builds
   and works, and which is not declared deprecated.

Hmm, personally I think that's a bit too broad.  I consider a system
"supported" if there is someone who is more or less actively tracking
GDB development, making sure that GDB keeps working on a particular
target.

   > how the GNU project benefits by expending already limited resources
   > on continually fixing vax-ultrix - a non GNU system

   The same way it benefits by expending already limited resources on
   fixing other targets--by being useful to our users.

I can't say with a straight face that vax-ultrix will be very useful
to our more than a few user; there aren't many VAXen left running
ULTRIX I suppose.  I "support" vax-ultrix since it was fun to do.  But
I think it serves the higher purpose of keeping us honest about the
variety of systems out there.  Since it is an up to date target it
doesn't take much resources.

Keeping support for targets without shared libraries alive just for
vax-ultrix wouldn't make sense.  But it certainly isn't the only
target out there without shared libs.

Mark

Re: Assume solib.h

[Eli Zaretskii]

> Date: Tue, 16 Nov 2004 09:36:56 +0100 (CET)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: cagney@gnu.org, gdb-patches@sources.redhat.com
> 
>    Like Daniel, I consider "supported" any target for which GDB builds
>    and works, and which is not declared deprecated.
> 
> Hmm, personally I think that's a bit too broad.  I consider a system
> "supported" if there is someone who is more or less actively tracking
> GDB development, making sure that GDB keeps working on a particular
> target.

That's the same thing in different words: if a target is not actively
maintained, it will bitrot and stop building after a very short time.

Re: Assume solib.h

[Andrew Cagney]

>>and how my change breaks it?
> 
> 
> This part I don't know the details about.  Mark said that it does
> break, and I spoke on the assumption that you agree with the fact of
> breakage,

Unfortunatly your assumption is wrong.  As I stated to Mark, and 
contrary to his assertion, powerpc-elf passes this sniff test:

$ gcc -g -static src/gdb/testsuite/gdb.base/break{,1}.c
cagney@to-dhcp51$ ./X-powerpc-elf/gdb/gdb ./a.out
warning: A handler for the OS ABI "GNU/Linux" is not built into this 
configuration
of GDB.  Attempting to continue with the default powerpc:common settings.
(gdb) target sim
Connected to the simulator.
(gdb) load
(gdb) run
Starting program: /home/scratch/PENDING/YYYY-MM-DD-solib/a.out
do_call() unimplemented call settimeofday
(gdb) disassemble
No frame selected.
<oops>
(gdb) x/i $pc
0x10008a10 <uname+4>:   sc

 >  but don't consider it important.

The mind boggles, if the facts aren't important, what is?

Andrew

Re: Assume solib.h

[Mark Kettenis]

   Date: Tue, 16 Nov 2004 11:13:54 -0500
   From: Andrew Cagney <cagney@gnu.org>

   >>and how my change breaks it?
   > 
   > 
   > This part I don't know the details about.  Mark said that it does
   > break, and I spoke on the assumption that you agree with the fact of
   > breakage,

   Unfortunatly your assumption is wrong.  As I stated to Mark, and 
   contrary to his assertion, powerpc-elf passes this sniff test:

   $ gcc -g -static src/gdb/testsuite/gdb.base/break{,1}.c
   cagney@to-dhcp51$ ./X-powerpc-elf/gdb/gdb ./a.out
   warning: A handler for the OS ABI "GNU/Linux" is not built into this 
   configuration
   of GDB.  Attempting to continue with the default powerpc:common settings.
   (gdb) target sim
   Connected to the simulator.
   (gdb) load
   (gdb) run
   Starting program: /home/scratch/PENDING/YYYY-MM-DD-solib/a.out
   do_call() unimplemented call settimeofday
   (gdb) disassemble
   No frame selected.
   <oops>
   (gdb) x/i $pc
   0x10008a10 <uname+4>:   sc

Yup, I'm wrong.  Not *every* embedded target will break.  Some of them
include solib-svr4.o or some other solib-xxx.o; powerpc-elf is one of
them.  I'm also wrong that it breaks vax-dec-openbsd* for pretty much
the same reason.  However, there are plenty of embedded targets for
which I'm pretty certain that my analysis is true: arm-elf, mips-elf,
i386-elf are among them.

Mark

Re: Assume solib.h

[Andrew Cagney]

> Yup, I'm wrong.  Not *every* embedded target will break.  Some of them
> include solib-svr4.o or some other solib-xxx.o; powerpc-elf is one of
> them.  I'm also wrong that it breaks vax-dec-openbsd* for pretty much
> the same reason.  However, there are plenty of embedded targets for
> which I'm pretty certain that my analysis is true: arm-elf, mips-elf,
> i386-elf are among them.

I'm not.  Can you test my, or kevin's patch?  The're pretty much equivalent.

Andrew

Re: Assume solib.h

[Mark Kettenis]

   Date: Thu, 18 Nov 2004 09:09:43 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > Yup, I'm wrong.  Not *every* embedded target will break.  Some of them
   > include solib-svr4.o or some other solib-xxx.o; powerpc-elf is one of
   > them.  I'm also wrong that it breaks vax-dec-openbsd* for pretty much
   > the same reason.  However, there are plenty of embedded targets for
   > which I'm pretty certain that my analysis is true: arm-elf, mips-elf,
   > i386-elf are among them.

   I'm not.  Can you test my, or kevin's patch?  The're pretty much equivalent.

How can you say that they're equivalent Andrew?  That doesn't make any
sense.  Kevin's patch fixes what your patch breaks: all targets that
currently don't include any shared library support.

But let's end this discussion.  Kevin, can you check in the patch in

   http://sources.redhat.com/ml/gdb-patches/2004-11/msg00316.html

After that anyone who cares can followup on Andrew's suggestion in

   http://sources.redhat.com/ml/gdb-patches/2004-11/msg00239.html

I might even do the legwork that's needed.

Mark

Re: Assume solib.h

[Kevin Buettner]

On Thu, 18 Nov 2004 15:36:37 +0100 (CET)
Mark Kettenis <kettenis@gnu.org> wrote:

> But let's end this discussion.  Kevin, can you check in the patch in
> 
>    http://sources.redhat.com/ml/gdb-patches/2004-11/msg00316.html

Done.

I haven't checked in the required changes to Makefile yet.  They require
Andrew's patch which started this thread.

Andrew, please check in that patch which started this thread.  If you
wish, you can also check in the obvious Makefile changes regarding
solib-null.[co].  Or, if you prefer, just let me know when it's in,
and I'll take care of it.

Kevin

Re: Assume solib.h

[Andrew Cagney]

>    Date: Thu, 18 Nov 2004 09:09:43 -0500
>    From: Andrew Cagney <cagney@gnu.org>
>    Mark wrote:
>    > Yup, I'm wrong.  Not *every* embedded target will break.  Some of them
>    > include solib-svr4.o or some other solib-xxx.o; powerpc-elf is one of
>    > them.  I'm also wrong that it breaks vax-dec-openbsd* for pretty much
>    > the same reason.  However, there are plenty of embedded targets for
>    > which I'm pretty certain that my analysis is true: arm-elf, mips-elf,
>    > i386-elf are among them.
> 
>    I'm not.

This is for mips-elf:

cagney@to-dhcp51$ ./gdb /tmp/a.out
GNU gdb 6.3.50_2004-11-01-cvs
...
(gdb) b main
Breakpoint 1 at 0xa00202b0: file hello.c, line 5.
(gdb) target sim
Connected to the simulator.
(gdb) load
...
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, main () at hello.c:5
5       hello.c: No such file or directory.
         in hello.c

sigh,

Joseph,

Given that no one has raised a concern over my original point that it 
would break _AIX_ and _HPUX_ (the latter doesn't build anyway) (perhaps 
this key point was lost in the noise), and given that Kevin's also given 
his approval, you're finally clear to throw the switch and assume solib.

Kevin's dummy solib simplifies things slightly.   I think the real patch 
will just need to add #include "solib.h" where needed, and remove all 
the existing *.tm:DEPRECATED_TM_FILE=solib.h and {tm,nm}-*.h:#include 
"solib.h".  I'd also test it on a GNU/Linux system.

Have fun, and thank you for your patience.  (Hmm, what's left, if 
Solaris is useable, it's time to add a NEWS entry!)

Andrew

Re: Assume solib.h

[Randolph Chung]

Andrew,

> Given that no one has raised a concern over my original point that it 
> would break _AIX_ and _HPUX_ (the latter doesn't build anyway) (perhaps 
> this key point was lost in the noise), and given that Kevin's also given 
> his approval, you're finally clear to throw the switch and assume solib.

I *have* raised a concern about breaking HPUX:
    http://sources.redhat.com/ml/gdb-patches/2004-11/msg00259.html

HPUX was building fine until the very recent removal of 
deprecated_registers (for which i have a patch that is being tested at 
the moment). MichaelC posts test results for hpux somewhat regularly...
while the results are not fantastic, it is still working for people who
use it.....

We can discuss changes required to fix the hpux target, but let's not
assume that hpux support will be gone in the next release (which is
what's currently in the NEWS file...)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: Assume solib.h

[Joel Brobecker]

> We can discuss changes required to fix the hpux target, but let's not
> assume that hpux support will be gone in the next release (which is
> what's currently in the NEWS file...)

Don't worry about HP/UX. I'll fix the breakage, I just haven't had
time to work on it this week. I started with mips-irix, and wanted
to continue with HP/UX, but just didn't have the time.

-- 
Joel

Re: Assume solib.h

[Randolph Chung]

In reference to a message from Joel Brobecker, dated Nov 19:
> > We can discuss changes required to fix the hpux target, but let's not
> > assume that hpux support will be gone in the next release (which is
> > what's currently in the NEWS file...)
> 
> Don't worry about HP/UX. I'll fix the breakage, I just haven't had
> time to work on it this week. I started with mips-irix, and wanted
> to continue with HP/UX, but just didn't have the time.

I have a patch from Dave Anglin for deprecated_registers, so if you want
to work on hpux please fix solib instead? ;-)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: Assume solib.h

[Joel Brobecker]

> I have a patch from Dave Anglin for deprecated_registers, so if you want
> to work on hpux please fix solib instead? ;-)

This is tougher for me to promise this because I don't know how much
work is involved. I have seldom looked at this area of the code before...
I promised a lot of things in this list, all in good faith, and ended
up being able to deliver just a tiny fraction of it.

-- 
Joel

Re: Assume solib.h

[Joseph S. Myers]

On Fri, 19 Nov 2004, Andrew Cagney wrote:

> Have fun, and thank you for your patience.  (Hmm, what's left, if Solaris is
> useable, it's time to add a NEWS entry!)

The AMD64 Solaris 10 port is already working reasonably without needing 
any solib changes (modulo Solaris kernel bugs), though there are some test 
failures I have yet to investigate to see whether they are GDB or Solaris 
bugs.  Of course I'll update the port as required by future changes in GDB 
that require it to be updated (as opposed to changes requiring only the 
x86 Solaris <= 9 port - which I can't test - to be updated).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Assume solib.h

[Eli Zaretskii]

> Date: Tue, 16 Nov 2004 11:13:54 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: mark.kettenis@xs4all.nl, joseph@codesourcery.com, kevinb@redhat.com,
>         gdb-patches@sources.redhat.com
> 
> 
> >>and how my change breaks it?
> > 
> > 
> > This part I don't know the details about.  Mark said that it does
> > break, and I spoke on the assumption that you agree with the fact of
> > breakage,
> 
> Unfortunatly your assumption is wrong.

I wrote that before this was established.

> As I stated to Mark, and 
> contrary to his assertion, powerpc-elf passes this sniff test:

The discussion would have stayed more technical and calm if, instead
of elevating it to a principle to which some of us disagree, you'd
show the facts and tried to convince.

>  >  but don't consider it important.
> 
> The mind boggles, if the facts aren't important, what is?

I think you simply misunderstood what I wrote.

Re: Assume solib.h

[Andrew Cagney]

Eli Zaretskii wrote:
>>Date: Tue, 16 Nov 2004 11:13:54 -0500
>>From: Andrew Cagney <cagney@gnu.org>
>>Cc: mark.kettenis@xs4all.nl, joseph@codesourcery.com, kevinb@redhat.com,
>>        gdb-patches@sources.redhat.com
>>
>>
>>
>>>>and how my change breaks it?
>>>
>>>
>>>This part I don't know the details about.  Mark said that it does
>>>break, and I spoke on the assumption that you agree with the fact of
>>>breakage,
>>
>>Unfortunatly your assumption is wrong.
> 
> 
> I wrote that before this was established.

Er,

My opening remark stated:

> It means breaking non solib.[hc] shared library systems.  Kevin indicated that there were two - AIX and HP/UX remaining.  I think we can live with that - we've patiently waited for what, more than two years for nothing to happen, so it is now time to give things that gentle push.

and then in my immediate reply to mark I stated:

> I gave it a full test with PowerPC GNU/Linux and sniff test with powerpc-elf.  If there are other problems, I'm sure they'll be sorted out. 

and that was followed by:

 > Really!  Please look again at the proposal.

So how well established my assertion is depends on who you'd prefer to 
believe.

(your e-mail was several responses later)

Andrew

Re: Assume solib.h

[Eli Zaretskii]

> Date: Tue, 16 Nov 2004 17:27:17 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: mark.kettenis@xs4all.nl, joseph@codesourcery.com, kevinb@redhat.com,
>         gdb-patches@sources.redhat.com
> 
> So how well established my assertion is depends on who you'd prefer to 
> believe.

Please re-read the text that I cited in my response, and you will see
that I was reacting to an entirely different part of your and Mark's
exchange.

Anyway, I don't understand what is your point.  In another message in
this thread you were complaining about the futility of the discussion,
and yet you yourself start futile sub-threads that have nothing to do
with the issue at hand.

Re: Assume solib.h

[Daniel Jacobowitz]

On Fri, Nov 12, 2004 at 10:51:07AM -0500, Andrew Cagney wrote:
> My change allows Code Sorcery to achieve their goal of getting Solaris 
> 10 support in GDB, while at the same time allow us to move forward with 
> our objective of improving support for GNU, GNU/Linux and even the other 
> mainstream Free and non-Free platform support.
> 
> We win - Code Sorcery Wins; we have a symbiotic relationship.

First of all, the name of my and Joseph's employer is CodeSourcery. 
The rest of this message is written as a GDB developer, not an
employee.

> On the other hand, by effectively requiring that a contributor must 
> first test/fix a change on marginal if not irrelevant systems such as 
> vax-dec-ultrix4 (the suggestion also carried other less pleasant 
> undertones), can only stall the host's (GDB's) development.  Isn't that 
> called a parasitic relationship?

And you're complaining about Mark's tone?  Please make a passing
effort to be polite.

By requiring contributors to make an architectural change to GDB -
which so far I've seen at least three GDB global maintainers take a
stab at and none finish - you are making GDB more difficult to
contribute to.  This has the effect of driving away contributions,
which isn't any kind of relationship at all.

The timing of deprecating the TM_FILE mechanism was never discussed; it
got lost in your argument with Eli about xm-go32.h.  I apologize for
not loudly objecting at the time; I was making an obviously futile
effort to stay out of an increasingly unpleasant argument.  The tone
of the GDB development lists has gotten steadily worse over the last
year.

I think that deprecating this mechanism with so many unfinished
questions on how to do without it was premature.  The next person to
attempt to contribute a solib-using port obviously got stuck with the
entire mess.

I'll refer to Eli's message:
  http://sources.redhat.com/ml/gdb-patches/2004-09/msg00151.html
The exact same problems apply to TM_FILE.



Separately, the other issue in the above.

Thousands of people use GDB on embedded targets that, Mark said, would
be broken by the patch you posted - targets which do not normally use
shared libraries.  I think it was entirely reasonable of him to insist
that you address his concern before proceeding with surgery on the
solib mechanism.

-- 
Daniel Jacobowitz

Re: Assume solib.h

[Eli Zaretskii]

> Date: Mon, 15 Nov 2004 20:40:27 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, joseph@codesourcery.com,
> 	kevinb@redhat.com, gdb-patches@sources.redhat.com
> 
> The timing of deprecating the TM_FILE mechanism was never discussed; it
> got lost in your argument with Eli about xm-go32.h.  I apologize for
> not loudly objecting at the time; I was making an obviously futile
> effort to stay out of an increasingly unpleasant argument.  The tone
> of the GDB development lists has gotten steadily worse over the last
> year.

I agree with the lament about the tone, and FWIW, I'm sorry for any
contribution I could have made, albeit inadvertently, to things
getting worse lately.  Unfortunately, it seems like there's no other
way to disagree with Andrew on matters of principle without getting
into an unpleasant dispute.  The only alternative seems to be to shut
up, which I'm not prepared to do, since silence is taken as a sign of
agreement.

Re: Assume solib.h

[Andrew Cagney]

> By requiring contributors to make an architectural change to GDB -
> which so far I've seen at least three GDB global maintainers take a
> stab at and none finish - you are making GDB more difficult to
> contribute to.  This has the effect of driving away contributions,
> which isn't any kind of relationship at all.

Sorry, but contrary to your assertion, it is trivial.

My and/or Kevin's patch did all that is required - throw the switch and 
include solib.[ch].  Nothing technically challenging here, and certainly 
nothing unreasonable for a contributor.  Especially when there's a core 
developer helping with the change.

It could by now have even been committed, if only we'd not been dragged 
down this rat-hole where people start insisting that it has to be tested 
on old crufty systems that likely don't even build.  If you want drive 
away native GNU and GNU/Linux developers from what is ment to be a GNU 
project, tell them to fix vax-ultrix.

Andrew

Re: Assume solib.h

[Mark Kettenis]

   Date: Tue, 16 Nov 2004 11:30:59 -0500
   From: Andrew Cagney <cagney@gnu.org>

   It could by now have even been committed, if only we'd not been dragged 
   down this rat-hole where people start insisting that it has to be tested 
   on old crufty systems that likely don't even build.  If you want drive 
   away native GNU and GNU/Linux developers from what is ment to be a GNU 
   project, tell them to fix vax-ultrix.

To set this straight: vax-ultrix is an old crufty system that *does*
build.  But can we please leave vax-ultrix out of this discussion.  As
soon as it really hampers progress, I'll happily scrap it.

While I recognize that GDB's primary target is GNU/Linux, moving into
the direction of GDB as a GNU-only debugger is a bad idea.  As I've
stated before, support for other systems makes us take the right
design issues.  But what's more important, by turning GDB into a
GNU-only debugger you'll probably loose some of the few active
contributors that we have left.

Mark

Re: Assume solib.h

[Eli Zaretskii]

> Date: Tue, 16 Nov 2004 11:30:59 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Mark Kettenis <mark.kettenis@xs4all.nl>, joseph@codesourcery.com,
>         kevinb@redhat.com, gdb-patches@sources.redhat.com
> 
> It could by now have even been committed, if only we'd not been dragged 
> down this rat-hole where people start insisting that it has to be tested 
> on old crufty systems that likely don't even build.  If you want drive 
> away native GNU and GNU/Linux developers from what is ment to be a GNU 
> project, tell them to fix vax-ultrix.

If you think the affected systems are ``crufty'' and ``old'', please
suggest to declare them deprecated, and let's see if we can reach a
consensus on that.  That's our way of saying that a system is ``old
and crufty''.

Re: Assume solib.h

[Randolph Chung]

> There's just one non-technical nit.
> 
> It means breaking non solib.[hc] shared library systems.  Kevin 
> indicated that there were two - AIX and HP/UX remaining.  I think we can 
> live with that - we've patiently waited for what, more than two years 
> for nothing to happen, so it is now time to give things that gentle pus

I'm not prepared to sign up for hpux support, but can you explain some
more what will break and what is needed to fix it? Despite the lack of
maintainence, there are still a good number of people out there using
gdb on hpux (judging by private mail I've received since I started 
working on hppa-linux support)....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: Assume solib.h

[Andrew Cagney]

Randolph Chung wrote:
>>There's just one non-technical nit.
>>
>>It means breaking non solib.[hc] shared library systems.  Kevin 
>>indicated that there were two - AIX and HP/UX remaining.  I think we can 
>>live with that - we've patiently waited for what, more than two years 
>>for nothing to happen, so it is now time to give things that gentle pus
> 
> 
> I'm not prepared to sign up for hpux support, but can you explain some
> more what will break and what is needed to fix it? Despite the lack of
> maintainence, there are still a good number of people out there using
> gdb on hpux (judging by private mail I've received since I started 
> working on hppa-linux support)....

Have a look at solist.h which contains:

> struct target_so_ops
>   {
>     /* Adjust the section binding addresses by the base address at
>        which the object was actually mapped.  */
>     void (*relocate_section_addresses) (struct so_list *so,
>                                         struct section_table *);
...

it just needs to implement that object (see solib-svr4.c).  Without it, 
shared libraries wouldn't work but everything else should.

We need to find a way of flushing some of these people still using GDB 
on HP/UX (or are they using HP's WDB fork?) and, unfortunate as it is, 
push-come-to-shove is one of the most effective ways of doing this.

Anyway, HP/UX has a more immediate problem - it's still using 
deprecated_registers[] and that's now past its end-of-life :-/

Andrew