[RFC] Move common handlers to sol2_init_abi

Message ID yddr1u5orci.fsf@CeBiTec.Uni-Bielefeld.DE
State New
Headers show
Series
  • [RFC] Move common handlers to sol2_init_abi
Related show

Commit Message

Rainer Orth June 23, 2020, 1:15 p.m.
There's some overlap and duplication between 32 and 64-bit Solaris/SPARC
and x86 tdep files, in particular

        sol2_core_pid_to_str
	*_sol2_sigtramp_p
        sol2_skip_solib_resolver
        *_sol2_static_transform_name (forgotten on amd64)
        set_gdbarch_sofun_address_maybe_missing (likewise)

This patch avoids this by centralizing common code in sol2-tdep.c.
While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name
were declared in the shared sparc-tdep.h, they were only used in Solaris
files.

However, I just discovered that there are two targets that would break
with this patch: both sparc-*-linux* and sparc64-*-linux* include
sparc-sol2-tdep.o and sparc64-sol2-tdep.o in configure.tgt.  With the
new call to sol2_init_abi which only lives in sol2-tdep.o, gdb would
fail to link.  I have no idea what business they have with
Solaris-specific files: I suspect that's to allow debugging of
Solaris/SPARC binaries (i.e. GDB_OSABI_SOLARIS).  What should I do about
this?  Maybe I also could include sol2-tdep.o on Linux/SPARC, but is
this TRT?  AFAICS those files received only mechanical changes over the
last two years (haven't looked further), and I have no way of testing
changes.

Tested on amd64-pc-solaris2.11, i386-pc-solaris2.11,
sparcv9-sun-solaris2.11, and sparc-sun-solaris2.11.

While those patches only/mostly affect Solaris-specific code, I have
some questions:

* Two settings above (static_transform_name,
  sofun_address_maybe_missing) only apply to quirks of stabs.

  The first is completely Solaris-specific (or rather specific to the
  Studio compilers) and I didn't do any real testing here.  Studio cc
  has deprecated stabs support in the 12.4 release back in 2015, gcc has
  defaulted to DWARF-2 on Solaris 7+ since 2004, so maybe the whole
  static_transform_name code can go?

  The second is also called in i386-linux-tdep.c and rs6000-tdep.c and I
  don't know enough about this to say what to do here.

* Beyond that, maybe it's time to think about deprecating Stabs support
  in general.  There has been some discussion on the GCC side

  https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01297.html

  but nothing happened yet.

* When running gdb_ari.sh on the changed files, I got some warnings:

./sol2-tdep.c:156: warning: gdbarch: Call to set_gdbarch_sofun_address_maybe_missing
./sol2-tdep.c:160: warning: gdbarch: Call to set_gdbarch_static_transform_name
./sol2-tdep.c:163: warning: gdbarch: Call to set_gdbarch_skip_solib_resolver
./sol2-tdep.c:166: warning: gdbarch: Call to set_gdbarch_core_pid_to_str
./sparc64-sol2-tdep.c:216: warning: gdbarch: Call to set_gdbarch_skip_trampoline_code
./sparc64-sol2-tdep.c:225: warning: gdbarch: Call to set_gdbarch_software_single_step

  However, all of those calls occur all over the code.  What's worse,
  ARI doesn't give any indication what's the correct way instead.

Thanks.
	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2018-06-27  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* amd64-sol2-tdep.c (amd64_sol2_sigtramp_p): Remove.
	(amd64_sol2_init_abi): Use sol2_sigtramp_p.
	Call sol2_init_abi.
 	Remove calls to set_gdbarch_skip_solib_resolver,
	set_gdbarch_core_pid_to_str.
	* i386-sol2-tdep.c (i386_sol2_sigtramp_p): Remove.
	(i386_sol2_static_transform_name): Remove.
	(i386_sol2_init_abi): Call sol2_init_abi.
	Remove calls to set_gdbarch_sofun_address_maybe_missing,
	set_gdbarch_static_transform_name,
	set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.
	Use sol2_sigtramp_p.
	* sol2-tdep.c (sol2_pc_in_sigtramp): New function.
	(sol2_sigtramp_p): New function.
	(sol2_static_transform_name): New function.
	(sol2_skip_solib_resolver, sol2_core_pid_to_str): Make static.
	(sol2_init_abi): New function.
	* sol2-tdep.h (sol2_sigtramp_p, sol2_init_abi): Declare.
	(sol2_skip_solib_resolver, sol2_core_pid_to_str): Remove.
	* sparc-sol2-tdep.c (sparc_sol2_pc_in_sigtramp): Remove.
	(sparc32_sol2_sigtramp_frame_sniffer): Just call sol2_sigtramp_p.
	(sparc_sol2_static_transform_name): Remove.
	(sparc32_sol2_init_abi): Call sol2_init_abi.
	Remove calls to set_gdbarch_sofun_address_maybe_missing,
	set_gdbarch_static_transform_name,
	set_gdbarch_skip_solib_resolver,
	set_gdbarch_core_pid_to_str.
	* sparc-tdep.h (sparc_sol2_pc_in_sigtramp)
	(sparc_sol2_static_transform_name): Remove
	* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_sniffer): Just
	call sol2_sigtramp_p.
	(sparc64_sol2_init_abi): Call sol2_init_abi.
	Remove calls to set_gdbarch_sofun_address_maybe_missing,
	set_gdbarch_static_transform_name,
	set_gdbarch_skip_solib_resolver, set_gdbarch_core_pid_to_str.

Comments

Rainer Orth June 24, 2020, 10:27 a.m. | #1
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> There's some overlap and duplication between 32 and 64-bit Solaris/SPARC

> and x86 tdep files, in particular

>

>         sol2_core_pid_to_str

> 	*_sol2_sigtramp_p

>         sol2_skip_solib_resolver

>         *_sol2_static_transform_name (forgotten on amd64)

>         set_gdbarch_sofun_address_maybe_missing (likewise)

>

> This patch avoids this by centralizing common code in sol2-tdep.c.

> While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name

> were declared in the shared sparc-tdep.h, they were only used in Solaris

> files.

>

> However, I just discovered that there are two targets that would break

> with this patch: both sparc-*-linux* and sparc64-*-linux* include

> sparc-sol2-tdep.o and sparc64-sol2-tdep.o in configure.tgt.  With the

> new call to sol2_init_abi which only lives in sol2-tdep.o, gdb would

> fail to link.  I have no idea what business they have with

> Solaris-specific files: I suspect that's to allow debugging of

> Solaris/SPARC binaries (i.e. GDB_OSABI_SOLARIS).  What should I do about

> this?  Maybe I also could include sol2-tdep.o on Linux/SPARC, but is

> this TRT?  AFAICS those files received only mechanical changes over the

> last two years (haven't looked further), and I have no way of testing

> changes.


I must have been half asleep when I wrote this: sparc*-*-linux* already
*does* link sol2-tdep.o.  I've now verified (on gcc202 in the GCC
compile farm) that gdb links without and with my patch, so I'm going to
install the patch soon.

I couldn't do a proper regtest, however, since even unmodified master
ran into a tight loop testing gdb.base/testenv.exp (it went up to 4.4+
million iterations before I noticed the problem).  I cannot report the
details now since the system has been unaccessible for two days.

The other questions raised in the patch submission still hold, though.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Simon Marchi June 24, 2020, 2:56 p.m. | #2
On 2020-06-23 9:15 a.m., Rainer Orth wrote:
> There's some overlap and duplication between 32 and 64-bit Solaris/SPARC

> and x86 tdep files, in particular

> 

>         sol2_core_pid_to_str

> 	*_sol2_sigtramp_p

>         sol2_skip_solib_resolver

>         *_sol2_static_transform_name (forgotten on amd64)

>         set_gdbarch_sofun_address_maybe_missing (likewise)

> 

> This patch avoids this by centralizing common code in sol2-tdep.c.

> While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name

> were declared in the shared sparc-tdep.h, they were only used in Solaris

> files.

> 

> However, I just discovered that there are two targets that would break

> with this patch: both sparc-*-linux* and sparc64-*-linux* include

> sparc-sol2-tdep.o and sparc64-sol2-tdep.o in configure.tgt.  With the

> new call to sol2_init_abi which only lives in sol2-tdep.o, gdb would

> fail to link.  I have no idea what business they have with

> Solaris-specific files: I suspect that's to allow debugging of

> Solaris/SPARC binaries (i.e. GDB_OSABI_SOLARIS).  What should I do about

> this?  Maybe I also could include sol2-tdep.o on Linux/SPARC, but is

> this TRT?  AFAICS those files received only mechanical changes over the

> last two years (haven't looked further), and I have no way of testing

> changes.


Hmm, sparc-*-linux* and sparc64-*-linux* have no business including some
Solaris-specific files in the build.

When building a GDB on sparc64/Linux, it shouldn't have support for debugging
sparc64/Solaris binaries.  If you want that, you need to pass
--enable-targets=sparc64-solaris-something (I don't know what the actual triplet
would be).

So it seems like there is some untangling here, putting the functions on the
files that they really belong to, until you can successfully build a sparc64/Linux
GDB without including the sol2 tdep files.  I haven't looked much at the patch
(don't have time right now), but tt would be easier to review if you could go
incrementally, one function at a time.

> 

> Tested on amd64-pc-solaris2.11, i386-pc-solaris2.11,

> sparcv9-sun-solaris2.11, and sparc-sun-solaris2.11.

> 

> While those patches only/mostly affect Solaris-specific code, I have

> some questions:

> 

> * Two settings above (static_transform_name,

>   sofun_address_maybe_missing) only apply to quirks of stabs.

> 

>   The first is completely Solaris-specific (or rather specific to the

>   Studio compilers) and I didn't do any real testing here.  Studio cc

>   has deprecated stabs support in the 12.4 release back in 2015, gcc has

>   defaulted to DWARF-2 on Solaris 7+ since 2004, so maybe the whole

>   static_transform_name code can go?


I would be completely fine with it.  The Solaris port pretty much depends on
the time you have to give, so if you don't have time to deal with ancient stuff,
it's fine to drop support for it.

> 

>   The second is also called in i386-linux-tdep.c and rs6000-tdep.c and I

>   don't know enough about this to say what to do here.

> 

> * Beyond that, maybe it's time to think about deprecating Stabs support

>   in general.  There has been some discussion on the GCC side

> 

>   https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01297.html

> 

>   but nothing happened yet.


I would also be fine with it.  For years, all we have done to the stabs code
(and other old debug info reader) is adjust it to interface changes of the
core code.  And actually, since that goes pretty much untested, it is likely
that an old GDB is less buggy than today's GDB w.r.t. stabs debug info reading.

Simon
Rainer Orth June 24, 2020, 8:57 p.m. | #3
Hi Simon,

> On 2020-06-23 9:15 a.m., Rainer Orth wrote:

>> There's some overlap and duplication between 32 and 64-bit Solaris/SPARC

>> and x86 tdep files, in particular

>> 

>>         sol2_core_pid_to_str

>> 	*_sol2_sigtramp_p

>>         sol2_skip_solib_resolver

>>         *_sol2_static_transform_name (forgotten on amd64)

>>         set_gdbarch_sofun_address_maybe_missing (likewise)

>> 

>> This patch avoids this by centralizing common code in sol2-tdep.c.

>> While sparc_sol2_pc_in_sigtramp and sparc_sol2_static_transform_name

>> were declared in the shared sparc-tdep.h, they were only used in Solaris

>> files.

>> 

>> However, I just discovered that there are two targets that would break

>> with this patch: both sparc-*-linux* and sparc64-*-linux* include

>> sparc-sol2-tdep.o and sparc64-sol2-tdep.o in configure.tgt.  With the

>> new call to sol2_init_abi which only lives in sol2-tdep.o, gdb would

>> fail to link.  I have no idea what business they have with

>> Solaris-specific files: I suspect that's to allow debugging of

>> Solaris/SPARC binaries (i.e. GDB_OSABI_SOLARIS).  What should I do about

>> this?  Maybe I also could include sol2-tdep.o on Linux/SPARC, but is

>> this TRT?  AFAICS those files received only mechanical changes over the

>> last two years (haven't looked further), and I have no way of testing

>> changes.

>

> Hmm, sparc-*-linux* and sparc64-*-linux* have no business including some

> Solaris-specific files in the build.

>

> When building a GDB on sparc64/Linux, it shouldn't have support for debugging

> sparc64/Solaris binaries.  If you want that, you need to pass

> --enable-targets=sparc64-solaris-something (I don't know what the actual triplet

> would be).


sparc{v9,64}-sun-solaris2.11

> So it seems like there is some untangling here, putting the functions on the

> files that they really belong to, until you can successfully build a

> sparc64/Linux

> GDB without including the sol2 tdep files.  I haven't looked much at the patch


From a quick check, this should just work today: the functions declared
in sparc*-sol2-tdep.c are only called in Solaris-specific files already.
I'll give it a try separately.  sparc{32,64}_sol2_init_abi are currently
declared in common files (sparc*-tdep.h), but they can just be made
static and the declarations removed.

> (don't have time right now), but tt would be easier to review if you could go

> incrementally, one function at a time.


I'd thought about that.  However, given that many of the features moved
to common code are rather obscure, I formally don't need approval for
Solaris-specific changes, and a make -j24 check takes between 30 and 60
minutes each time (there are some tests that regularly time out, letting
the test time grow out of bounds), I decided to keep it in one patch.

I'm primarily looking for answers to the meta-questions below here.

>> While those patches only/mostly affect Solaris-specific code, I have

>> some questions:

>> 

>> * Two settings above (static_transform_name,

>>   sofun_address_maybe_missing) only apply to quirks of stabs.

>> 

>>   The first is completely Solaris-specific (or rather specific to the

>>   Studio compilers) and I didn't do any real testing here.  Studio cc

>>   has deprecated stabs support in the 12.4 release back in 2015, gcc has

>>   defaulted to DWARF-2 on Solaris 7+ since 2004, so maybe the whole

>>   static_transform_name code can go?

>

> I would be completely fine with it.  The Solaris port pretty much depends on

> the time you have to give, so if you don't have time to deal with ancient stuff,

> it's fine to drop support for it.


I guess I'll go for it, time permitting: while it doesn't create a
burden, it's just dead code these days.

>> * Beyond that, maybe it's time to think about deprecating Stabs support

>>   in general.  There has been some discussion on the GCC side

>> 

>>   https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01297.html

>> 

>>   but nothing happened yet.

>

> I would also be fine with it.  For years, all we have done to the stabs code

> (and other old debug info reader) is adjust it to interface changes of the

> core code.  And actually, since that goes pretty much untested, it is likely

> that an old GDB is less buggy than today's GDB w.r.t. stabs debug info reading.


Probably someone just has to take the lead, both in GDB and GCC.
Especially in the latter, it's going to take a considerable amount of
work.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Patch

# HG changeset patch
# Parent  7e33a7dc78bfbff535962f2f9db86818cc879796
Move common handlers to sol2_init_abi

diff --git a/gdb/amd64-sol2-tdep.c b/gdb/amd64-sol2-tdep.c
--- a/gdb/amd64-sol2-tdep.c
+++ b/gdb/amd64-sol2-tdep.c
@@ -63,21 +63,6 @@  static int amd64_sol2_gregset_reg_offset
 };
 
 
-/* Return whether THIS_FRAME corresponds to a Solaris sigtramp
-   routine.  */
-
-static int
-amd64_sol2_sigtramp_p (struct frame_info *this_frame)
-{
-  CORE_ADDR pc = get_frame_pc (this_frame);
-  const char *name;
-
-  find_pc_partial_function (pc, &name, NULL, NULL);
-  return (name && (strcmp ("sigacthandler", name) == 0
-		   || strcmp (name, "ucbsigvechandler") == 0
-		   || strcmp (name, "__sighndlr") == 0));
-}
-
 /* Solaris doesn't have a 'struct sigcontext', but it does have a
    'mcontext_t' that contains the saved set of machine registers.  */
 
@@ -104,18 +89,16 @@  amd64_sol2_init_abi (struct gdbarch_info
   amd64_init_abi (info, gdbarch,
 		  amd64_target_description (X86_XSTATE_SSE_MASK, true));
 
-  tdep->sigtramp_p = amd64_sol2_sigtramp_p;
+  sol2_init_abi (info, gdbarch);
+
+  tdep->sigtramp_p = sol2_sigtramp_p;
   tdep->sigcontext_addr = amd64_sol2_mcontext_addr;
   tdep->sc_reg_offset = tdep->gregset_reg_offset;
   tdep->sc_num_regs = tdep->gregset_num_regs;
 
   /* Solaris uses SVR4-style shared libraries.  */
-  set_gdbarch_skip_solib_resolver (gdbarch, sol2_skip_solib_resolver);
   set_solib_svr4_fetch_link_map_offsets
     (gdbarch, svr4_lp64_fetch_link_map_offsets);
-
-  /* How to print LWP PTIDs from core files.  */
-  set_gdbarch_core_pid_to_str (gdbarch, sol2_core_pid_to_str);
 }
 
 void _initialize_amd64_sol2_tdep ();
diff --git a/gdb/i386-sol2-tdep.c b/gdb/i386-sol2-tdep.c
--- a/gdb/i386-sol2-tdep.c
+++ b/gdb/i386-sol2-tdep.c
@@ -46,21 +46,6 @@  static int i386_sol2_gregset_reg_offset[
   0 * 4				/* %gs */
 };
 
-/* Return whether THIS_FRAME corresponds to a Solaris sigtramp
-   routine.  */
-
-static int
-i386_sol2_sigtramp_p (struct frame_info *this_frame)
-{
-  CORE_ADDR pc = get_frame_pc (this_frame);
-  const char *name;
-
-  find_pc_partial_function (pc, &name, NULL, NULL);
-  return (name && (strcmp ("sigacthandler", name) == 0
-		   || strcmp (name, "ucbsigvechandler") == 0
-		   || strcmp (name, "__sighndlr") == 0));
-}
-
 /* Solaris doesn't have a `struct sigcontext', but it does have a
    `mcontext_t' that contains the saved set of machine registers.  */
 
@@ -75,30 +60,6 @@  i386_sol2_mcontext_addr (struct frame_in
   return ucontext_addr + 36;
 }
 
-/* SunPRO encodes the static variables.  This is not related to C++
-   mangling, it is done for C too.  */
-
-static const char *
-i386_sol2_static_transform_name (const char *name)
-{
-  if (name[0] == '.')
-    {
-      const char *p;
-
-      /* For file-local statics there will be a period, a bunch of
-         junk (the contents of which match a string given in the
-         N_OPT), a period and the name.  For function-local statics
-         there will be a bunch of junk (which seems to change the
-         second character from 'A' to 'B'), a period, the name of the
-         function, and the name.  So just skip everything before the
-         last period.  */
-      p = strrchr (name, '.');
-      if (p != NULL)
-        name = p + 1;
-    }
-  return name;
-}
-
 /* Solaris 2.  */
 
 static void
@@ -109,12 +70,7 @@  i386_sol2_init_abi (struct gdbarch_info 
   /* Solaris is SVR4-based.  */
   i386_svr4_init_abi (info, gdbarch);
 
-  /* The SunPRO compiler puts out 0 instead of the address in N_SO symbols,
-     and for SunPRO 3.0, N_FUN symbols too.  */
-  set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
-
-  /* Handle SunPRO encoding of static symbols.  */
-  set_gdbarch_static_transform_name (gdbarch, i386_sol2_static_transform_name);
+  sol2_init_abi (info, gdbarch);
 
   /* Solaris reserves space for its FPU emulator in `fpregset_t'.
      There is also some space reserved for the registers of a Weitek
@@ -125,18 +81,14 @@  i386_sol2_init_abi (struct gdbarch_info 
   tdep->sizeof_fpregset = 380;
 
   /* Signal trampolines are slightly different from SVR4.  */
-  tdep->sigtramp_p = i386_sol2_sigtramp_p;
+  tdep->sigtramp_p = sol2_sigtramp_p;
   tdep->sigcontext_addr = i386_sol2_mcontext_addr;
   tdep->sc_reg_offset = tdep->gregset_reg_offset;
   tdep->sc_num_regs = tdep->gregset_num_regs;
 
   /* Solaris has SVR4-style shared libraries.  */
-  set_gdbarch_skip_solib_resolver (gdbarch, sol2_skip_solib_resolver);
   set_solib_svr4_fetch_link_map_offsets
     (gdbarch, svr4_ilp32_fetch_link_map_offsets);
-
-  /* How to print LWP PTIDs from core files.  */
-  set_gdbarch_core_pid_to_str (gdbarch, sol2_core_pid_to_str);
 }
 
 
diff --git a/gdb/sol2-tdep.c b/gdb/sol2-tdep.c
--- a/gdb/sol2-tdep.c
+++ b/gdb/sol2-tdep.c
@@ -25,7 +25,89 @@ 
 
 #include "sol2-tdep.h"
 
-CORE_ADDR
+/* The Solaris signal trampolines reside in libc.  For normal signals,
+   the function `sigacthandler' is used.  This signal trampoline will
+   call the signal handler using the System V calling convention,
+   where the third argument is a pointer to an instance of
+   `ucontext_t', which has a member `uc_mcontext' that contains the
+   saved registers.  Incidentally, the kernel passes the `ucontext_t'
+   pointer as the third argument of the signal trampoline too, and
+   `sigacthandler' simply passes it on.  However, if you link your
+   program with "-L/usr/ucblib -R/usr/ucblib -lucb", the function
+   `ucbsigvechandler' will be used, which invokes the using the BSD
+   convention, where the third argument is a pointer to an instance of
+   `struct sigcontext'.  It is the `ucbsigvechandler' function that
+   converts the `ucontext_t' to a `sigcontext', and back.  Unless the
+   signal handler modifies the `struct sigcontext' we can safely
+   ignore this.  */
+
+static int
+sol2_pc_in_sigtramp (CORE_ADDR pc, const char *name)
+{
+  return (name && (strcmp (name, "sigacthandler") == 0
+		   || strcmp (name, "ucbsigvechandler") == 0
+		   || strcmp (name, "__sighndlr") == 0));
+}
+
+/* Return whether THIS_FRAME corresponds to a Solaris sigtramp routine.  */
+
+int
+sol2_sigtramp_p (struct frame_info *this_frame)
+{
+  CORE_ADDR pc = get_frame_pc (this_frame);
+  const char *name;
+
+  find_pc_partial_function (pc, &name, NULL, NULL);
+  return sol2_pc_in_sigtramp (pc, name);
+}
+
+/* Unglobalize NAME.  */
+
+static const char *
+sol2_static_transform_name (const char *name)
+{
+  /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop,
+     SunPRO) convert file static variables into global values, a
+     process known as globalization.  In order to do this, the
+     compiler will create a unique prefix and prepend it to each file
+     static variable.  For static variables within a function, this
+     globalization prefix is followed by the function name (nested
+     static variables within a function are supposed to generate a
+     warning message, and are left alone).  The procedure is
+     documented in the Stabs Interface Manual, which is distributed
+     with the compilers, although version 4.0 of the manual seems to
+     be incorrect in some places, at least for SPARC.  The
+     globalization prefix is encoded into an N_OPT stab, with the form
+     "G=<prefix>".  The globalization prefix always seems to start
+     with a dollar sign '$' (sparc) resp. a dot '.' (x86); a dot '.'
+     is used as a separator.  So we  simply strip everything up until
+     the last dot.  */
+  int prefix;
+  
+  switch (gdbarch_bfd_arch_info (target_gdbarch ())->arch)
+    {
+    case bfd_arch_i386:
+      prefix = '.';
+      break;
+    case bfd_arch_sparc:
+      prefix = '$';
+      break;
+    default:
+      internal_error (__FILE__, __LINE__, "Unexpected arch");
+      break;
+    }
+
+  if (name[0] == prefix)
+    {
+      const char *p = strrchr (name, '.');
+      if (p)
+        return p + 1;
+    }
+
+  return name;
+}
+
+static CORE_ADDR
 sol2_skip_solib_resolver (struct gdbarch *gdbarch, CORE_ADDR pc)
 {
   struct bound_minimal_symbol msym;
@@ -37,17 +119,15 @@  sol2_skip_solib_resolver (struct gdbarch
   return 0;
 }
 
-/* This is how we want PTIDs from Solaris core files to be
-   printed.  */
+/* This is how we want PTIDs from Solaris core files to be printed.  */
 
-std::string
+static std::string
 sol2_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid)
 {
   struct inferior *inf;
   int pid;
 
-  /* Check whether we're printing an LWP (gdb thread) or a
-     process.  */
+  /* Check whether we're printing an LWP (gdb thread) or a process.  */
   pid = ptid.lwp ();
   if (pid != 0)
     {
@@ -56,8 +136,7 @@  sol2_core_pid_to_str (struct gdbarch *gd
     }
 
   /* GDB didn't use to put a NT_PSTATUS note in Solaris cores.  If
-     that's missing, then we're dealing with a fake PID corelow.c made
-     up.  */
+     that's missing, then we're dealing with a fake PID corelow.c made up.  */
   inf = find_inferior_ptid (current_inferior ()->process_target (), ptid);
   if (inf == NULL || inf->fake_pid_p)
     return "<core>";
@@ -65,3 +144,24 @@  sol2_core_pid_to_str (struct gdbarch *gd
   /* Not fake; print as usual.  */
   return normal_pid_to_str (ptid);
 }
+
+/* To be called from GDB_OSABI_SOLARIS handlers.  */
+
+void
+sol2_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop, SunPRO)
+     compiler puts out 0 instead of the address in N_SO stabs.  Starting with
+     SunPRO 3.0, the compiler does this for N_FUN stabs too.  */
+  set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
+
+  /* The Sun compilers also do "globalization"; see the comment in
+     sol2_static_transform_name for more information.  */
+  set_gdbarch_static_transform_name (gdbarch, sol2_static_transform_name);
+
+  /* Solaris uses SVR4-style shared libraries.  */
+  set_gdbarch_skip_solib_resolver (gdbarch, sol2_skip_solib_resolver);
+
+  /* How to print LWP PTIDs from core files.  */
+  set_gdbarch_core_pid_to_str (gdbarch, sol2_core_pid_to_str);
+}
diff --git a/gdb/sol2-tdep.h b/gdb/sol2-tdep.h
--- a/gdb/sol2-tdep.h
+++ b/gdb/sol2-tdep.h
@@ -22,8 +22,8 @@ 
 
 struct gdbarch;
 
-CORE_ADDR sol2_skip_solib_resolver (struct gdbarch *, CORE_ADDR);
+int sol2_sigtramp_p (struct frame_info *this_frame);
 
-std::string sol2_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid);
+void sol2_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
 
 #endif /* sol2-tdep.h */
diff --git a/gdb/sparc-sol2-tdep.c b/gdb/sparc-sol2-tdep.c
--- a/gdb/sparc-sol2-tdep.c
+++ b/gdb/sparc-sol2-tdep.c
@@ -99,30 +99,6 @@  static const struct regset sparc32_sol2_
   };
 
 
-/* The Solaris signal trampolines reside in libc.  For normal signals,
-   the function `sigacthandler' is used.  This signal trampoline will
-   call the signal handler using the System V calling convention,
-   where the third argument is a pointer to an instance of
-   `ucontext_t', which has a member `uc_mcontext' that contains the
-   saved registers.  Incidentally, the kernel passes the `ucontext_t'
-   pointer as the third argument of the signal trampoline too, and
-   `sigacthandler' simply passes it on.  However, if you link your
-   program with "-L/usr/ucblib -R/usr/ucblib -lucb", the function
-   `ucbsigvechandler' will be used, which invokes the using the BSD
-   convention, where the third argument is a pointer to an instance of
-   `struct sigcontext'.  It is the `ucbsigvechandler' function that
-   converts the `ucontext_t' to a `sigcontext', and back.  Unless the
-   signal handler modifies the `struct sigcontext' we can safely
-   ignore this.  */
-
-int
-sparc_sol2_pc_in_sigtramp (CORE_ADDR pc, const char *name)
-{
-  return (name && (strcmp (name, "sigacthandler") == 0
-		   || strcmp (name, "ucbsigvechandler") == 0
-		   || strcmp (name, "__sighndlr") == 0));
-}
-
 static struct sparc_frame_cache *
 sparc32_sol2_sigtramp_frame_cache (struct frame_info *this_frame,
 				   void **this_cache)
@@ -201,14 +177,7 @@  sparc32_sol2_sigtramp_frame_sniffer (con
 				     struct frame_info *this_frame,
 				     void **this_cache)
 {
-  CORE_ADDR pc = get_frame_pc (this_frame);
-  const char *name;
-
-  find_pc_partial_function (pc, &name, NULL, NULL);
-  if (sparc_sol2_pc_in_sigtramp (pc, name))
-    return 1;
-
-  return 0;
+  return sol2_sigtramp_p (this_frame);
 }
 
 static const struct frame_unwind sparc32_sol2_sigtramp_frame_unwind =
@@ -221,36 +190,6 @@  static const struct frame_unwind sparc32
   sparc32_sol2_sigtramp_frame_sniffer
 };
 
-/* Unglobalize NAME.  */
-
-const char *
-sparc_sol2_static_transform_name (const char *name)
-{
-  /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop,
-     SunPRO) convert file static variables into global values, a
-     process known as globalization.  In order to do this, the
-     compiler will create a unique prefix and prepend it to each file
-     static variable.  For static variables within a function, this
-     globalization prefix is followed by the function name (nested
-     static variables within a function are supposed to generate a
-     warning message, and are left alone).  The procedure is
-     documented in the Stabs Interface Manual, which is distributed
-     with the compilers, although version 4.0 of the manual seems to
-     be incorrect in some places, at least for SPARC.  The
-     globalization prefix is encoded into an N_OPT stab, with the form
-     "G=<prefix>".  The globalization prefix always seems to start
-     with a dollar sign '$'; a dot '.' is used as a separator.  So we
-     simply strip everything up until the last dot.  */
-
-  if (name[0] == '$')
-    {
-      const char *p = strrchr (name, '.');
-      if (p)
-        return p + 1;
-    }
-
-  return name;
-}
 
 
 void
@@ -264,19 +203,10 @@  sparc32_sol2_init_abi (struct gdbarch_in
   tdep->fpregset = &sparc32_sol2_fpregset;
   tdep->sizeof_fpregset = 400;
 
-  /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop, SunPRO)
-     compiler puts out 0 instead of the address in N_SO stabs.  Starting with
-     SunPRO 3.0, the compiler does this for N_FUN stabs too.  */
-  set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
-
-  /* The Sun compilers also do "globalization"; see the comment in
-     sparc_sol2_static_transform_name for more information.  */
-  set_gdbarch_static_transform_name
-    (gdbarch, sparc_sol2_static_transform_name);
+  sol2_init_abi (info, gdbarch);
 
   /* Solaris has SVR4-style shared libraries...  */
   set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
-  set_gdbarch_skip_solib_resolver (gdbarch, sol2_skip_solib_resolver);
   set_solib_svr4_fetch_link_map_offsets
     (gdbarch, svr4_ilp32_fetch_link_map_offsets);
 
@@ -288,9 +218,6 @@  sparc32_sol2_init_abi (struct gdbarch_in
   set_gdbarch_software_single_step (gdbarch, NULL);
 
   frame_unwind_append_unwinder (gdbarch, &sparc32_sol2_sigtramp_frame_unwind);
-
-  /* How to print LWP PTIDs from core files.  */
-  set_gdbarch_core_pid_to_str (gdbarch, sol2_core_pid_to_str);
 }
 
 void _initialize_sparc_sol2_tdep ();
diff --git a/gdb/sparc-tdep.h b/gdb/sparc-tdep.h
--- a/gdb/sparc-tdep.h
+++ b/gdb/sparc-tdep.h
@@ -245,10 +245,6 @@  extern int sparc_is_annulled_branch_insn
 extern const struct sparc_gregmap sparc32_sol2_gregmap;
 extern const struct sparc_fpregmap sparc32_sol2_fpregmap;
 
-extern int sparc_sol2_pc_in_sigtramp (CORE_ADDR pc, const char *name);
-
-extern const char *sparc_sol2_static_transform_name (const char *name);
-
 extern void sparc32_sol2_init_abi (struct gdbarch_info info,
 				   struct gdbarch *gdbarch);
 
diff --git a/gdb/sparc64-sol2-tdep.c b/gdb/sparc64-sol2-tdep.c
--- a/gdb/sparc64-sol2-tdep.c
+++ b/gdb/sparc64-sol2-tdep.c
@@ -180,15 +180,9 @@  sparc64_sol2_sigtramp_frame_sniffer (con
 				     struct frame_info *this_frame,
 				     void **this_cache)
 {
-  CORE_ADDR pc = get_frame_pc (this_frame);
-  const char *name;
+  return sol2_sigtramp_p (this_frame);
+}
 
-  find_pc_partial_function (pc, &name, NULL, NULL);
-  if (sparc_sol2_pc_in_sigtramp (pc, name))
-    return 1;
-
-  return 0;
-}
 static const struct frame_unwind sparc64_sol2_sigtramp_frame_unwind =
 {
   SIGTRAMP_FRAME,
@@ -216,19 +210,10 @@  sparc64_sol2_init_abi (struct gdbarch_in
 
   sparc64_init_abi (info, gdbarch);
 
-  /* The Sun compilers (Sun ONE Studio, Forte Developer, Sun WorkShop, SunPRO)
-     compiler puts out 0 instead of the address in N_SO stabs.  Starting with
-     SunPRO 3.0, the compiler does this for N_FUN stabs too.  */
-  set_gdbarch_sofun_address_maybe_missing (gdbarch, 1);
-
-  /* The Sun compilers also do "globalization"; see the comment in
-     sparc_sol2_static_transform_name for more information.  */
-  set_gdbarch_static_transform_name
-    (gdbarch, sparc_sol2_static_transform_name);
+  sol2_init_abi (info, gdbarch);
 
   /* Solaris has SVR4-style shared libraries...  */
   set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
-  set_gdbarch_skip_solib_resolver (gdbarch, sol2_skip_solib_resolver);
   set_solib_svr4_fetch_link_map_offsets
     (gdbarch, svr4_lp64_fetch_link_map_offsets);
 
@@ -238,9 +223,6 @@  sparc64_sol2_init_abi (struct gdbarch_in
 
   /* Solaris has kernel-assisted single-stepping support.  */
   set_gdbarch_software_single_step (gdbarch, NULL);
-
-  /* How to print LWP PTIDs from core files.  */
-  set_gdbarch_core_pid_to_str (gdbarch, sol2_core_pid_to_str);
 }
 
 void _initialize_sparc64_sol2_tdep ();