Created attachment 1001207 [details]
A patch to skip 64-bit biarch tests on 32-bit host

In theory this should work. A 32bit elfutils can unwind a 64bit core file for example. But the problem here is that there seems to be no way to get the 64bit register values of the target process. We end up in backends/x86_64_initreg.c (x86_64_set_initial_registers_tid) which will just return false:

#if !defined(__x86_64__) || !defined(__linux__)
  return false;
#else /* __x86_64__ */

Is there anything we can do there?
Or is ptrace from a 32bit process against a 64bit process just not going to work?

(In reply to Mark Wielaard from comment #2)
> Is there anything we can do there?
> Or is ptrace from a 32bit process against a 64bit process just not going to
> work?

You can't get 64-bit register values from ia32 process.  You can
get 64-bit register values from x32 process.  But the x32 address
space can't reach 64-bit address. Many things won't work.

(In reply to H.J. Lu from comment #3)
> You can't get 64-bit register values from ia32 process.
> You can get 64-bit register values from x32 process.

OK, then for ia32 your patch makes sense.
But it might be too broad if it also covers x32.

> But the x32 address space can't reach 64-bit address. Many things won't work.

For x32 I think we should at least get the 64-bit register values and see how far we get with that. Since libdw uses GElf_Addr and Dwarf_Addr, which are always 64bit, we are able to unwind 64-bit core files from a 32bit eu-stack for example. It might make sense to extend that to native processes for x32. Otherwise you'll have to build a x86_64 elfutils to get full x32 support.

ppc has syscalls for 32->64 access like PPC_PTRACE_PEEKTEXT_3264.

(In reply to Jan Kratochvil from comment #5)
> ppc has syscalls for 32->64 access like PPC_PTRACE_PEEKTEXT_3264.

I don't think it ever works:

static bool
pid_memory_read (Dwfl *dwfl, Dwarf_Addr addr, Dwarf_Word *result, void *arg)
{
  struct __libdwfl_pid_arg *pid_arg = arg;
  pid_t tid = pid_arg->tid_attached;
  assert (tid > 0);
  Dwfl_Process *process = dwfl->process;
  if (ebl_get_elfclass (process->ebl) == ELFCLASS64)
    {
#if SIZEOF_LONG == 8
      errno = 0;
      *result = ptrace (PTRACE_PEEKDATA, tid, (void *) (uintptr_t) addr, NULL);
      return errno == 0;
#else /* SIZEOF_LONG != 8 */
      /* This should not happen.  */
      return false;

Memory read of 64-bit process from 32-bit process always fails.

#endif /* SIZEOF_LONG != 8 */
    }

(In reply to H.J. Lu from comment #6)
> (In reply to Jan Kratochvil from comment #5)
> > ppc has syscalls for 32->64 access like PPC_PTRACE_PEEKTEXT_3264.
> 
> I don't think it ever works:
> 
> static bool
> pid_memory_read (Dwfl *dwfl, Dwarf_Addr addr, Dwarf_Word *result, void *arg)
> {
>   struct __libdwfl_pid_arg *pid_arg = arg;
>   pid_t tid = pid_arg->tid_attached;
>   assert (tid > 0);
>   Dwfl_Process *process = dwfl->process;
>   if (ebl_get_elfclass (process->ebl) == ELFCLASS64)
>     {
> #if SIZEOF_LONG == 8
>       errno = 0;
>       *result = ptrace (PTRACE_PEEKDATA, tid, (void *) (uintptr_t) addr,
> NULL);
>       return errno == 0;
> #else /* SIZEOF_LONG != 8 */
>       /* This should not happen.  */
>       return false;
> 
> Memory read of 64-bit process from 32-bit process always fails.
> 
> #endif /* SIZEOF_LONG != 8 */
>     }

Could that be fixed by using process_vm_readv or pread on /proc/PID/mem?

(In reply to Mark Wielaard from comment #7)
> 
> Could that be fixed by using process_vm_readv or pread on /proc/PID/mem?

Yes, if you can read 64-bit process memory from 32-bit process.

There are

struct iovec
  {
    void *iov_base;	/* Pointer to data.  */
    size_t iov_len;	/* Length of data.  */
  };

You can't read 64-bit memory from 32-bit process.

Created attachment 1002948 [details]
ppc32 backend patch to query 64bit processes

I created a dirty hack to make a ppc32 elfutils eu-stack work against ppc64 processes. It works, but needs some cleanup. The callback needs a way to know the ELF class of the process and the pid_memory_read probably needs to become a new ebl function so other arches can override.

$ file src/stack
src/stack: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xc8af6f4ce1da3e8c8c6eb20893f28c92edba8eec, not stripped

$ file -L /proc/$$/exe 
/proc/57869/exe: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xa0b448d58e63764cf7e618775cfa3ef639c107db, stripped

$ LD_LIBRARY_PATH=backends:libelf:libdw src/stack -v -p $$
PID 57869 - process
TID 57869:
#0  0x00003fffa9a416cc     __waitpid - /usr/lib64/power8/libc-2.17.so
#1  0x000000001004efd4 - 1 - /usr/bin/bash
#2  0x00000000100508cc - 1 wait_for - /usr/bin/bash
#3  0x000000001003c010 - 1 execute_command_internal - /usr/bin/bash
#4  0x000000001003c204 - 1 execute_command - /usr/bin/bash
#5  0x000000001001fa58 - 1 reader_loop - /usr/bin/bash
#6  0x000000001001d520 - 1 main - /usr/bin/bash
#7  0x00003fffa9995dec - 1 generic_start_main.isra.0 - /usr/lib64/power8/libc-2.17.so

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Marking futurefeature since it could in theory be supported if needed.

Lets move this upstream. The following bug describes the same issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=24158