[0/8] solib handler rework

[0/8] solib handler rework

[Ulrich Weigand]

Hello,

one of the last remaining obstacles to enabling supporting multiple
targets at the same time the current_target_so_ops global variable.
Each variant of shared library handler currently set that variable
in its initialization function, making it impossible to link more
than one shared library handler into a single GDB binary.

This series of patches fixes this problem by moving selection of
the proper shared library handler to the target architecture; the
approriate gdbarch init function will call set_solib_ops.

One twist is that some solib handlers cannot even be compiled 
except on the native configuration, because they make use of
platform specific header files or libraries.  This patch series
does not fix this problem, but at least stops it hurting other
platforms.  After the patch series is applied, there are two
classes of solib handlers:

- Native-only solib: File is compiled and linked only in native
  configurations (via NATDEPFILES), it installs itself via the
  global current_target_so_ops, and there are no references from
  any tdep file to the solib file.

- Cross-platform solib: File can be compiled and linked on an
  arbitrary host platform; it *is* compiled and linked on both
  cross and native configurations (via TDEPFILES), it does *not*
  touch current_target_so_ops.  There *may* be references from
  tdep files (for the same configuration) to the solib file.


This implies that any cross-debugger configuration will be able
to debug shared libraries correctly, as long as the target system
uses a cross-platform solib.  In the future, it will be possible
to build multi-target configurations that support multiple
different solib handlers simultaneously.


After the patch series is applied, the only remaining native-only
solib handlers will in fact be solib-sunos and solib-osf.  Those
could probably converted to cross-platform handlers as well, by
removing dependencies on native header files.  I'll leave that
part to someone who has access to those platforms ...


The whole series was tested on s390-linux, s390x-linux, powerpc-
linux, i386-linux, and ia64-linux.   Tests on other affected
platforms would be welcome: alpha-linux, arm-wince, arm-linux,
i386-gnu, i386-cygwin, i386-nto, m32r-linux, hppa-hpux (32-bit
and 64-bit), mips-irix, and frv.

OK to apply to mainline?

Bye,
Ulrich
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Joel Brobecker]

Hello Ulrich,

> Tests on other affected platforms would be welcome: alpha-linux,
> arm-wince, arm-linux, i386-gnu, i386-cygwin, i386-nto, m32r-linux,
> hppa-hpux (32-bit and 64-bit), mips-irix, and frv.

I tested on hppa-hpux (32-bit only, I don't have a 64-bit compiler),
and on mips-irix. The good news is that testing on mips-irix showed
no change. The other good news is that I saw no regression on hppa-hpux
as well. But there was a glitch: solib-pa64.c builds fine, but then
I have unresolved symbol issues:

/usr/ccs/bin/ld: Unsatisfied symbols:
   dlgetmodinfo (first referenced in libgdb.a(solib-pa64.o)) (code)
   dlgetname (first referenced in libgdb.a(solib-pa64.o)) (code)

This wasn't happening before simply because this entire file was
ifdef'ed out when building 32-bit GDB. Why was it included in the first
place if it was going to be ifdef'ed out?

Looking at the HP documentation, it looks like this symbol should be
provided by -ldl (see http://docs.hp.com/en/B9106-90010/dlgetname.3C.html)
but in fact, neither on HPUX 11.00 and 11.11 seems to provide libdl.
On the other hand, I found these symbols inside libxpdl.sl. So it looks
like we just need to add -lxpdl. I did this manually and that allowed
me to complete the testing of your patch on hpux.

I really wonder if this was actually building on hppa64 before... Looking
at all the makefile fragments, I don't see how.  I'm trying to find
a 64bit GCC somewhere to give it a try.

-- 
Joel

Re: [0/8] solib handler rework

[Joel Brobecker]

> But there was a glitch: solib-pa64.c builds fine, but then
> I have unresolved symbol issues:
> 
> /usr/ccs/bin/ld: Unsatisfied symbols:
>    dlgetmodinfo (first referenced in libgdb.a(solib-pa64.o)) (code)
>    dlgetname (first referenced in libgdb.a(solib-pa64.o)) (code)

More info on this:

I managed to find an old 64bit GCC-3.2 compiler from HP, and it
allowed me to actually verify to my astonishment that GDB does in
fact build in 64-bit mode. The dependency on libdl is indirect:

  % chatr /lib/pa20_64/libc.2
    [...]
         shared library list:
             libdl.1

I found libdl.1 to be in /usr/lib/pa20_64, and it indeed exports
the symbol that we were missing:

  % nm /usr/lib/pa20_64/libdl.1| grep dlgetname
  4000000000001110 T dlgetname

Whereas, if you inspect the 32bit version:

  % chatr /lib/libc.2
    [...]
         shared library list:
             dynamic   /usr/lib/libdld.2

libdld does not export the symbols that we're missing (or we wouldn't
have our link issue :-). So it looks like adding -lxpdl is only needed
for 32bit builds.

Now, onto testing...
-- 
Joel

Re: [0/8] solib handler rework

[Joel Brobecker]

> Now, onto testing...
[hppa64-hpux]

Testing reveals no regression, but you couldn't break it more than it
already is broken:

   (gdb) start
   Breakpoint 1 at 0x4000000000001218: file foo.c, line 6.
   Starting program: /[...]/foo 
   Error trying to get information about dynamic linker.

(that's before your patch) :-(

-- 
Joel

Re: [0/8] solib handler rework

[Ulrich Weigand]

Joel Brobecker wrote:

> Testing reveals no regression, but you couldn't break it more than it
> already is broken:
> 
>    (gdb) start
>    Breakpoint 1 at 0x4000000000001218: file foo.c, line 6.
>    Starting program: /[...]/foo 
>    Error trying to get information about dynamic linker.
> 
> (that's before your patch) :-(

Huh.  This error message is issued by solib-pa64.c if the initial
dlgetmodinfo call (with index -1) fails.  The docs I can find:
http://docs.hp.com/en/B2355-60127/dlgetmodinfo.3C.html
say you can use dlerrno () to find out more details on that
failure ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Joel Brobecker]

> Huh.

Yeah, my thinking exactly :-).

> This error message is issued by solib-pa64.c if the initial
> dlgetmodinfo call (with index -1) fails.  The docs I can find:
> http://docs.hp.com/en/B2355-60127/dlgetmodinfo.3C.html
> say you can use dlerrno () to find out more details on that
> failure ...

Unfortunately, this function doesn't seem to be defined anywhere
on the systems I have access to. I was doing my testing on 11.00,
but also checked in 11.11 since this is what the man page refers
to. Nor could I find any of the values that the man page says
dlerrno returns.

Just in case, I did check errno, and it returned 22 EINVAL...
Not as useful as what dlerrno would tell us.

I'm going to try to build GDB on 11.11 and see if I get better
results. First, I need to find a compiler...

-- 
Joel

Re: [0/8] solib handler rework

[Joel Brobecker]

> I'm going to try to build GDB on 11.11 and see if I get better
> results. First, I need to find a compiler...

No luck there either...

I propose that we just accept the changes in solib-pa64 since they compile.
The pa64-hpux debugger is pretty broken, so we can't verify them any
further. We should probably document that fact somewhere, maybe in
the NEWS file?

-- 
Joel

Re: [0/8] solib handler rework

[Daniel Jacobowitz]

On Tue, Oct 23, 2007 at 11:38:10PM -0700, Joel Brobecker wrote:
> > I'm going to try to build GDB on 11.11 and see if I get better
> > results. First, I need to find a compiler...
> 
> No luck there either...
> 
> I propose that we just accept the changes in solib-pa64 since they compile.
> The pa64-hpux debugger is pretty broken, so we can't verify them any
> further. We should probably document that fact somewhere, maybe in
> the NEWS file?

Poor outdated PROBLEMS, I suppose.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [0/8] solib handler rework

[Eli Zaretskii]

> Date: Wed, 24 Oct 2007 07:48:22 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> > The pa64-hpux debugger is pretty broken, so we can't verify them any
> > further. We should probably document that fact somewhere, maybe in
> > the NEWS file?
> 
> Poor outdated PROBLEMS, I suppose.

I think we should reserve PROBLEMS for issues for which we can offer a
solution or a workaround.  If we want to say that a port is broken,
that should go into NEWS, like we do with deprecated and deleted
targets.

Re: [0/8] solib handler rework

[Eli Zaretskii]

> Date: Tue, 23 Oct 2007 23:38:10 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> The pa64-hpux debugger is pretty broken, so we can't verify them any
> further. We should probably document that fact somewhere, maybe in
> the NEWS file?

Yes, NEWS would be a good place, IMO.

Re: [0/8] solib handler rework

[Joel Brobecker]

> > The pa64-hpux debugger is pretty broken, so we can't verify them any
> > further. We should probably document that fact somewhere, maybe in
> > the NEWS file?
> 
> Yes, NEWS would be a good place, IMO.

Argh! Our emails crossed, I just posted a patch for PROBLEMS. Which
one would you prefer? Both maybe?

-- 
Joel

Re: [0/8] solib handler rework

[Ulrich Weigand]

Hello Joel,

> I tested on hppa-hpux (32-bit only, I don't have a 64-bit compiler),
> and on mips-irix. The good news is that testing on mips-irix showed
> no change. The other good news is that I saw no regression on hppa-hpux
> as well.

Thanks for testing!

> But there was a glitch: solib-pa64.c builds fine, but then
> I have unresolved symbol issues:
> 
> /usr/ccs/bin/ld: Unsatisfied symbols:
>    dlgetmodinfo (first referenced in libgdb.a(solib-pa64.o)) (code)
>    dlgetname (first referenced in libgdb.a(solib-pa64.o)) (code)

I was afraid something like that might be happening :-(

> This wasn't happening before simply because this entire file was
> ifdef'ed out when building 32-bit GDB. Why was it included in the first
> place if it was going to be ifdef'ed out?

This is all a bit unfortunate.  The problem is that hppa-hpux-tdep.c
contains references to both som_solib_select and pa64_solib_select,
so it needs to be linked against both solib-som.c and solib-pa64.c.

Now, solib-som.c appears to be platform-independent, and can be 
compiled everywhere, at least after the (unused) #include "som.h"
is removed.  However, solib-pa64.c depends crucially on header
files and library routines specific to 64-bit HP/UX, like
dlgetmodinfo.

The original code tried to resolve this in a somewhat weird manner:
both hpux and hpux64 targets would link against both solib-som.c
and solib-pa64.c, but the 32-bit target would define a special
PA_SOM_ONLY macro which prevents the bulk of solib-pa64.c from being
built, with the exception of a stub version of pa64_solib_select.

However, this would still break a multi-target build, and in fact
even any cross-build with hpux64 target, as it only selects the stub
version when building the 32-bit hpux targets.

Thus my patch tried to revert the logic: instead of having a conditional
when *not* to build the real solib-pa64.c, have a conditional that
selects when to *build* the real solib-pa64.c.  And in fact, that
conditional should be automatically computed by the configure process:
we want to build solib-pa64.c whenever its dependencies are present.

The way I attemted to implemented this is via a configure check for
the presence of the <elf_hp.h> header file, which I understand contains
the required structure definitions and prototypes needed by solib-pa64.c

This check did work as expected in my tests on non-HPUX systems,
and apparently it also works as expected in your 64-bit HPUX build.
However, it obviously isn't sufficient for a 32-bit HPUX build.

> Looking at the HP documentation, it looks like this symbol should be
> provided by -ldl (see http://docs.hp.com/en/B9106-90010/dlgetname.3C.html)
> but in fact, neither on HPUX 11.00 and 11.11 seems to provide libdl.
> On the other hand, I found these symbols inside libxpdl.sl. So it looks
> like we just need to add -lxpdl. I did this manually and that allowed
> me to complete the testing of your patch on hpux.

Hmmm, maybe that -lxpdl library is something new that was added to
allow 32-bit x 64-bit cross-debuggers to be implemented?  From the
comments in solib-pa64.c I got the impression that, at least originally,
accessing those routines on a 32-bit host was simply impossible ...

I guess there are two things to consider here:

- What additional test, besides the <elf_hp.h> header check, would
  allow us to distiguish between systems that provide the dlgetmodinfo
  etc routines and those that don't?

- If there is sometimes the need to add a special compatibility 
  library like -lxpdl, we need to add the appropriate configure
  magic to make that happen ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Joel Brobecker]

> Hmmm, maybe that -lxpdl library is something new that was added to
> allow 32-bit x 64-bit cross-debuggers to be implemented?

That is indeed a distinct possibility.

> I guess there are two things to consider here:
> 
> - If there is sometimes the need to add a special compatibility 
>   library like -lxpdl, we need to add the appropriate configure
>   magic to make that happen ...

This is the option that I prefer. I'm not sure that a 32bit GDB
on HP/UX will be able to debug a 64bit program, but at least that's
a step in that direction.

-- 
Joel

Re: [0/8] solib handler rework

[Ulrich Weigand]

Joel Brobecker wrote:

> > - If there is sometimes the need to add a special compatibility 
> >   library like -lxpdl, we need to add the appropriate configure
> >   magic to make that happen ...
> 
> This is the option that I prefer. I'm not sure that a 32bit GDB
> on HP/UX will be able to debug a 64bit program, but at least that's
> a step in that direction.

Something like the configure patch below should do that.
(Should apply on top of the solib patches.)

Bye,
Ulrich


diff -urNp gdb-orig/gdb/configure gdb-head/gdb/configure
--- gdb-orig/gdb/configure	2007-10-19 23:36:41.000000000 +0200
+++ gdb-head/gdb/configure	2007-10-22 20:28:15.532021324 +0200
@@ -5629,6 +5629,134 @@ if test "$ac_cv_search_waddstr" != no; t
 fi
 
 
+# On HP/UX we may need libxpdl for dlgetmodinfo (used by solib-pa64.c).
+echo "$as_me:$LINENO: checking for library containing dlgetmodinfo" >&5
+echo $ECHO_N "checking for library containing dlgetmodinfo... $ECHO_C" >&6
+if test "${ac_cv_search_dlgetmodinfo+set}" = set; then
+  echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+  ac_func_search_save_LIBS=$LIBS
+ac_cv_search_dlgetmodinfo=no
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char dlgetmodinfo ();
+int
+main ()
+{
+dlgetmodinfo ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_search_dlgetmodinfo="none required"
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+if test "$ac_cv_search_dlgetmodinfo" = no; then
+  for ac_lib in dl xpdl; do
+    LIBS="-l$ac_lib  $ac_func_search_save_LIBS"
+    cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h.  */
+
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern "C"
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char dlgetmodinfo ();
+int
+main ()
+{
+dlgetmodinfo ();
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
+  (eval $ac_link) 2>conftest.er1
+  ac_status=$?
+  grep -v '^ *+' conftest.er1 >conftest.err
+  rm -f conftest.er1
+  cat conftest.err >&5
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); } &&
+	 { ac_try='test -z "$ac_c_werror_flag"
+			 || test ! -s conftest.err'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; } &&
+	 { ac_try='test -s conftest$ac_exeext'
+  { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+  (eval $ac_try) 2>&5
+  ac_status=$?
+  echo "$as_me:$LINENO: \$? = $ac_status" >&5
+  (exit $ac_status); }; }; then
+  ac_cv_search_dlgetmodinfo="-l$ac_lib"
+break
+else
+  echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext \
+      conftest$ac_exeext conftest.$ac_ext
+  done
+fi
+LIBS=$ac_func_search_save_LIBS
+fi
+echo "$as_me:$LINENO: result: $ac_cv_search_dlgetmodinfo" >&5
+echo "${ECHO_T}$ac_cv_search_dlgetmodinfo" >&6
+if test "$ac_cv_search_dlgetmodinfo" != no; then
+  test "$ac_cv_search_dlgetmodinfo" = "none required" || LIBS="$ac_cv_search_dlgetmodinfo $LIBS"
+
+fi
+
+
 # Since GDB uses Readline, we need termcap functionality.  In many
 # cases this will be provided by the curses library, but some systems
 # have a seperate termcap library, or no curses library at all.
diff -urNp gdb-orig/gdb/configure.ac gdb-head/gdb/configure.ac
--- gdb-orig/gdb/configure.ac	2007-10-19 23:36:41.000000000 +0200
+++ gdb-head/gdb/configure.ac	2007-10-22 20:28:06.689965572 +0200
@@ -319,6 +319,9 @@ AC_SEARCH_LIBS(socketpair, socket)
 # a situation.
 AC_SEARCH_LIBS(waddstr, [ncurses cursesX curses])
 
+# On HP/UX we may need libxpdl for dlgetmodinfo (used by solib-pa64.c).
+AC_SEARCH_LIBS(dlgetmodinfo, [dl xpdl])
+
 # Since GDB uses Readline, we need termcap functionality.  In many
 # cases this will be provided by the curses library, but some systems
 # have a seperate termcap library, or no curses library at all.


-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Joel Brobecker]

> Something like the configure patch below should do that.
> (Should apply on top of the solib patches.)

Yep, just verified it :).

-- 
Joel

Re: [0/8] solib handler rework

[Ulrich Weigand]

Joel Brobecker wrote:
> > Something like the configure patch below should do that.
> > (Should apply on top of the solib patches.)
> 
> Yep, just verified it :).

Thanks!  I've added this to the patch I've committed.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Pedro Alves]

Ulrich Weigand wrote:

> The whole series was tested on s390-linux, s390x-linux, powerpc-
> linux, i386-linux, and ia64-linux.   Tests on other affected
> platforms would be welcome: alpha-linux, arm-wince, arm-linux,
> i386-gnu, i386-cygwin, i386-nto, m32r-linux, hppa-hpux (32-bit
> and 64-bit), mips-irix, and frv.
>

FYI, I've started the testing on cygwin and arm-wince.  That will
cover solib-target.c
native and remote.

Cheers,
Pedro Alves

Re: [0/8] solib handler rework

[Pedro Alves]

Pedro Alves wrote:
> Ulrich Weigand wrote:
> 
>> The whole series was tested on s390-linux, s390x-linux, powerpc-
>> linux, i386-linux, and ia64-linux.   Tests on other affected
>> platforms would be welcome: alpha-linux, arm-wince, arm-linux,
>> i386-gnu, i386-cygwin, i386-nto, m32r-linux, hppa-hpux (32-bit
>> and 64-bit), mips-irix, and frv.
>>
> 
> FYI, I've started the testing on cygwin and arm-wince.  That will
> cover solib-target.c
> native and remote.
> 

Done.  No changes in both cygwin and arm-wince.

Cheers,
Pedro Alves

Re: [0/8] solib handler rework

[Ulrich Weigand]

> Pedro Alves wrote:
> > Ulrich Weigand wrote:
> > 
> >> The whole series was tested on s390-linux, s390x-linux, powerpc-
> >> linux, i386-linux, and ia64-linux.   Tests on other affected
> >> platforms would be welcome: alpha-linux, arm-wince, arm-linux,
> >> i386-gnu, i386-cygwin, i386-nto, m32r-linux, hppa-hpux (32-bit
> >> and 64-bit), mips-irix, and frv.
> >>
> > 
> > FYI, I've started the testing on cygwin and arm-wince.  That will
> > cover solib-target.c
> > native and remote.
> > 
> 
> Done.  No changes in both cygwin and arm-wince.

Excellent, thanks again for testing!

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Daniel Jacobowitz]

On Fri, Oct 19, 2007 at 11:31:34PM +0200, Ulrich Weigand wrote:
> The whole series was tested on s390-linux, s390x-linux, powerpc-
> linux, i386-linux, and ia64-linux.   Tests on other affected
> platforms would be welcome: alpha-linux, arm-wince, arm-linux,
> i386-gnu, i386-cygwin, i386-nto, m32r-linux, hppa-hpux (32-bit
> and 64-bit), mips-irix, and frv.
> 
> OK to apply to mainline?

I skimmed all of these and they looked fine to me, too.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [0/8] solib handler rework

[Kevin Buettner]

On Fri, 19 Oct 2007 23:31:34 +0200 (CEST)
"Ulrich Weigand" <uweigand@de.ibm.com> wrote:

> OK to apply to mainline?

I've approved parts 1, 2, 7, and 8.  Parts 3-6 look reasonable too,
but I'm not as familiar with the files that these patches touch, and
so will leave it up to others to comment on these portions.  If
everyone's concerns with those portions have been addressed, you can
consider them approved too.

Kevin

Re: [0/8] solib handler rework

[Ulrich Weigand]

Kevin Buettner wrote:
> On Fri, 19 Oct 2007 23:31:34 +0200 (CEST)
> "Ulrich Weigand" <uweigand@de.ibm.com> wrote:
> 
> > OK to apply to mainline?
> 
> I've approved parts 1, 2, 7, and 8.  Parts 3-6 look reasonable too,
> but I'm not as familiar with the files that these patches touch, and
> so will leave it up to others to comment on these portions.  If
> everyone's concerns with those portions have been addressed, you can
> consider them approved too.

Here's the status of parts 3-6:

3: Joel tested on hpux and found a configure issue.  He verified that
   an updated version of the patch works fine.
4: Joel tested on mips-irix without problems.
5: Pedro tested on cygwin and arm-wince without problems.
6: No comments received.  However, since i386-nto-tdep.c didn't even
   compile before my changes, I didn't think I would ...

Therefore, I've now checked all parts in.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [0/8] solib handler rework

[Mark Kettenis]

> Date: Wed, 24 Oct 2007 23:29:54 +0200 (CEST)
> From: "Ulrich Weigand" <uweigand@de.ibm.com>
> 
> 6: No comments received.  However, since i386-nto-tdep.c didn't even
>    compile before my changes, I didn't think I would ...

We probably should simply drop that platform.

i386-nto support (was: Re: [0/8] solib handler rework)

[Ulrich Weigand]

> > Date: Wed, 24 Oct 2007 23:29:54 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > 
> > 6: No comments received.  However, since i386-nto-tdep.c didn't even
> >    compile before my changes, I didn't think I would ...
> 
> We probably should simply drop that platform.

Hmmm, it still seems to be in active use; on qnx.com there is a development
toolchain for download that includes a GDB based on 6.6.

It would certainly be nice if we'd have more active involvement of the
QNX folks in mainline GDB ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

RE: i386-nto support (was: Re: [0/8] solib handler rework)

[Aleksandar Ristovski]

Yes, nto platform is alive. We have a gdb 6.7 based gdb on our community
portal. 

Ulrich, thank you for pointing that out and fixing i386-nto for us. We will
get actively involved as of now.

Regards,

Aleksandar

-----Original Message-----
From: Ulrich Weigand [mailto:uweigand@de.ibm.com] 
Sent: October 29, 2007 4:03 PM
To: mark.kettenis@xs4all.nl
Cc: kevinb@redhat.com; gdb-patches@sourceware.org
Subject: i386-nto support (was: Re: [0/8] solib handler rework)

> > Date: Wed, 24 Oct 2007 23:29:54 +0200 (CEST)
> > From: "Ulrich Weigand" <uweigand@de.ibm.com>
> > 
> > 6: No comments received.  However, since i386-nto-tdep.c didn't even
> >    compile before my changes, I didn't think I would ...
> 
> We probably should simply drop that platform.

Hmmm, it still seems to be in active use; on qnx.com there is a development
toolchain for download that includes a GDB based on 6.6.

It would certainly be nice if we'd have more active involvement of the
QNX folks in mainline GDB ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com