Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [hppa-hpux] Core file support for hppa64-hp-hpux11.11
@ 2005-11-17 12:56 Randolph Chung
  2005-11-17 14:46 ` Mark Kettenis
  0 siblings, 1 reply; 8+ messages in thread
From: Randolph Chung @ 2005-11-17 12:56 UTC (permalink / raw)
  To: gdb-patches

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

Together with http://sourceware.org/ml/binutils/2005-11/msg00269.html, 
the following patch adds support for corefiles to hppa64-hp-hpux11.11. 
This should fix corefiles/2026

I'll check this in once the bfd bits are approved.

randolph

[-- Attachment #2: core.diff --]
[-- Type: text/x-patch, Size: 1244 bytes --]

2005-11-17  Randolph Chung  <tausq@debian.org>

	PR corefiles/2026
	* hppa-hpux-tdep.c (hppa_hpux_core_osabi_sniffer): Recognize core 
	files generated by hppa64-hp-hpux*
	(_initialize_hppa_hpux_tdep): Likewise.

Index: hppa-hpux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-hpux-tdep.c,v
retrieving revision 1.43
diff -u -p -r1.43 hppa-hpux-tdep.c
--- hppa-hpux-tdep.c	29 Oct 2005 21:31:45 -0000	1.43
+++ hppa-hpux-tdep.c	17 Nov 2005 12:18:56 -0000
@@ -2055,6 +2064,8 @@ hppa_hpux_core_osabi_sniffer (bfd *abfd)
 {
   if (strcmp (bfd_get_target (abfd), "hpux-core") == 0)
     return GDB_OSABI_HPUX_SOM;
+  else if (strcmp (bfd_get_target (abfd), "elf64-hppa") == 0)
+    return GDB_OSABI_HPUX_ELF;
 
   return GDB_OSABI_UNKNOWN;
 }
@@ -2067,6 +2078,9 @@ _initialize_hppa_hpux_tdep (void)
   gdbarch_register_osabi_sniffer (bfd_arch_unknown,
 				  bfd_target_unknown_flavour,
 				  hppa_hpux_core_osabi_sniffer);
+  gdbarch_register_osabi_sniffer (bfd_arch_hppa,
+                                  bfd_target_elf_flavour,
+				  hppa_hpux_core_osabi_sniffer);
 
   gdbarch_register_osabi (bfd_arch_hppa, 0, GDB_OSABI_HPUX_SOM,
                           hppa_hpux_som_init_abi);

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-17 12:56 [hppa-hpux] Core file support for hppa64-hp-hpux11.11 Randolph Chung
@ 2005-11-17 14:46 ` Mark Kettenis
  2005-11-17 15:52   ` Randolph Chung
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Kettenis @ 2005-11-17 14:46 UTC (permalink / raw)
  To: randolph; +Cc: gdb-patches

> Date: Thu, 17 Nov 2005 20:26:06 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> Together with http://sourceware.org/ml/binutils/2005-11/msg00269.html, 
> the following patch adds support for corefiles to hppa64-hp-hpux11.11. 
> This should fix corefiles/2026
> 
> I'll check this in once the bfd bits are approved.
> 
> 2005-11-17  Randolph Chung  <tausq@debian.org>
> 
> 	PR corefiles/2026
> 	* hppa-hpux-tdep.c (hppa_hpux_core_osabi_sniffer): Recognize core 
> 	files generated by hppa64-hp-hpux*
> 	(_initialize_hppa_hpux_tdep): Likewise.
> 
> Index: hppa-hpux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/hppa-hpux-tdep.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 hppa-hpux-tdep.c
> --- hppa-hpux-tdep.c	29 Oct 2005 21:31:45 -0000	1.43
> +++ hppa-hpux-tdep.c	17 Nov 2005 12:18:56 -0000
> @@ -2055,6 +2064,8 @@ hppa_hpux_core_osabi_sniffer (bfd *abfd)
>  {
>    if (strcmp (bfd_get_target (abfd), "hpux-core") == 0)
>      return GDB_OSABI_HPUX_SOM;
> +  else if (strcmp (bfd_get_target (abfd), "elf64-hppa") == 0)
> +    return GDB_OSABI_HPUX_ELF;

Don't think this is right.  Is it needed at all?  If it is, then we
should try to do this differently.  The mere fact that the BFD target
is elf64-hppa doesn't imply that this is a HP-UX ELF core file does it?

Mark


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-17 14:46 ` Mark Kettenis
@ 2005-11-17 15:52   ` Randolph Chung
  2005-11-17 16:02     ` Mark Kettenis
  0 siblings, 1 reply; 8+ messages in thread
From: Randolph Chung @ 2005-11-17 15:52 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

> Don't think this is right.  Is it needed at all?  If it is, then we
> should try to do this differently.  The mere fact that the BFD target
> is elf64-hppa doesn't imply that this is a HP-UX ELF core file does it?

Well, the osabi sniffer doesn't say that it's a corefile, it just says 
it's a HPUX ELF file. As for whether "elf64-hppa" means hpux, currently 
bfd/elf64-hppa.c only supports two targets, hpux and linux, and linux is 
"elf64-hppa-linux". I know this is not very nice. Do you have any other 
suggestions?

randolph


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-17 15:52   ` Randolph Chung
@ 2005-11-17 16:02     ` Mark Kettenis
  2005-11-18  3:37       ` Randolph Chung
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Kettenis @ 2005-11-17 16:02 UTC (permalink / raw)
  To: randolph; +Cc: gdb-patches

> Date: Thu, 17 Nov 2005 20:56:39 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> Well, the osabi sniffer doesn't say that it's a corefile, it just says 
> it's a HPUX ELF file. As for whether "elf64-hppa" means hpux, currently 
> bfd/elf64-hppa.c only supports two targets, hpux and linux, and linux is 
> "elf64-hppa-linux". I know this is not very nice. Do you have any other 
> suggestions?

Ok, so your problem is that the core file is marked as "UNIX - System
V", so there's no way to tell that this is a HP-UX core file.

What I'd do, is create BFD sections out of those HP_CORE_XXX program
headers, and then in GDB, check for one of those sections.  There's
one program header that looks particularly promising: HP_CORE_KERNEL.
That one contains the string HP-UX.  That'd certainly convince me that
this is a HP-UX core file.

Actually I think it makes sense to modify your BFD patch such that it
gives all HP_CORE_XXX program headers a sensible name:


/* Support HP specific sections for core files.  */
static bfd_boolean
elf64_hppa_section_from_phdr (bfd *abfd, Elf_Internal_Phdr *hdr, int index,
                              const char *typename)
{
  switch (hdr->p_type)
    {
    case PT_HP_CORE_VERSION:
      typename = "core.version";
      break;
    case PT_HP_CORE_KERNEL:
      typename = "core.kernel";
      break;
    case PT_HP_CORE_PROC:

      ...

    }

  if (hdr->p_type == PT_HP_CORE_PROC)
    {
      int sig;

      if (bfd_seek (abfd, hdr->p_offset, SEEK_SET) != 0)
        return FALSE;
      if (bfd_bread (&sig, 4, abfd) != 4)
        return FALSE;

      elf_tdata (abfd)->core_signal = sig;

      /* gdb uses the ".reg" section to read register contents.  */
      if (!_bfd_elfcore_make_pseudosection (abfd, ".reg", hdr->p_filesz,
	  				    hdr->p_offset))
        return FALSE;
    }

  if (hdr->p_type == PT_HP_CORE_LOADABLE
      || hdr->p_type == PT_HP_CORE_STACK
      || hdr->p_type == PT_HP_CORE_MMF)
    hdr->p_type = PT_LOAD;

  return _bfd_elf_make_section_from_phdr (abfd, hdr, index, typename);
}


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-17 16:02     ` Mark Kettenis
@ 2005-11-18  3:37       ` Randolph Chung
  2005-11-18  4:44         ` Mark Kettenis
  0 siblings, 1 reply; 8+ messages in thread
From: Randolph Chung @ 2005-11-18  3:37 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

> Ok, so your problem is that the core file is marked as "UNIX - System
> V", so there's no way to tell that this is a HP-UX core file.

Yes.

> What I'd do, is create BFD sections out of those HP_CORE_XXX program
> headers, and then in GDB, check for one of those sections.  There's
> one program header that looks particularly promising: HP_CORE_KERNEL.
> That one contains the string HP-UX.  That'd certainly convince me that
> this is a HP-UX core file.

[...]

> Actually I think it makes sense to modify your BFD patch such that it
> gives all HP_CORE_XXX program headers a sensible name:

Sure, I'll do that.

So basically you want:
1) BFD to name the HP_CORE_KERNEL phdr as a "core.kernel" section
2) GDB in its OSABI sniffer will look for this section and check that 
its contents contains "HP-UX"

right?

randolph


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-18  3:37       ` Randolph Chung
@ 2005-11-18  4:44         ` Mark Kettenis
  2005-11-18 13:49           ` Randolph Chung
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Kettenis @ 2005-11-18  4:44 UTC (permalink / raw)
  To: randolph; +Cc: gdb-patches

> Date: Fri, 18 Nov 2005 07:44:04 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> > Ok, so your problem is that the core file is marked as "UNIX - System
> > V", so there's no way to tell that this is a HP-UX core file.
> 
> Yes.
> 
> > What I'd do, is create BFD sections out of those HP_CORE_XXX program
> > headers, and then in GDB, check for one of those sections.  There's
> > one program header that looks particularly promising: HP_CORE_KERNEL.
> > That one contains the string HP-UX.  That'd certainly convince me that
> > this is a HP-UX core file.
> 
> [...]
> 
> > Actually I think it makes sense to modify your BFD patch such that it
> > gives all HP_CORE_XXX program headers a sensible name:
> 
> Sure, I'll do that.
> 
> So basically you want:
> 1) BFD to name the HP_CORE_KERNEL phdr as a "core.kernel" section
> 2) GDB in its OSABI sniffer will look for this section and check that 
> its contents contains "HP-UX"
> 
> right?

Yes.  The section will come out as .core.kernel in objdump.  Perhaps
it should be .hp.core.kernel.  I'll leave the naming decision to you
and/or the binutils maintainers.  But I think that's better than
having all those .proc0, .proc1, .proc2 sections that we have now.
And it makes it easier to pick the right one from GDB.

Mark


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-18  4:44         ` Mark Kettenis
@ 2005-11-18 13:49           ` Randolph Chung
  2005-11-18 15:30             ` Mark Kettenis
  0 siblings, 1 reply; 8+ messages in thread
From: Randolph Chung @ 2005-11-18 13:49 UTC (permalink / raw)
  To: Mark Kettenis; +Cc: gdb-patches

> Yes.  The section will come out as .core.kernel in objdump.  Perhaps
> it should be .hp.core.kernel.  I'll leave the naming decision to you
> and/or the binutils maintainers.  But I think that's better than
> having all those .proc0, .proc1, .proc2 sections that we have now.
> And it makes it easier to pick the right one from GDB.

actually there's no . prefix unless i explicitly pass one, and they will 
look like:

/home/tausq/core:     file format elf64-hppa

Sections:
Idx Name          Size      VMA               LMA               File off 
  Algn
   0 hp.core.version0 00000004  0000000000000000  0000000000000000 
00000350  2**0
                   CONTENTS, READONLY
   1 hp.core.kernel1 0000003c  0000000000000000  0000000000000000 
00000354  2**0
                  CONTENTS, READONLY
   2 hp.core.comm2 00000009  0000000000000000  0000000000000000 
00000390  2**0
                   CONTENTS, READONLY
   [...]

Does this match what you have in mind?

randolph


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [hppa-hpux] Core file support for hppa64-hp-hpux11.11
  2005-11-18 13:49           ` Randolph Chung
@ 2005-11-18 15:30             ` Mark Kettenis
  0 siblings, 0 replies; 8+ messages in thread
From: Mark Kettenis @ 2005-11-18 15:30 UTC (permalink / raw)
  To: randolph; +Cc: gdb-patches

> Date: Fri, 18 Nov 2005 20:58:49 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> > Yes.  The section will come out as .core.kernel in objdump.  Perhaps
> > it should be .hp.core.kernel.  I'll leave the naming decision to you
> > and/or the binutils maintainers.  But I think that's better than
> > having all those .proc0, .proc1, .proc2 sections that we have now.
> > And it makes it easier to pick the right one from GDB.
> 
> actually there's no . prefix unless i explicitly pass one, and they will 
> look like:

Hmm, looks like I misread the code in bfd//elf.c then.

> /home/tausq/core:     file format elf64-hppa
> 
> Sections:
> Idx Name          Size      VMA               LMA               File off 
>   Algn
>    0 hp.core.version0 00000004  0000000000000000  0000000000000000 
> 00000350  2**0
>                    CONTENTS, READONLY
>    1 hp.core.kernel1 0000003c  0000000000000000  0000000000000000 
> 00000354  2**0
>                   CONTENTS, READONLY
>    2 hp.core.comm2 00000009  0000000000000000  0000000000000000 
> 00000390  2**0
>                    CONTENTS, READONLY
>    [...]
> 
> Does this match what you have in mind?

It sort of screws up the formatting doesn't it.  Perhaps something
like the attached is better; we only need the HP_CORE_KERNEL section
don't we?  This gives output like this:

/tmp/core:     file format elf64-hppa

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 proc0         00000004  0000000000000000  0000000000000000  00000350  2**0
                  CONTENTS, READONLY
  1 proc1         0000003c  0000000000000000  0000000000000000  00000354  2**0
                  CONTENTS, READONLY
  2 .kernel       0000003c  0000000000000000  0000000000000000  00000354  2**0
                  CONTENTS, READONLY
  3 proc2         00000009  0000000000000000  0000000000000000  00000390  2**0
                  CONTENTS, READONLY
  4 proc3         00000498  0000000000000000  0000000000000000  000003a0  2**0
                  CONTENTS, READONLY
  5 .reg/0        00000498  0000000000000000  0000000000000000  000003a0  2**2
                  CONTENTS
  6 .reg          00000498  0000000000000000  0000000000000000  000003a0  2**2
                  CONTENTS
  7 proc4         0000c000  8000000100000000  0000000000000000  00000838  2**0
                  CONTENTS, ALLOC, LOAD, CODE


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

	* elf64-hppa.c (elf64_hppa_section_from_phdr): Create .kernel
	pseudo-section.  Make sure .reg section comes after the proc
	section it's generated from.

Index: elf64-hppa.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-hppa.c,v
retrieving revision 1.66
diff -u -p -r1.66 elf64-hppa.c
--- elf64-hppa.c 18 Nov 2005 00:48:50 -0000 1.66
+++ elf64-hppa.c 18 Nov 2005 14:19:00 -0000
@@ -2652,6 +2652,22 @@ static bfd_boolean
 elf64_hppa_section_from_phdr (bfd *abfd, Elf_Internal_Phdr *hdr, int index,
 			      const char *typename)
 {
+  if (hdr->p_type == PT_HP_CORE_KERNEL)
+    {
+      asection *sect;
+
+      if (!_bfd_elf_make_section_from_phdr (abfd, hdr, index, typename))
+	return FALSE;
+
+      sect = bfd_make_section_anyway (abfd, ".kernel");
+      if (sect == NULL)
+	return FALSE;
+      sect->size = hdr->p_filesz;
+      sect->filepos = hdr->p_offset;
+      sect->flags = SEC_HAS_CONTENTS | SEC_READONLY;
+      return TRUE;
+    }
+
   if (hdr->p_type == PT_HP_CORE_PROC)
     {
       int sig;
@@ -2663,10 +2679,12 @@ elf64_hppa_section_from_phdr (bfd *abfd,
 
       elf_tdata (abfd)->core_signal = sig;
 
-      /* gdb uses the ".reg" section to read register contents.  */
-      if (!_bfd_elfcore_make_pseudosection (abfd, ".reg", hdr->p_filesz,
-	  				    hdr->p_offset))
+      if (!_bfd_elf_make_section_from_phdr (abfd, hdr, index, typename))
 	return FALSE;
+
+      /* GDB uses the ".reg" section to read register contents.  */
+      return _bfd_elfcore_make_pseudosection (abfd, ".reg", hdr->p_filesz,
+					      hdr->p_offset);
     }
 
   if (hdr->p_type == PT_HP_CORE_LOADABLE


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-11-18 14:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-11-17 12:56 [hppa-hpux] Core file support for hppa64-hp-hpux11.11 Randolph Chung
2005-11-17 14:46 ` Mark Kettenis
2005-11-17 15:52   ` Randolph Chung
2005-11-17 16:02     ` Mark Kettenis
2005-11-18  3:37       ` Randolph Chung
2005-11-18  4:44         ` Mark Kettenis
2005-11-18 13:49           ` Randolph Chung
2005-11-18 15:30             ` Mark Kettenis

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox