Re: Are ppc*_elf_write_core_note Os-specific?

John Baldwin <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.comp.gnu.binutils
Message-ID <[email protected]>
On Tuesday, January 19, 2016 08:41:05 AM H.J. Lu wrote:
> On Mon, Jan 18, 2016 at 7:14 PM, Alan Modra <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.