Re: Are ppc*_elf_write_core_note Os-specific?

Re: Are ppc*_elf_write_core_note Os-specific?

[Alan Modra]

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?

-- 
Alan Modra
Australia Development Lab, IBM

Re: Are ppc*_elf_write_core_note Os-specific?

[Pedro Alves]

On 01/19/2016 03:14 AM, Alan Modra 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?
> 

Yes.  IMO, all bfd core file generation and reading should be
made independent of host headers.

Thanks,
Pedro Alves

Re: Are ppc*_elf_write_core_note Os-specific?

[H.J. Lu]

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.

-- 
H.J.

Re: Are ppc*_elf_write_core_note Os-specific?

[John Baldwin]

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.

-- 
John Baldwin

Re: Are ppc*_elf_write_core_note Os-specific?

[H.J. Lu]

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?

-- 
H.J.

Re: Are ppc*_elf_write_core_note Os-specific?

[John Baldwin]

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

Re: Are ppc*_elf_write_core_note Os-specific?

[H.J. Lu]

On Tue, Jan 19, 2016 at 11:32 AM, John Baldwin <jhb@freebsd.org> wrote:
> 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.
>

We could do

1.  Pass OS selection from GDB to BFD.  Or
2.  Factor out OS selection from GDB and put it into GDB so that it
can be used by both GDB and BFD.


-- 
H.J.

Re: Are ppc*_elf_write_core_note Os-specific?

[John Baldwin]

On Tuesday, January 19, 2016 11:35:33 AM H.J. Lu wrote:
> On Tue, Jan 19, 2016 at 11:32 AM, John Baldwin <jhb@freebsd.org> wrote:
> > 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.
> >
> 
> We could do
> 
> 1.  Pass OS selection from GDB to BFD.  Or
> 2.  Factor out OS selection from GDB and put it into GDB so that it
> can be used by both GDB and BFD.

I can work with whatever approach you think is best.  Note that some of
the logic in osabi.c is to deal with older binaries (a.out, older ELF when
different "branding" strategies were used, etc.).  For the purposes of
generating new binaries, checking elf_osabi in the ELF-specific core code
as in elfcore_write_xstatereg might be sufficient for 1.

For 2., the existing logic is used to choose a specific gdbarch (which I
think would be akin to detecting a specific BFD target to use).  You could
already perhaps do this without additional changes if the write_core_note
override were a per-target override (e.g. x86_64_elf64_fbsd_vec could have
a FreeBSD-specific write_core_note).  However, I don't generally see
Linux-specific targets (which I think you would want to hold
Linux-specific write_core_note's so that the "generic" targets did not
provide overrides, though only architectures that want a custom
write_core_note would need that).  My understanding of BFD targets is
quite limited however, and it maybe that write_core_note is already a
target method (or it might be that write_core_note in a BFD target would
be a layering violation).

-- 
John Baldwin

Re: Are ppc*_elf_write_core_note Os-specific?

[Pedro Alves]

Can this be made to work along the lines of 70a38d42c5b3 ?

Thanks,
Pedro Alves

Re: Are ppc*_elf_write_core_note Os-specific?

[H.J. Lu]

On Tue, Jan 19, 2016 at 12:54 PM, Pedro Alves <palves@redhat.com> wrote:
> Can this be made to work along the lines of 70a38d42c5b3 ?
>

Probably.  See:

https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=0b1b9b0935de0f6d97540d80dfb698444cb07072

-- 
H.J.

Re: Are ppc*_elf_write_core_note Os-specific?

[H.J. Lu]

On Tue, Jan 19, 2016 at 1:20 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Jan 19, 2016 at 12:54 PM, Pedro Alves <palves@redhat.com> wrote:
>> Can this be made to work along the lines of 70a38d42c5b3 ?
>>
>
> Probably.  See:
>
> https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=0b1b9b0935de0f6d97540d80dfb698444cb07072
>
> --
> H.J.

See users/hjl/gcore branch.


-- 
H.J.

Re: Are ppc*_elf_write_core_note Os-specific?

[Pedro Alves]

On 01/19/2016 09:20 PM, H.J. Lu wrote:
> On Tue, Jan 19, 2016 at 12:54 PM, Pedro Alves <palves@redhat.com> wrote:
>> Can this be made to work along the lines of 70a38d42c5b3 ?
>>
> 
> Probably.  See:
> 
> https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=0b1b9b0935de0f6d97540d80dfb698444cb07072
> 

The thing is that GDB always knows the target ABI/OS it wants the core note
to be generated for, so there should be no need to go through the bfd target
vector to generate an OS-specific note, or to stuff everything
through a crippling varargs interface such as elf_backend_write_core_note's.
Instead, bfd can export OS-specific variants of the note generation functions,
and GDB can call those directly.  By avoiding the varargs-style strangling of
elf_backend_write_core_note, it's also MUCH easier to pass down note-specific
info.  The original motivation of 70a38d42c5b3 (elfcore_write_linux_prpsinfo*)
was so that we could fill in all fields of the Linux prpsinfo structure.
(Note how elfcore_write_prpsinfo only takes a few parameters; it's missing a
lot of others bits.)

The gdb-side counterpart of 70a38d42c5b3 is b3ac9c77560a.

All the Linux-specific NT_PRPSINFO handling in the different
elf_backend_write_core_note implementations in bfd are dead code, I think,
since GDB always calls elfcore_write_linux_prpsinfo* directly, and only
GDB calls the  elfcore_write_pr* functions.

I think that ideally we'd give the same treatment to
elfcore_write_prstatus; it's just that nobody ever did the leg work.

Thanks,
Pedro Alves

Re: Are ppc*_elf_write_core_note Os-specific?

[Alan Modra]

On Tue, Jan 19, 2016 at 10:52:33PM +0000, Pedro Alves wrote:
> I think that ideally we'd give the same treatment to
> elfcore_write_prstatus; it's just that nobody ever did the leg work.

Some leg work.  For all linux targets except mips n32 which has a
64-bit pr_sigpend and pr_sighold, we have

struct elf_prstatus
{
  struct elf_siginfo pr_info;
  short int pr_cursig;
  unsigned long int pr_sigpend;
  unsigned long int pr_sighold;
  __pid_t pr_pid;
  __pid_t pr_ppid;
  __pid_t pr_pgrp;
  __pid_t pr_sid;
  struct timeval pr_utime;
  struct timeval pr_stime;
  struct timeval pr_cutime;
  struct timeval pr_cstime;
  elf_gregset_t pr_reg;
  int pr_fpvalid;
};

struct elf_siginfo is three ints, struct timeval is two longs except
for sparc where tv_usec is an int, __pid_t is an int.  elf_gregset_t
of course varies.  Unless I'm missing some odd target struct alignment
rule, I think that means linux needs a 32-bit and 64-bit variant of
elfcore_write_linux_prprstatus with parameters similar to
elfcore_write_linux_prpsinfo*, and special cases for mips n32 and
sparc64.  I'd assume gdb's new elf_internal_linux_prstatus struct
would contain a pointer to and size of regs in target format.  Host
format would be messy since some 64-bit targets have the odd 32-bit
reg hidden away in elf_gregset_t.

-- 
Alan Modra
Australia Development Lab, IBM