[RFC] Core files and the architecture vector

[RFC] Core files and the architecture vector

[Mark Kettenis]

Folks,

With the new regset_from_core_section architecture method, most of the
infrastructure for non-native generic core file support is present.
Now I face the problem of how to acrually use it.  My initial
approach, which I used to test the stuff that I've already checked in,
was to create yet another `struct core_fns', and register it using
add_core_fns().  This works, but has its problems:

* We have to do this seperately for every BFD "flavour" (i.e. a.out,
  COFF, ELF).

* It's diffucult to handle the case where the "architecture" of the
  core file is different from the "architecture" of the executable.

Let me elaborate on the second point.  When a 32-bit executable
running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
64-bit ELF core file.  To be able to make any sense out of this core
file, we'll need the 64-bit register set definitions that are provided
by the regset_from_core_section method from the 64-bit architecture
vector.  It is easier to accomplish this from a lower level, directly
in the functions in corelow.c.  This maybe a better way anyway, since
I'll propose to deprecate the old way of adding core file support
(using `struct core_fns') in the near future.

The problem I'm having, is that we have no clean seperation between
initalizing and activating an architecture vector; it's all done from
gdbarch.c:gdbarch_update_p().  Looking at the function, it seems as if
it's not quite so easy to seperate the two because of the
per-architecture swapped data.  I've hacked around this by
unconditionally setting the architecture from CORE_BFD, fetching the
core architecture vector from CURRENT_GDBARCH, and reset the
architecture from EXEC_BFD if we have one; refer to the attached code
to see what I mean.

Is this kosher?  Do folks agree with this approach?

Mark


Index: corelow.c
===================================================================
RCS file: /cvs/src/src/gdb/corelow.c,v
retrieving revision 1.30
diff -u -p -r1.30 corelow.c
--- corelow.c 21 Sep 2003 01:26:44 -0000 1.30
+++ corelow.c 11 Oct 2003 21:25:14 -0000
@@ -37,9 +37,12 @@
 #include "gdbcore.h"
 #include "gdbthread.h"
 #include "regcache.h"
+#include "regset.h"
 #include "symfile.h"
 #include <readline/readline.h>
 
+#include "gdb_assert.h"
+
 #ifndef O_BINARY
 #define O_BINARY 0
 #endif
@@ -55,6 +58,8 @@ static struct core_fns *core_file_fns = 
 
 static struct core_fns *core_vec = NULL;
 
+struct gdbarch *core_gdbarch = NULL;
+
 static void core_files_info (struct target_ops *);
 
 #ifdef SOLIB_ADD
@@ -124,6 +129,9 @@ sniff_core_bfd (bfd *abfd)
   struct core_fns *yummy = NULL;
   int matches = 0;;
 
+  if (gdbarch_regset_from_core_section_p (core_gdbarch))
+    return NULL;
+
   for (cf = core_file_fns; cf != NULL; cf = cf->next)
     {
       if (cf->core_sniffer (cf, abfd))
@@ -208,6 +216,7 @@ core_close (int quitting)
 	}
     }
   core_vec = NULL;
+  core_gdbarch = NULL;
 }
 
 static void
@@ -310,6 +319,9 @@ core_open (char *filename, int from_tty)
   core_bfd = temp_bfd;
   old_chain = make_cleanup (core_close_cleanup, 0 /*ignore*/);
 
+  set_gdbarch_from_file (core_bfd);
+  core_gdbarch = current_gdbarch;
+
   /* Find a suitable core file handler to munch on core_bfd */
   core_vec = sniff_core_bfd (core_bfd);
 
@@ -321,12 +333,11 @@ core_open (char *filename, int from_tty)
     error ("\"%s\": Can't find sections: %s",
 	   bfd_get_filename (core_bfd), bfd_errmsg (bfd_get_error ()));
 
-  /* If we have no exec file, try to set the architecture from the
-     core file.  We don't do this unconditionally since an exec file
+  /* If we have an exec file, reset the architecture.  An exec file
      typically contains more information that helps us determine the
      architecture than a core file.  */
-  if (!exec_bfd)
-    set_gdbarch_from_file (core_bfd);
+  if (exec_bfd)
+    set_gdbarch_from_file (exec_bfd);
 
   ontop = !push_target (&core_ops);
   discard_cleanups (old_chain);
@@ -436,6 +447,24 @@ get_core_register_section (char *name,
       return;
     }
 
+  if (gdbarch_regset_from_core_section_p (core_gdbarch))
+    {
+      const struct regset *regset;
+
+      regset = gdbarch_regset_from_core_section (core_gdbarch, name, size);
+      if (regset == NULL)
+	{
+	  if (required)
+	    warning ("Couldn't recognize %s registers in core file.\n",
+		     human_name);
+	  return;
+	}
+
+      regset->supply_regset (regset, current_regcache, -1, contents, size);
+      return;
+    }
+
+  gdb_assert (core_vec);
   core_vec->core_read_registers (contents, size, which, 
 				 ((CORE_ADDR)
 				  bfd_section_vma (core_bfd, section)));
@@ -453,8 +482,8 @@ get_core_registers (int regno)
 {
   int status;
 
-  if (core_vec == NULL
-      || core_vec->core_read_registers == NULL)
+  if (!gdbarch_regset_from_core_section_p (core_gdbarch)
+      && (core_vec == NULL || core_vec->core_read_registers == NULL))
     {
       fprintf_filtered (gdb_stderr,
 		     "Can't fetch registers from this type of core file\n");

Re: [RFC] Core files and the architecture vector

[Daniel Jacobowitz]

I'll respond to the rest of your message later but...

On Sun, Oct 12, 2003 at 12:07:32AM +0200, Mark Kettenis wrote:
> Let me elaborate on the second point.  When a 32-bit executable
> running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
> 64-bit ELF core file.  To be able to make any sense out of this core
> file, we'll need the 64-bit register set definitions that are provided
> by the regset_from_core_section method from the 64-bit architecture

I still don't think this bit makes much sense.  The process sees only
32-bit registers; the core should contain only 32-bit registers. 
Intuitively at least.  On the other hand, on MIPS64 (and x86-64?) a
32-bit process can actually access 64-bit registers.  It's forbidden to
and the context switching won't cope right, but it can be done anyway.

Do we see 32-bit or 64-bit registers from ptrace when debugging such a
process?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Core files and the architecture vector

[Mark Kettenis]

   Date: Sat, 11 Oct 2003 18:26:22 -0400
   From: Daniel Jacobowitz <drow@mvista.com>

   I'll respond to the rest of your message later but...

   On Sun, Oct 12, 2003 at 12:07:32AM +0200, Mark Kettenis wrote:
   > Let me elaborate on the second point.  When a 32-bit executable
   > running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
   > 64-bit ELF core file.  To be able to make any sense out of this core
   > file, we'll need the 64-bit register set definitions that are provided
   > by the regset_from_core_section method from the 64-bit architecture

   I still don't think this bit makes much sense.  The process sees only
   32-bit registers; the core should contain only 32-bit registers.

Well, it's not for me to decide what how the various OSes dump core
:-(.

Anyway even for 32-bit only stuff the core file architecture and
executable architecture might differ.  When running a GNU/Linux i386
binary on FreeBSD/i386, it produces a FreeBSD/i386 corefile.

   Do we see 32-bit or 64-bit registers from ptrace when debugging such a
   process?

At least on FreeBSD/amd64 you see the 64-bit register with ptrace.

Mark

Re: [RFC] Core files and the architecture vector

[Andrew Cagney]

> When a 32-bit executable
> running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
> 64-bit ELF core file.

I think that's a kernel bug.  A 32 bit emulation environment should 
emulate things right down to the binary format of a core dump :-)

However ...

> The problem I'm having, is that we have no clean seperation between
> initalizing and activating an architecture vector; it's all done from
> gdbarch.c:gdbarch_update_p().  Looking at the function, it seems as if
> it's not quite so easy to seperate the two because of the
> per-architecture swapped data.  I've hacked around this by
> unconditionally setting the architecture from CORE_BFD, fetching the
> core architecture vector from CURRENT_GDBARCH, and reset the
> architecture from EXEC_BFD if we have one; refer to the attached code
> to see what I mean.
> 
> Is this kosher?  Do folks agree with this approach?

Is this kosher?  No.  Is there a better way?  No.

GDBARCH methods that give the appearance of returning an architecture 
(without affecting global state) vis:

	struct gdbarch *gdbarch_from_file ();

are going to be needed (however, right now they would only allow us to 
fool ourselves into thinking we're safe :-).  A method like:

	struct gdbarch *deprecated_select_gdbarch_hack (struct gdbarch *);

method might also be useful?

Andrew

PS: This is only going to get worse - target <>- thread <>- frame will 
have an equally messy transition.

PPS: Suggest more "rude" comments about how dangerous this is.

Re: [RFC] Core files and the architecture vector

[Andrew Cagney]

>    Do we see 32-bit or 64-bit registers from ptrace when debugging such a
>    process?
> 
> At least on FreeBSD/amd64 you see the 64-bit register with ptrace.

As in a 64-bit GDB is linked against a 64-bit ptrace so sees 64-bit 
registers when debugging a 32-bit app.  Same for x86-64 GNU/Linux.

At least this bit is right.

Andrew

Re: [RFC] Core files and the architecture vector

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> I'll respond to the rest of your message later but...  On
 Daniel> Sun, Oct 12, 2003 at 12:07:32AM +0200, Mark Kettenis wrote:
 >> Let me elaborate on the second point.  When a 32-bit executable
 >> running on FreeBSD/amd64 or GNU/Linux x86-64 dumps, it produces an
 >> 64-bit ELF core file.  To be able to make any sense out of this
 >> core file, we'll need the 64-bit register set definitions that are
 >> provided by the regset_from_core_section method from the 64-bit
 >> architecture

 Daniel> I still don't think this bit makes much sense.  The process
 Daniel> sees only 32-bit registers; the core should contain only
 Daniel> 32-bit registers.  Intuitively at least.  On the other hand,
 Daniel> on MIPS64 (and x86-64?) a 32-bit process can actually access
 Daniel> 64-bit registers.  It's forbidden to and the context
 Daniel> switching won't cope right, but it can be done anyway.

Precisely for that reason the core file should contain the real
registers, not the truncated ones.  Taking a MIPS example: if
supposedly 32-bit code somehow manages to have the upper 32 bits of
the registers NOT be sign-extension as they are supposed to be, then
Bad Things will happen to that program.  If the core file only shows
the truncated registers, you can't see what went wrong.

    paul