Re: Are ppc*_elf_write_core_note Os-specific?

[John Baldwin <jhb at freebsd dot org>]

On Tuesday, January 19, 2016 11:08:23 AM H.J. Lu wrote:
> On Tue, Jan 19, 2016 at 10:16 AM, John Baldwin <jhb@freebsd.org> wrote:
> > On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote:
> >> On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <amodra@gmail.com> wrote:
> >> > On Tue, Jan 19, 2016 at 10:48:19AM +1030, Alan Modra wrote:
> >> >> PowerPC64 glibc even now doesn't defing prstatus32_t.  :-(  It seems
> >> >> only sparc and s390 do so.  So PowerPC would need a
> >> >> hosts/powerpc-linux.h to define them for Linux, with some configury
> >> >> changes, like hosts/x86-64linux.h does for x86-64 Linux.  I'll see
> >> >> about making those changes.
> >> >>
> >> >> Note that elf_backend_write_core_note is defined for x86-64, arm and
> >> >> aarch64 too.  The ARM and AARCH64 functions look to be completely
> >> >> redundant, and I suspect all of them could disappear if we modify the
> >> >> generic code to handle prstatusx32_t for x86-64.
> >> >
> >> > Actually, there is a reason for the ARM and AARCH64 functions.
> >> > See https://sourceware.org/ml/binutils/2011-10/msg00202.html
> >> > Note the followup emails too..
> >> >
> >> > So it seems that with the current infrastructure we can either support
> >> > core file generation on remote (linux) targets, or core file
> >> > generation on more native targets (freebsd).  Alternatively, we'd
> >> > need to use separate bfd target vectors for linux and freebsd, which
> >> > can and will cause multiple target matches.
> >> >
> >> > Do we really want non-native core file generation?
> >> >
> >>
> >> Any changes shouldn't introduce regressions.  I don't see why
> >> elf_backend_write_core_note can't handle all targets BFD supports
> >> since note_type is unique to each OS.  BFD just needs to provide
> >> proper types independent of host header files, similar to
> >> hosts/x86-64linux.h.
> >
> > Switching on note_type alone (as the current write_core_note methods do)
> > isn't sufficient.   Currently bfd writes out notes like NT_PRSTATUS and
> > NT_PRPSINFO with the "CORE" name on multiple platforms, so a
> > (note_name, note_type) tuple also seems insufficient.  Are you suggesting
> > to switch on (ELF OSABI, note_type)?  That is, supposing you had a
> > hosts/x86-64freebsd.h with a 'struct freebsd_amd64_prstatus' and if
> > hosts/x86-64linux.h had 'struct linux_x86_64_prstatus' (or whatever names
> > are preferred), then the logic in the write_core_note would look something
> > like:
> >
> >   switch (get_elf_backend_data (abfd)->elf_osabi)
> >     {
> >       case ELFOSABI_FREEBSD:
> >         {
> >           switch (note_type)
> >             {
> >               case NT_PRSTATUS:
> >                  struct freebsd_amd64_prstatus prstatus;
> >                  ...
> >                  return elfcore_write_note (abfd, ... &prstatus, ...);
> >               ...
> >             }
> >           ...
> >         }
> >       case ELFOSABI_LINUX:
> >         {
> >           switch (note_type)
> >             {
> >               case NT_PRSTATUS:
> >                  struct linux_x86_64_prstatus prstatus;
> >                  ...
> >                  return elfcore_write_note (abfd, ... &prstatus, ...);
> >               ...
> >             }
> >           ...
> >         }
> >       ..
> >     }
> >
> > If so, checking elf_osabi in the current write_core_note functions and
> > falling back to the native "catch-all" if it is not a currently-supported
> > elf_osabi would be sufficient to preserve existing functionality (I think)
> > while allowing other ABIs to either use the catch-all or implement support
> > for desired non-native cores.
> 
> How does GDB tell Linux binary from FreeBSD binary?

For the purposes of choosing a gdbarch to use (and a corresponding set of
'tdep' code to use for parsing register notes, etc.) there are various
tests used.  The bits I understand are in gdb/osabi.c and test for various
things including the elf_osabi field but also .note.ABI-tag notes?  I think
some (most?) of this detection is to handle historical cases.  I'm not sure
of the history enough to know which fields are set in modern binaries (and
thus used to choose an ABI).

The current code to generate a core from within gdb in fbsd-tdep.c overrides
the osabi of the bfd before outputting notes:

static char *
fbsd_make_corefile_notes (struct gdbarch *gdbarch, bfd *obfd, int *note_size)
{
  ...

  /* Put a "FreeBSD" label in the ELF header.  */
  i_ehdrp = elf_elfheader (obfd);
  i_ehdrp->e_ident[EI_OSABI] = ELFOSABI_FREEBSD;

(This may be unnecessary since the core is created using the same target as
the executable file.  I will have to try that and see.)

This is already used in elfcore_write_xstatereg to determine the note name to
use when writing out a register note for XSAVE state:

char *
elfcore_write_xstatereg (bfd *abfd, char *buf, int *bufsiz,
			 const void *xfpregs, int size)
{
  char *note_name;
  if (get_elf_backend_data (abfd)->elf_osabi == ELFOSABI_FREEBSD)
    note_name = "FreeBSD";
  else
    note_name = "LINUX";
  return elfcore_write_note (abfd, buf, bufsiz,
			     note_name, NT_X86_XSTATE, xfpregs, size);
}

linux-tdep.c doesn't appear to explicitly set the osabi, and FreeBSD and
Linux are the only targets in gdb that I see that support writing out corefile
notes.

-- 
John Baldwin