[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #15 from Martin Liska  ---
Thanks Mark, I installed the patch but I see still the same. For now, I'm
leaving that, I'm not so much interested in s390x ;)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #16 from Mark Wielaard  ---
(In reply to Martin Liska from comment #15)
> Thanks Mark, I installed the patch but I see still the same.

The output was exactly the same? That is surprising. So there is no additional
output that explains which failure path was taken? I would have expected at
least a message about the dwfl_getthreads call.

> For now, I'm
> leaving that, I'm not so much interested in s390x ;)

Understood if it is too much work to track down. We have other s390x setups
that seems fine. But I still don't fully understand the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mliska at suse dot cz]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #17 from Martin Liska  ---
(In reply to Mark Wielaard from comment #16)
> (In reply to Martin Liska from comment #15)
> > Thanks Mark, I installed the patch but I see still the same.
> 
> The output was exactly the same? That is surprising. So there is no
> additional output that explains which failure path was taken? I would have
> expected at least a message about the dwfl_getthreads call.

Yes:

$ ./backtrace-dwarf 
0x3ff8a9c0622   raise
0x3ff8a9a3ce2   abort
./backtrace-dwarf: dwfl_thread_getframes: no error

Looks that child correctly triggers assert.

> 
> > For now, I'm
> > leaving that, I'm not so much interested in s390x ;)
> 
> Understood if it is too much work to track down. We have other s390x setups
> that seems fine. But I still don't fully understand the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23673

--- Comment #18 from Mark Wielaard  ---
(In reply to Martin Liska from comment #17)
> (In reply to Mark Wielaard from comment #16)
> > (In reply to Martin Liska from comment #15)
> > > Thanks Mark, I installed the patch but I see still the same.
> > 
> > The output was exactly the same? That is surprising. So there is no
> > additional output that explains which failure path was taken? I would have
> > expected at least a message about the dwfl_getthreads call.
> 
> Yes:
> 
> $ ./backtrace-dwarf 
> 0x3ff8a9c0622 raise
> 0x3ff8a9a3ce2 abort
> ./backtrace-dwarf: dwfl_thread_getframes: no error
> 
> Looks that child correctly triggers assert.

Aha, ok, yes, I missed that dwfl_thread_getthreads just calls
dwfl_thread_getframes (there is only one thread) and this does indeed not find
the main frame. I'll tweak the testcase a bit more to make it show that.

But we now know for sure that it isn't the testframe infrastructure failing,
but that the unwinder really seems to not unwind through abort and so doesn't
find main. Still don't know what is happening though.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[COMMITTED] tests: backtrace-dwarf.c improve error handling in test framework.

[Mark Wielaard]

To debug https://sourceware.org/bugzilla/show_bug.cgi?id=23673
clean up the test framework so we know what exactly failed.

Suggested-by: Dmitry V. Levin 
Signed-off-by: Mark Wielaard 
---
 tests/ChangeLog |  7 +++
 tests/backtrace-dwarf.c | 38 --
 2 files changed, 31 insertions(+), 14 deletions(-)

diff --git a/tests/ChangeLog b/tests/ChangeLog
index 4e8b814..04eeb4a 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,3 +1,10 @@
+2018-09-18  Mark Wielaard  
+
+   * backtrace-dwarf.c (thread_callback): Only error when
+   dwfl_thread_getframes returns an error.
+   (main): Don't call abort or assert but print an error when
+   something unexpected happens.
+
 2018-09-13  Mark Wielaard  
 
* run-strip-test-many.sh: New test.
diff --git a/tests/backtrace-dwarf.c b/tests/backtrace-dwarf.c
index 35f25ed..dfbf185 100644
--- a/tests/backtrace-dwarf.c
+++ b/tests/backtrace-dwarf.c
@@ -1,5 +1,5 @@
 /* Test program for unwinding of complicated DWARF expressions.
-   Copyright (C) 2013, 2015 Red Hat, Inc.
+   Copyright (C) 2013, 2015, 2018 Red Hat, Inc.
This file is part of elfutils.
 
This file is free software; you can redistribute it and/or modify
@@ -16,7 +16,6 @@
along with this program.  If not, see .  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -117,9 +116,11 @@ frame_callback (Dwfl_Frame *state, void *frame_arg)
 static int
 thread_callback (Dwfl_Thread *thread, void *thread_arg)
 {
-  dwfl_thread_getframes (thread, frame_callback, NULL);
+  if (dwfl_thread_getframes (thread, frame_callback, NULL) == -1)
+error (1, 0, "dwfl_thread_getframes: %s", dwfl_errmsg (-1));
+
   /* frame_callback shall exit (0) on success.  */
-  error (1, 0, "dwfl_thread_getframes: %s", dwfl_errmsg (-1));
+  printf ("dwfl_thread_getframes returned, main not found\n");
   return DWARF_CB_ABORT;
 }
 
@@ -141,13 +142,18 @@ main (int argc __attribute__ ((unused)), char **argv)
   switch (pid)
   {
 case -1:
-  abort ();
+  perror ("fork failed");
+  exit (-1);
 case 0:;
   long l = ptrace (PTRACE_TRACEME, 0, NULL, NULL);
-  assert (errno == 0);
-  assert (l == 0);
+  if (l != 0)
+   {
+ perror ("PTRACE_TRACEME failed");
+ exit (-1);
+   }
   cleanup_13_main ();
-  abort ();
+  printf ("cleanup_13_main returned, impossible...\n");
+  exit (-1);
 default:
   break;
   }
@@ -155,16 +161,20 @@ main (int argc __attribute__ ((unused)), char **argv)
   errno = 0;
   int status;
   pid_t got = waitpid (pid, &status, 0);
-  assert (errno == 0);
-  assert (got == pid);
-  assert (WIFSTOPPED (status));
-  assert (WSTOPSIG (status) == SIGABRT);
+  if (got != pid)
+error (1, errno, "waitpid returned %d", got);
+  if (!WIFSTOPPED (status))
+error (1, 0, "unexpected wait status %u", status);
+  if (WSTOPSIG (status) != SIGABRT)
+error (1, 0, "unexpected signal %u", WSTOPSIG (status));
 
   Dwfl *dwfl = pid_to_dwfl (pid);
-  dwfl_getthreads (dwfl, thread_callback, NULL);
+  if (dwfl_getthreads (dwfl, thread_callback, NULL) == -1)
+error (1, 0, "dwfl_getthreads: %s", dwfl_errmsg (-1));
 
   /* There is an exit (0) call if we find the "main" frame,  */
-  error (1, 0, "dwfl_getthreads: %s", dwfl_errmsg (-1));
+  printf ("dwfl_getthreads returned, main not found\n");
+  exit (-1);
 }
 
 #endif /* ! __linux__ */
-- 
1.8.3.1

Re: Handling pgoff in perf elf mmap/mmap2 elf info

[Mark Wielaard]

On Wed, 2018-09-19 at 14:24 +0200, Ulf Hermann wrote:
> > We suspect perf to offset its recording-addresses of mmapped
> > dsos/executables starting with a specific section, such that they
> > denote
> > their pointers with this pg_offset parameter. (e.g. skipping a
> > library's
> > header and setting pgoff to the headersize). Although we are not
> > 100%
> > sure about this information.
> 
> According to my understanding, the pgoff is not perf's invention.
> Rather, the libary loader for the target application does not mmap()
> the full ELF file, but only the parts it's interested in. Those
> partial mappings are then reported through perf.

OK, so pgoff is like the offset argument of the mmap call?
Is it just recording all user space mmap events that have PROT_EXEC in
their prot argument? What about if the mapping was later changed with
mprotect? Or does PERF_RECORD_MMAP only map to some internal kernel
mmap action?

>  We then try to recreate the memory mapping with perfparser, but run
> into problems because dwfl_report_elf() doesn't let us do partial
> mappings. You can only map complete files with that function. There
> probably is some way to manually map the relevant sections using
> other functions in libdw and libelf, but I haven't figured out how to
> do this, yet. If there is a simple trick I'm missing, I'd be happy to
> hear about it. 
> 
> And, yes, a function that works like dwfl_report_elf, but takes a
> pgoff and length as additional parameters is sorely missing from the
> API.

dwfl_report_elf indeed does assume the whole ELF file is mapped in
according to the PHDRs in the file and the given base address. But what
you are actually seeing (I think, depending on the answers on the
questions above) is the dynamic loader mapping in the file in pieces.
And so you would like an interface where you can report the module
piece wise while it is being mapped in. So what would be most
convenient would be some kind of dwfl_report_elf_mmap function that you
can use to either get a new Dwfl_Module or to extend an existing one.

I have to think how that interacts with mprotect and mmunmap.

Cheers,

Mark