[PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[Mark Kettenis]

I'm working on integrating some mostly SPARC-related patches from
David S. Miller.  There were also some general bits in his tree that
I'm going to check in on mainline.  Here's the first.

Committed as obvious (to mainline).

Mark


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

	From David S. Miller  <davem@redhat.com>:
	* gdbarch.sh (SKIP_SOLIB_RESOLVER): New method.
	* gdbarch.c, gdbarch.h: Regenerated.
	* arch-utils.c (generic_skip_solib_resolver): New function.
	* arch-utils.h (generic_skip_solib_resolver): New prototype.
	* infrun.c (SKIP_SOLIB_RESOLVER): Don't define.

Index: gdbarch.sh
===================================================================
RCS file: /cvs/src/src/gdb/gdbarch.sh,v
retrieving revision 1.280
diff -u -p -r1.280 gdbarch.sh
--- gdbarch.sh 22 Oct 2003 23:54:11 -0000 1.280
+++ gdbarch.sh 9 Nov 2003 12:03:22 -0000
@@ -700,6 +700,10 @@ f::TARGET_PRINT_INSN:int:print_insn:bfd_
 f:2:SKIP_TRAMPOLINE_CODE:CORE_ADDR:skip_trampoline_code:CORE_ADDR pc:pc:::generic_skip_trampoline_code::0
 
 
+# If IN_SOLIB_DYNSYM_RESOLVE_CODE returns true, and SKIP_SOLIB_RESOLVER
+# evaluates non-zero, this is the address where the debugger will place
+# a step-resume breakpoint to get us past the dynamic linker.
+f:2:SKIP_SOLIB_RESOLVER:CORE_ADDR:skip_solib_resolver:CORE_ADDR pc:pc:::generic_skip_solib_resolver::0
 # For SVR4 shared libraries, each call goes through a small piece of
 # trampoline code in the ".plt" section.  IN_SOLIB_CALL_TRAMPOLINE evaluates
 # to nonzero if we are currently stopped in one of these.
Index: arch-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.c,v
retrieving revision 1.101
diff -u -p -r1.101 arch-utils.c
--- arch-utils.c 31 Oct 2003 22:19:12 -0000 1.101
+++ arch-utils.c 9 Nov 2003 12:03:22 -0000
@@ -100,6 +100,12 @@ generic_skip_trampoline_code (CORE_ADDR 
   return 0;
 }
 
+CORE_ADDR
+generic_skip_solib_resolver (CORE_ADDR pc)
+{
+  return 0;
+}
+
 int
 generic_in_solib_call_trampoline (CORE_ADDR pc, char *name)
 {
Index: arch-utils.h
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.h,v
retrieving revision 1.59
diff -u -p -r1.59 arch-utils.h
--- arch-utils.h 27 Oct 2003 20:47:27 -0000 1.59
+++ arch-utils.h 9 Nov 2003 12:03:22 -0000
@@ -110,6 +110,8 @@ extern gdbarch_virtual_frame_pointer_fty
 
 extern CORE_ADDR generic_skip_trampoline_code (CORE_ADDR pc);
 
+extern CORE_ADDR generic_skip_solib_resolver (CORE_ADDR pc);
+
 extern int generic_in_solib_call_trampoline (CORE_ADDR pc, char *name);
 
 extern int generic_in_solib_return_trampoline (CORE_ADDR pc, char *name);
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.117
diff -u -p -r1.117 infrun.c
--- infrun.c 24 Oct 2003 17:37:03 -0000 1.117
+++ infrun.c 9 Nov 2003 12:03:25 -0000
@@ -153,10 +153,6 @@ static int may_follow_exec = MAY_FOLLOW_
 #define IN_SOLIB_DYNSYM_RESOLVE_CODE(pc) 0
 #endif
 
-#ifndef SKIP_SOLIB_RESOLVER
-#define SKIP_SOLIB_RESOLVER(pc) 0
-#endif
-
 /* This function returns TRUE if pc is the address of an instruction
    that lies within the dynamic linker (such as the event hook, or the
    dld itself).

Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[Andrew Cagney]

> I'm working on integrating some mostly SPARC-related patches from
> David S. Miller.  There were also some general bits in his tree that
> I'm going to check in on mainline.  Here's the first.

You mean the stuff david posted here?

> Committed as obvious (to mainline).

It should be "m" or "M", and not "f".
You'll also note that I've started deleting still lurking macros so 
these conversions are no longer so obvious :-)

Andrew

Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[Mark Kettenis]

   Date: Sun, 09 Nov 2003 08:38:57 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > I'm working on integrating some mostly SPARC-related patches from
   > David S. Miller.  There were also some general bits in his tree that
   > I'm going to check in on mainline.  Here's the first.

   You mean the stuff david posted here?

Some of it has been posted, some hasn't.  I explicitly asked David
about the copyright status, and he told me it was all written by
himself, and that is copyright assignment is still in place.

   > Committed as obvious (to mainline).

   It should be "m" or "M", and not "f".
   You'll also note that I've started deleting still lurking macros so 
   these conversions are no longer so obvious :-)

Hmm.  So the "f" conversions are no longer considered obvious?  The
problem with "m" and "M" is that they no longer define the macro that
we're replacing.  That means things become a bit more complicated.  Do
you want me to replace SKIP_SOLIB_RESOLVER with a truly multi-arched
function?

Mark

Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[Andrew Cagney]

>    Date: Sun, 09 Nov 2003 08:38:57 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    > I'm working on integrating some mostly SPARC-related patches from
>    > David S. Miller.  There were also some general bits in his tree that
>    > I'm going to check in on mainline.  Here's the first.
> 
>    You mean the stuff david posted here?
> 
> Some of it has been posted, some hasn't.  I explicitly asked David
> about the copyright status, and he told me it was all written by
> himself, and that is copyright assignment is still in place.
> 
>    > Committed as obvious (to mainline).
> 
>    It should be "m" or "M", and not "f".
>    You'll also note that I've started deleting still lurking macros so 
>    these conversions are no longer so obvious :-)
> 
> Hmm.  So the "f" conversions are no longer considered obvious?  The
> problem with "m" and "M" is that they no longer define the macro that
> we're replacing.  That means things become a bit more complicated.  Do
> you want me to replace SKIP_SOLIB_RESOLVER with a truly multi-arched
> function?

Yep.  More generally, I'd prefer to see people try to consolidate 
existing methods, or create a new "gdbarch has-a" relationship(1), 
rather than add yet another architecture method.  The architecture 
vector contains so much redundancy that it is depressing.

Any way, for your case, make the default something like:

CORE_ADDR
cannot_skip_solib_resolver (struct gdbarch *gdbarch, CORE_ADDR pc)
{
#ifdef SKIP_SOLIB_RESOLVER
	/* Ok the function's name is a lie.   This is here to prop up old 
architectures and should be deleted.  */
	return SKIP_SOLIB_RESOLVER(...);
#else
  	return 0;
#endif
}

Then the macro can be deprecated.

Andrew

(1) As in gdbarch has-a reggroup, gdbarch has-a unwinder, gdbarch has-a 
regset, ...

Re: [PATCH] Multi-arch SKIP_SOLIB_RESOLVER

[Mark Kettenis]

   Date: Sun, 09 Nov 2003 15:38:18 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > Hmm.  So the "f" conversions are no longer considered obvious?  The
   > problem with "m" and "M" is that they no longer define the macro that
   > we're replacing.  That means things become a bit more complicated.  Do
   > you want me to replace SKIP_SOLIB_RESOLVER with a truly multi-arched
   > function?

   Yep.  More generally, I'd prefer to see people try to consolidate 
   existing methods, or create a new "gdbarch has-a" relationship(1), 
   rather than add yet another architecture method.  The architecture 
   vector contains so much redundancy that it is depressing.

gdbarch has-a shared library architecture.  Yes, we defenitely need
that.  I have some thoughts on it.  But I want to finish SPARC and the
corefile stuff first...

   Any way, for your case, make the default something like:

   CORE_ADDR
   cannot_skip_solib_resolver (struct gdbarch *gdbarch, CORE_ADDR pc)
   {
   #ifdef SKIP_SOLIB_RESOLVER
	   /* Ok the function's name is a lie.   This is here to prop up old 
   architectures and should be deleted.  */
	   return SKIP_SOLIB_RESOLVER(...);
   #else
	   return 0;
   #endif
   }

   Then the macro can be deprecated.

I'll get rid of the SKIP_SOLIB_RESOLVER macro completely, but
unfortunately I won't have time to do this before friday.

Mark