Re: Are ppc*_elf_write_core_note Os-specific?

["H.J. Lu" <hjl.tools@gmail.com>]

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.