[PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Ulf Hermann]

This is useful to test unwinding without debug information. The
binaries being examined might still have frame pointers that allow
us to bridge the unknown symbols.

Signed-off-by: Ulf Hermann <ulf.hermann@qt.io>
---
  tests/ChangeLog         |  6 ++++++
  tests/backtrace-subr.sh | 14 ++++++++++----
  tests/backtrace.c       | 30 ++++++++++++++++++++++--------
  3 files changed, 38 insertions(+), 12 deletions(-)

diff --git a/tests/ChangeLog b/tests/ChangeLog
index 7040ac8..bca47be 100644
--- a/tests/ChangeLog
+++ b/tests/ChangeLog
@@ -1,5 +1,11 @@
  2017-02-09  Ulf Hermann  <ulf.hermann@qt.io>
  
+	* backtrace.c: Add an option to allow unknown symbols in the trace
+	* backtrace-substr.sh: Add an option to allow unknown symbols
+	to check_core() and allow failed symbol lookups in check_err()
+
+2017-02-09  Ulf Hermann  <ulf.hermann@qt.io>
+
  	* backtrace-data.c: Don't assert that symbols are found.
  	The unwinder is allowed to ask for invalid addresses. We deny
  	such requests, rather than make the test fail.
diff --git a/tests/backtrace-subr.sh b/tests/backtrace-subr.sh
index 790b4f4..5d3937c 100644
--- a/tests/backtrace-subr.sh
+++ b/tests/backtrace-subr.sh
@@ -44,9 +44,12 @@ check_gsignal()
  # In some cases we cannot reliably find out we got behind _start as some
  # operating system do not properly terminate CFI by undefined PC.
  # Ignore it here as it is a bug of OS, not a bug of elfutils.
+# If the CFI is not terminated correctly, we might find another frame by
+# checking for frame pointers. This is still not our problem, but only
+# gives an error message when trying to look up the function name.
  check_err()
  {
-  if [ $(egrep -v <$1 'dwfl_thread_getframes: (No DWARF information found|no matching address range)$' \
+  if [ $(egrep -v <$1 'dwfl_thread_getframes: (No DWARF information found|no matching address range|address out of range)$' \
           | wc -c) \
         -eq 0 ]
    then
@@ -61,7 +64,9 @@ check_all()
    bt=$1
    err=$2
    testname=$3
-  check_main $bt $testname
+  if [ "x$4" != "x--allow-unknown" ]; then
+    check_main $bt $testname
+  fi
    check_gsignal $bt $testname
    check_err $err $testname
  }
@@ -98,13 +103,14 @@ check_native_unsupported()
  check_core()
  {
    arch=$1
+  args=$2
    testfiles backtrace.$arch.{exec,core}
    tempfiles backtrace.$arch.{bt,err}
    echo ./backtrace ./backtrace.$arch.{exec,core}
-  testrun ${abs_builddir}/backtrace -e ./backtrace.$arch.exec --core=./backtrace.$arch.core 1>backtrace.$arch.bt 2>backtrace.$arch.err || true
+  testrun ${abs_builddir}/backtrace $args -e ./backtrace.$arch.exec --core=./backtrace.$arch.core 1>backtrace.$arch.bt 2>backtrace.$arch.err || true
    cat backtrace.$arch.{bt,err}
    check_unsupported backtrace.$arch.err backtrace.$arch.core
-  check_all backtrace.$arch.{bt,err} backtrace.$arch.core
+  check_all backtrace.$arch.{bt,err} backtrace.$arch.core $args
  }
  
  # Backtrace live process.
diff --git a/tests/backtrace.c b/tests/backtrace.c
index 1ff6353..34a2ab0 100644
--- a/tests/backtrace.c
+++ b/tests/backtrace.c
@@ -64,6 +64,7 @@ dump_modules (Dwfl_Module *mod, void **userdata __attribute__ ((unused)),
    return DWARF_CB_OK;
  }
  
+static bool allow_unknown;
  static bool use_raise_jmp_patching;
  static pid_t check_tid;
  
@@ -78,7 +79,8 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr pc,
      seen_main = true;
    if (pc == 0)
      {
-      assert (seen_main);
+      if (!allow_unknown)
+        assert (seen_main);
        return;
      }
    if (check_tid == 0)
@@ -103,11 +105,12 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr pc,
  	       && (strcmp (symname, "__kernel_vsyscall") == 0
  		   || strcmp (symname, "__libc_do_syscall") == 0))
  	reduce_frameno = true;
-      else
+      else if (!allow_unknown || symname)
  	assert (symname && strcmp (symname, "raise") == 0);
        break;
      case 1:
-      assert (symname != NULL && strcmp (symname, "sigusr2") == 0);
+      if (!allow_unknown || symname)
+        assert (symname != NULL && strcmp (symname, "sigusr2") == 0);
        break;
      case 2: // x86_64 only
        /* __restore_rt - glibc maybe does not have to have this symbol.  */
@@ -116,20 +119,24 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr pc,
        if (use_raise_jmp_patching)
  	{
  	  /* Verify we trapped on the very first instruction of jmp.  */
-	  assert (symname != NULL && strcmp (symname, "jmp") == 0);
+          if (!allow_unknown || symname)
+            assert (symname != NULL && strcmp (symname, "jmp") == 0);
  	  mod = dwfl_addrmodule (dwfl, pc - 1);
  	  if (mod)
  	    symname2 = dwfl_module_addrname (mod, pc - 1);
-	  assert (symname2 == NULL || strcmp (symname2, "jmp") != 0);
+          if (!allow_unknown || symname2)
+            assert (symname2 == NULL || strcmp (symname2, "jmp") != 0);
  	  break;
  	}
        /* FALLTHRU */
      case 4:
-      assert (symname != NULL && strcmp (symname, "stdarg") == 0);
+      if (!allow_unknown || symname)
+        assert (symname != NULL && strcmp (symname, "stdarg") == 0);
        break;
      case 5:
        /* Verify we trapped on the very last instruction of child.  */
-      assert (symname != NULL && strcmp (symname, "backtracegen") == 0);
+      if (!allow_unknown || symname)
+        assert (symname != NULL && strcmp (symname, "backtracegen") == 0);
        mod = dwfl_addrmodule (dwfl, pc);
        if (mod)
  	symname2 = dwfl_module_addrname (mod, pc);
@@ -138,7 +145,7 @@ callback_verify (pid_t tid, unsigned frameno, Dwarf_Addr pc,
        // there is no guarantee that the compiler doesn't reorder the
        // instructions or even inserts some padding instructions at the end
        // (which apparently happens on ppc64).
-      if (use_raise_jmp_patching)
+      if (use_raise_jmp_patching && (!allow_unknown || symname2))
          assert (symname2 == NULL || strcmp (symname2, "backtracegen") != 0);
        break;
    }
@@ -424,10 +431,12 @@ exec_dump (const char *exec)
  }
  
  #define OPT_BACKTRACE_EXEC 0x100
+#define OPT_ALLOW_UNKNOWN 0x200
  
  static const struct argp_option options[] =
    {
      { "backtrace-exec", OPT_BACKTRACE_EXEC, "EXEC", 0, N_("Run executable"), 0 },
+    { "allow-unknown", OPT_ALLOW_UNKNOWN, 0, 0, N_("Allow unknown symbols"), 0 },
      { NULL, 0, NULL, 0, NULL, 0 }
    };
  
@@ -445,6 +454,10 @@ parse_opt (int key, char *arg, struct argp_state *state)
        exec_dump (arg);
        exit (0);
  
+    case OPT_ALLOW_UNKNOWN:
+      allow_unknown = true;
+      break;
+
      default:
        return ARGP_ERR_UNKNOWN;
      }
@@ -463,6 +476,7 @@ main (int argc __attribute__ ((unused)), char **argv)
    (void) setlocale (LC_ALL, "");
  
    elf_version (EV_CURRENT);
+  allow_unknown = false;
  
    Dwfl *dwfl = NULL;
    const struct argp_child argp_children[] =
-- 
2.1.4

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Ulf Hermann]

Hi,

I have another patch here, that introduces the actual feature; a fallback mode for unwinding by frame pointer if unwinding by cfi fails. Unfortunately your mail server thinks it's spam, presumably because of the inline test binaries. What can I do about that?

br,
Ulf Hermann

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Mark Wielaard]

On Fri, 2017-02-10 at 15:25 +0100, Ulf Hermann wrote:
> I have another patch here, that introduces the actual feature; a
> fallback mode for unwinding by frame pointer if unwinding by cfi
> fails.

That sounds like a useful feature!

> Unfortunately your mail server thinks it's spam, presumably because of
> the inline test binaries. What can I do about that?

Do you have the bounce message, then we can investigate.
Otherwise could you post the patch without the test binaries?
Then we get them some other way.

Although I am surprised the mailinglist rejects the output of git
send-email. It really shouldn't, so having the bounce message would be
good (we can then discuss on overseers@... to see what really happened).

Thanks,

Mark

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Ulf Hermann]

>> Unfortunately your mail server thinks it's spam, presumably because of
>> the inline test binaries. What can I do about that?
>
> Do you have the bounce message, then we can investigate.
> Otherwise could you post the patch without the test binaries?
> Then we get them some other way.


The bounce message is somewhat messy, containing inline html and attachments. This is a somewhat readable text representation:


> Your message to elfutils-devel@sourceware.org couldn't be delivered.
> sourceware.org suspects your message is spam and rejected it.
> ulf.hermann 	Office 365 	sourceware.org
> Sender 		Action Required
> 				
> 		Messages suspected as spam
>
> How to Fix It
> Try to modify your message, or change how you're sending the message, using the guidance in this article: Bulk E-mailing Best Practices for Senders Using Forefront Online Protection for Exchange. Then resend your message.
> If you continue to experience the problem, contact the recipient by some other means (by phone, for example) and ask them to ask their email admin to add your email address, or your domain name, to their allowed senders list.
>
> Was this helpful? Send feedback to Microsoft.
>
> More Info for Email Admins
> Status code: 550 5.7.350
>
> When Office 365 tried to send the message to the recipient (outside Office 365), the recipient's email server (or email filtering service) suspected the sender's message is spam.
>
> If the sender can't fix the problem by modifying their message, contact the recipient's email admin and ask them to add your domain name, or the sender's email address, to their list of allowed senders.
>
> Although the sender may be able to alter the message contents to fix this issue, it's likely that only the recipient's email admin can fix this problem. Unfortunately, Office 365 Support is unlikely to be able to help fix these kinds of externally reported errors.
>
> Original Message Details
> Created Date: 	2/10/2017 2:20:21 PM
> Sender Address: 	ulf.hermann@qt.io
> Recipient Address: 	elfutils-devel@sourceware.org
> Subject: 	[PATCH 4/4] Add frame pointer unwinding as fallback on x86_64
>
> Error Details
> Reported error: 	550 5.7.350 Remote server returned message detected as spam -> 552 spam score exceeded threshold
> DSN generated by: 	VI1PR0201MB1869.eurprd02.prod.outlook.com
> Remote server: 	sourceware.org
>
> Message Hops
> HOP 	TIME (UTC) 	FROM 	TO 	WITH 	RELAY TIME
> 1 	2/10/2017
> 2:20:22 PM 	[10.9.78.60] 	VI1PR0201MB1869.eurprd02.prod.outlook.com 	Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) 	1 sec
>
> Original Message Headers
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>  d=qtcompany.onmicrosoft.com; s=selector1-qt-io;
>  h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
>  bh=j1DH0w0/pXTH2S/0HIhEj4Ruuawzgt1pBNwl4lbKAqU=;
>  b=F8/u6gSVjlPl4d34hVp3S0ehZJGze8mXCGjPHO++IwhFa61XiFtanOSgXWvVgEgeRAv4sdbP3Dx0J3Q32sJFUdkdUMP7qg9ea+2SGGeCX5/aUvxOCFZqcT1bdRFyIfAURQNNPHSGaTk9IsaFb4n6VhZWwKBV0RD3P5G1b//DpLA=
> Authentication-Results: spf=none (sender IP is )
>  smtp.mailfrom=ulf.hermann@qt.io;
> Received: from [10.9.78.60] (62.220.2.194) by
>  VI1PR0201MB1869.eurprd02.prod.outlook.com (10.167.206.147) with Microsoft
>  SMTP Server (version=TLS1_2,
>  cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Fri, 10
>  Feb 2017 14:20:22 +0000
> From: Ulf Hermann <ulf.hermann@qt.io>
> Subject: [PATCH 4/4] Add frame pointer unwinding as fallback on x86_64
> To: <elfutils-devel@sourceware.org>
> Message-ID: <6007c160-b26f-a757-d00b-d40b4c582777@qt.io>
> Date: Fri, 10 Feb 2017 15:20:21 +0100
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
>  Icedove/45.6.0
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"; format=flowed
> Content-Transfer-Encoding: 7bit
> X-Originating-IP: [62.220.2.194]
> X-ClientProxiedBy: DB5PR03CA0083.eurprd03.prod.outlook.com (10.164.34.51) To
>  VI1PR0201MB1869.eurprd02.prod.outlook.com (10.167.206.147)
> Return-Path: ulf.hermann@qt.io
> X-MS-Office365-Filtering-Correlation-Id: ec09c7eb-12da-48b3-ab58-08d451bff373
> X-Microsoft-Antispam:
> 	UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR0201MB1869;
> X-Microsoft-Exchange-Diagnostics:
> 	1;VI1PR0201MB1869;3:R1nBXKiZxfHImwXYgHnoCPlwj548vce+nOHis8TgdLGSGnWq5EpPzVdJg4gykOxZ76C0AQs+CdNH+WCTGZ52qcic1z3f8trei8HMHtrcRYK4DyWEWjzujBCtD+ckfl4r+8iYRtAVkOcnrWCTK951whAvXK9QpZYjO3LuLsfOaVAzsjwq1hYSCtcsjFSUUkswBvZNkkCmUwYdckggdmLTN7IpgyUQN3KLo6+IDtn9tuvmcVJk//HmpelY1wFN3XFeJGcRbyzGYFucG4+ETmhRww==;25:PW9H6AvU67yyWrJz4zsRyDMdEgQSeVltnnJvsN/Vs7hGTdQ5EZd6xRVKlQ3v1QaD6KNjU+rgPp4BbbI/swQOWx1DjztURFfPqmaDWAxLeBI+djpCH9Dp+MQH7sPPSQyHCeW0FU0Rxg+5o4Wh8JQaidmKe3DrUyN0OW/9N6qw9XcS7+d7TeyhXBI6jVSBTstqhe8L3M8x7XD49aIHGOIkMrEIKPxo18ht6Xrgt5yhp2pv7HqDEaKoBYZbh7nNYIdmIUhnjuTC6P3ROIPqyNoidVEleaSzL4ATISomo6IWWx6bMtVFm3Ci5BDPM08CPzWak6u/FhQifXqnfO14RP03qY9q377tksmbHyxmiEhgP1FStP3vFd/u43XbkeyRVXA1RES12WTWhwlXPKVHQCqmWajEPkXYEMay0FYVjx1FSaQg8ia6F1edoskLWr+rrBfbjjF+qCP9IpLMwjINf40qwA==
> X-Microsoft-Exchange-Diagnostics:
> 	1;VI1PR0201MB1869;31:wqCMe8SufX32nsuTdNG1+jAIb7wQQGwls1qBgVuIlT60aKDyRLR6KouM3QsO/AhOnIBQFcRK1vH4cuuuwReqqg9Mum1YDzC67G/mXpjyU0GQ2NY6+sS6rHZCKLCZLy9ZjVbAEBXT7mXNuGLpTaaj7qNWR0Kf29+89Yi+FF1MI/BLCRYJtIEKSzVfA86EJg4bbQWlTJrQ3/Ob3d/tjWFVNPaiqU+lzluqcvmP7exMn6LZQQogYUDOKeH9oaPBn2lXxeEh1cryH5+H5mptsACgmg==;20:Esxi3d27bQqZzFfpHipZzM+Jgm+SWhqgoLVzRcwEu3qnfvCsLCp91bGnDuYqullDAmIjwtg5jZUKY2Za26f6KCIYrASeqzhcg76zgS00K1Kg40061zjM/E6t2Kw3pF2lpuJBfArEosvgbgPw5+jSNbNPdhXB3NDxOUCYbiNFabvWD8TtZCG2iwBWLLEXsGa3ybM6M2IYebABLBFZ6xVkPCEq9g8kSNAUoSznpPXCbBEYiGXWjQcQnZQIyZbMhkpM
> X-Microsoft-Antispam-PRVS:
> 	<VI1PR0201MB18698DE71FE880D1D2D6199AF5440@VI1PR0201MB1869.eurprd02.prod.outlook.com>
> X-Exchange-Antispam-Report-Test: UriScan:(250305191791016)(22074186197030);
> X-Exchange-Antispam-Report-CFA-Test:
> 	BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(6072148);SRVR:VI1PR0201MB1869;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0201MB1869;
> X-Microsoft-Exchange-Diagnostics:
> 	1;VI1PR0201MB1869;4:FGm1KRfRGqnNizUfNWo9BToWgcBEY2ggWICYtVlDkokUfyvZAVw53hmpOM4hAOI4OfZVLbJhAxRT2jwVSrax6NIBKTO6+WjWiHaPp8tyLAL/91dJGG1NUUx8spz/RravCNc8zk3zlLAEDJoryLpu5zpsSztv5B+8hOESe4+ezZ9zj1MfRTtFFczCC3SNrXWstNSpfZWcgZY6TKgOC3d1bC7jkO3GeOTUe4JLbO1ZvORZBhUnyYT4fo6aCq6WJ+y7hrM/UM3UNtQ5rGFhz5SoQi9g+S8ndnq8k6x+VBOfw8enc0DNgVhvOkGq0OWeaGH0KL+tqKbzu5JNntZYIoFy2hpLfF8T0oamTeNZSkZo6dwYHyz5oZR/pQhbNWJRzQYmYKTSxpUViIlqtevekswvvd4p0rg/83sQz3C7G9oCB+DMoUcvqpCeQ7gaXgbo9eBH0RibHl3J76FmOle8xxTLZDqDPB1cjI7eOmJfCB/ICOHJGcr6ykr3EaS3ZjNPVIjPFcJG7Lw83uXFg7K0wWlnwKmx2uo2jzWdJqEvhFOJ/68MSIpjZi0LJmSyjulFHzS+x0LwUBZAt9SEWkhZDfx0hGJy7JFPoMiUdKRqiLheG9xDgJeUuLUbvd+QnOCjjW1iYd3s5c7T6mBNb/bgzXGpD8daEsbA9ytyxr7O1vnYtWvBHKu3VJVtv090feoNjiID
> X-Forefront-PRVS: 0214EB3F68
> X-Forefront-Antispam-Report:
> 	SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(199003)(377424004)(189002)(54534003)(74482002)(450100001)(50986999)(64126003)(54356999)(101416001)(50466002)(31696002)(189998001)(77096006)(4001350100001)(5660300001)(25786008)(2351001)(97736004)(81156014)(81166006)(8676002)(38730400002)(6916009)(83506001)(6486002)(90366009)(6306002)(110136004)(53946003)(53936002)(23676002)(16200700003)(68736007)(3846002)(230700001)(86362001)(6116002)(47776003)(575784001)(105586002)(36756003)(33646002)(92566002)(106356001)(42186005)(31686004)(66066001)(305945005)(7736002)(2906002)(440394002)(2004002)(21314002)(248664003)(579004)(569005);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR0201MB1869;H:[10.9.78.60];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en;
> Received-SPF: None (protection.outlook.com: qt.io does not designate permitted
>  sender hosts)
> X-Microsoft-Exchange-Diagnostics:
> 	=?us-ascii?Q?1;VI1PR0201MB1869;23:uXJolUh3BToRc8Ng0hZaP/ubJhYHoiPHg3KgCyF?=
>  =?us-ascii?Q?peY9CPKIEBAlugjd8+hzfRqlcHq0IUQ0hFy830gW7qvvKFmnuDMqabZwecY1?=
>  =?us-ascii?Q?4PwK8p87rYW7Eb+kFnNdBfH/2NDPPyYuZyObUYv3b1CMJFRIaQtPg2HNpV5U?=
>  =?us-ascii?Q?uBRqy2aghkAeeUgWKkV/c5RjhiZ7JOBOITfhoZ+qW5z8hxQ+H3Tp5miz1xmt?=
>  =?us-ascii?Q?cZlR4JrEqf8FWGhOEh495kfJo1AeSx2NncG1Oc2Vd7DEiFk+LifFH+bKiLY5?=
>  =?us-ascii?Q?g9UbpZaztVqCFqE5i4lme080/1Am2uB15BIuhGmyYhgmM774ThA3G1AGU/+6?=
>  =?us-ascii?Q?qQ9GIaUPgJmFkr8hBF5BmkszC4JAZAoFg0hVGwE3B6h7MChZnxLUMSVaqJo7?=
>  =?us-ascii?Q?CWxp0chMWFR1J1Gg7MO3F1V0L/yc86r96nkYp2ZhZRbeMAz4jMPzLVilWBPj?=
>  =?us-ascii?Q?ShNFJTzaWgkXY21sswmI3CgNJIAM5Jxh03ARcpDySFu+P3iQFNNtBPSfCilL?=
>  =?us-ascii?Q?0i3R+m9Ry4g4KZHVZMwPK2vQhH4wpPL1zWkcfuA+jFI940tCCY0VaSLDPup1?=
>  =?us-ascii?Q?8pJkQAPZJITvsyQ2qZ5Y4Qj/LOG/4/wNOAQdZcuibOpRgKgF8IFY+LdtHV2e?=
>  =?us-ascii?Q?080BhHmcBfo30j2bG2fA7eKZ0SKkhlx4PCgaAsQ4WhfJvTW/vy7nerAON/wd?=
>  =?us-ascii?Q?B7uivDtH4//SKjmUKe2dRGXfXH8wxfK4Pq2xLHcoA6nkdV2s8uRUK4bRXKr6?=
>  =?us-ascii?Q?SM7AYoUgi1ES26tEl36aUahHwskjHuRA9xlv6NP3IhRjl6NAvrQj9Iclp7gz?=
>  =?us-ascii?Q?to+0u2O/DjLpMD2CfDDBvhzo0BZz9hd3FiNJ283druIwSLV/Yh92KdtA7SCU?=
>  =?us-ascii?Q?y3wfF5FaGWYwShmwS5AFnqXVODKfw5afKx8TnsEzgc/mEpPoW8S5sLLaqT0C?=
>  =?us-ascii?Q?Jx4mrd3jqyDVf3+SpbKn1WUcd17M/EsEVRDv9AO2CSnUPbRHWhZDXigHouCa?=
>  =?us-ascii?Q?LKP0avXP6nBQ5VDX79cjKbgpIsCBpm8Pe5QvBHlIjXdSzXiLe1Z7EJalwIpT?=
>  =?us-ascii?Q?ZnnvQlzx4jLjIwaFHfpON4JP3B26hDMMzIupsVwA/nc2YSnfs2NXzViKsIK/?=
>  =?us-ascii?Q?PBUPIQpA8JV+xJQTIZgEVzQjXOmFh69iQleB2Cu0HTWRxyoiUTs3R2kWhS88?=
>  =?us-ascii?Q?HHAg6G/ZYN8fh9Rkhatkfm95s768OkkqM8EWpf9bIHyTcwj7EWL/7MnM8QHK?=
>  =?us-ascii?Q?iqJzm4SeJXKrb1pO1I2Grn0t6hviNTEeXZ+5ImfyNG1PGGwuG8eD0S/yBhrR?=
>  =?us-ascii?Q?nPWelNePVPx7PVZUySS1yqk0OuuEe1TPGZxbPLav20ZkLYIWuatImF24rvSV?=
>  =?us-ascii?Q?JPIx9zajIyDRaau9UkIhia+EHh1+rio2rx0PYxiVdQVJ+y2NkQi6npB6k5L4?=
>  =?us-ascii?Q?ARJNiRLc9bDlDUiVs9T36+0HAsXzHYJBYSlsOjL3VKBrp8LbHOH/j?=
> X-Microsoft-Exchange-Diagnostics:
> 	1;VI1PR0201MB1869;6:9sbPgN4Zh4Gcs3TVSuPZ/rMfRLvUj4sQAElxp3wfIMHaL+mE+JnxUZik2/K9vneIp1LSl8PXeVToBiCgA8a4iGl+If+6eJLOuhQOagrXs0inZoZ7O05Pqw8ALVRzcpD7hFFfunNE1tNezNTVLJawjCpbOIGKSh3BYFkTo7Z45T/Roa38G5W7wQA/qdu/r7hPXmTwJKc4JsCalwlLy1b9HCjzYUPje1SLpWk72bvb4JeVAhxpn12+f3CsIqYjdTI5C2ti7U8w87vhzUe78nz8PgMNczgf2w5Ar1fK/CIBttlGRFqayU1KhJpXAlLTJ75IHYn9JtKGIGleYIn+IfGIHtKVUZkgK7iGffj0k5uCn8A1vrLzRoRX8K2JCVE2jXnLGorWtXma4twrX/DSe2ZW6A==;5:FNSt4YjhluD26bK4GkNjp59qq3NWlJLcGOa7rNmMMEKeqWqyi3ti9ZDDYBhbbB2zRHsTEhWS1nRXytrkS/iGxtG9JBKrbQDjL67Gc1TBMiXOZejftRj0hJtJV2xZkxNAO2zMkQdowcE8oPWJWbis5w==;24:KgLVeMckfT8VxOLFpwRiLiKPNuGjEUPojxgs4gFmB4ohaRGGQcAooOGoZFYiXlhoCEV2azqP4G/6FzLYrxXrbrpDUTqTOWNs8OFFRbavmOc=
> SpamDiagnosticOutput: 1:99
> SpamDiagnosticMetadata: NSPM
> X-Microsoft-Exchange-Diagnostics:
> 	1;VI1PR0201MB1869;7:+7rU8BJmcYx/FnIYz8ugqkyT1uBdnkHKiN4Jeppfa34DOd/TaTaBQUOvuY+I9jeJ2T/a+8evM1bawEdTrNAXC8Mz49fo6vEEg/cAOgcNLjUTFPc/UK03lsTLyukMXRIRr6H9TvIX25/LXauxxSDU0bcxB1agGZH0AyW9bQRk3PV5OLNU/QxZJ48zNlpW2sVzh+m1BFK/8aq1shVlMzBBpuMPearGdRuupXUcROpG89y7KLgY4U/e19fI9qXCD4dQEhCqJhljc4T5DBdlOmzRnu7XBP2PB1RYNLfhf5wGOX04oYafORJhLRTpqCbni9ydQowpdwBmOX9dtp6e94o3Ea2C8zF/HfF41Ou7hAVr4JX0L3ELQwGsMwAfvY/D4aJi8rHEU9uZJcSDJ4MWkLP+8kkT+UvyuvN4OxDExq/7pg8HPyhoJfWsoVFquhITJOxi6Je+bANX5Tr2aCVDaQf9hFe+ziOBhW+maps00T2nmOzcx00MIp/I8HjW9gSPa9p+tP0MQyWa9ZkngfChoNFhQA==
> X-OriginatorOrg: qt.io
> X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2017 14:20:22.8968 (UTC)
> X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
> X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0201MB1869
>
>
>
> Reporting-MTA: dns;VI1PR0201MB1869.eurprd02.prod.outlook.com
> Received-From-MTA: dns;[10.9.78.60]
> Arrival-Date: Fri, 10 Feb 2017 14:20:22 +0000
>
> Final-Recipient: rfc822;elfutils-devel@sourceware.org
> Action: failed
> Status: 5.7.350
> Diagnostic-Code: smtp;550 5.7.350 Remote server returned message detected as spam -> 552 spam score exceeded threshold
> Remote-MTA: dns;sourceware.org

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Ulf Hermann]

> Try sending suspicious content via something like fpaste.org.

I don't think it's very suspicious, but I don't intend to start a pointless argument as first thing I do here ;)
  
fpaste.org won't accept it either, but paste.kde.org does. So, here we go:

https://paste.kde.org/pgs6oqk2z

br,
Ulf Hermann

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Mark Wielaard]

On Fri, 2017-02-10 at 15:19 +0100, Ulf Hermann wrote:
> This is useful to test unwinding without debug information. The
> binaries being examined might still have frame pointers that allow
> us to bridge the unknown symbols.
> 
> Signed-off-by: Ulf Hermann <ulf.hermann@qt.io>

Applied even though the new option is not yet used (I assume it will be
in the next patch that mysteriously never made it to the mailinglist)
and the ChangeLog isn't 100% according to spec. But I am in a good
mood :)

Thanks,

Mark

:)
https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Mark Wielaard]

On Fri, 2017-02-10 at 17:50 +0100, Ulf Hermann wrote:
> > Try sending suspicious content via something like fpaste.org.
> 
> I don't think it's very suspicious, but I don't intend to start a pointless argument as first thing I do here ;)
>   
> fpaste.org won't accept it either, but paste.kde.org does. So, here we go:
> 
> https://paste.kde.org/pgs6oqk2z

I could reconstruct it from that pastebin. But it was a bit of a
struggle, some parts didn't apply as is because tabs seemed to be turned
into spaces. I tried to repost it to the list. But the first time it was
bounced as "spam" and the second time after removing the git-bin-diffs
sourceware seemed to accept it, but then it never showed up on the list.
(See below for the logs on my end.)

I have the patch and the binaries locally and you added the description
how to recreate them, so that is good. make check passes. But make
distcheck pointed out that run-backtrace-fp-core-x86_64.sh should be
added to EXTRA_DIST.

I haven't looked too deeply at the actual patch yet, sorry. But I think
I like the idea. I'll be away for a day, but will get back to it soon.
Lets see if we can somehow get it past the spam filters...

Thanks,

Mark

Bounce from first attempt:

Return-Path: <mark@klomp.org>
Received: from tarox.wildebeest.org (herd.wildebeest.org [80.127.118.209])
        (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
        (No client certificate requested)
        by gnu.wildebeest.org (Postfix) with ESMTPSA id 48FF73001559
        for <elfutils-devel@sourceware.org>; Sun, 12 Feb 2017 23:05:13 +0100 (CET)
Received: by tarox.wildebeest.org (Postfix, from userid 1000)
        id 2C4EA406D9E4; Sun, 12 Feb 2017 23:05:13 +0100 (CET)
From: Mark Wielaard <mark@klomp.org>
To: elfutils-devel@sourceware.org
Subject: [PATCH] Add frame pointer unwinding as fallback on x86_64
Date: Sun, 12 Feb 2017 23:05:09 +0100
Message-Id: <1486937109-29423-1-git-send-email-mark@klomp.org>
X-Mailer: git-send-email 1.8.3.1

postfix log for second attempt (with git-bin-diffs removed):

Feb 13 00:21:51 gnu postfix/smtpd[7671]: CE7703000269: client=herd.wildebeest.org[80.127.118.209], sasl_method=DIGEST-MD5, sasl_username=mark
Feb 13 00:21:51 gnu postfix/cleanup[7675]: CE7703000269: message-id=<1486941708-32567-1-git-send-email-mark@klomp.org>
Feb 13 00:21:51 gnu postfix/qmgr[1823]: CE7703000269: from=<mark@klomp.org>, size=9253, nrcpt=1 (queue active)
Feb 13 00:21:57 gnu postfix/smtp[7676]: CE7703000269: to=<elfutils-devel@sourceware.org>, relay=sourceware.org[209.132.180.131]:25, delay=5.9, delays=0.02/0.01/1.4/4.4, dsn=2.0.0, status=sent (250 Queued! 1486941717 qp 97183 <1486941708-32567-1-git-send-email-mark@klomp.org>)
Feb 13 00:21:57 gnu postfix/qmgr[1823]: CE7703000269: removed

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Ulf Hermann]

Thanks for pointing out the issues. I will track down the white space problem.

> I could reconstruct it from that pastebin. But it was a bit of a
> struggle, some parts didn't apply as is because tabs seemed to be turned
> into spaces. I tried to repost it to the list. But the first time it was
> bounced as "spam" and the second time after removing the git-bin-diffs
> sourceware seemed to accept it, but then it never showed up on the list.
> (See below for the logs on my end.)

I have the same frame pointer unwinding fallbacks for arm and arm64 in the elfutils bundled with perfparser. I just need to write test cases for them, then I will post them, too. So, it's probably a good idea to either have the mailing list accept patches with inline binaries or allow some other channel of patch submission.

br,
Ulf

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Mark Wielaard]

On Mon, 2017-02-13 at 11:01 +0100, Ulf Hermann wrote:
> Thanks for pointing out the issues. I will track down the white space problem.
> 
> > I could reconstruct it from that pastebin. But it was a bit of a
> > struggle, some parts didn't apply as is because tabs seemed to be turned
> > into spaces. I tried to repost it to the list. But the first time it was
> > bounced as "spam" and the second time after removing the git-bin-diffs
> > sourceware seemed to accept it, but then it never showed up on the list.
> > (See below for the logs on my end.)
> 
> I have the same frame pointer unwinding fallbacks for arm and arm64 in
> the elfutils bundled with perfparser. I just need to write test cases
> for them, then I will post them, too. So, it's probably a good idea to
> either have the mailing list accept patches with inline binaries or
> allow some other channel of patch submission.

I didn't know about perfparse. I assume that is this code base:
http://code.qt.io/cgit/qt-creator/perfparser.git/
Very nice.

Please feel free to sent the commit (with git send-email) to me and I
can add them to a review branch in elfutils.git so others can review
them easily. Or if you already have them in your own git tree feel free
to sent the commits to review/pull to the list. And we can pull them
from there. I assume this must be the patch that adds the arm64 support:
http://code.qt.io/cgit/qt-creator/perfparser.git/commit/3rdparty/elfutils?id=17ad3b57d613fede17a01b6cdd2d894850364f81

I'll ask overseers if something can be done about the sourceware list
being a little bit too strict on blocking these emails as spam.

Thanks,

Mark

Re: [PATCH 3/4] Optionally allow unknown symbols in the backtrace tests

[Ulf Hermann]

> I didn't know about perfparse. I assume that is this code base:
> http://code.qt.io/cgit/qt-creator/perfparser.git/
> Very nice.

Yes. I'm also trying to port this to windows. So, I have lots of changes to make the code more portable: https://codereview.qt-project.org/#/c/184401/ and the 50 changes depending on that. I will try to get those into an acceptable form and post them here.

> Please feel free to sent the commit (with git send-email) to me and I
> can add them to a review branch in elfutils.git so others can review
> them easily. Or if you already have them in your own git tree feel free
> to sent the commits to review/pull to the list. And we can pull them
> from there. I assume this must be the patch that adds the arm64 support:
> http://code.qt.io/cgit/qt-creator/perfparser.git/commit/3rdparty/elfutils?id=17ad3b57d613fede17a01b6cdd2d894850364f81

In principle yes. However, perfparser doesn't include elfutils' test framework and writing the tests I've found some problems with the frame pointer unwinders. So don't just take that commit ... I'll send the new versions to you personally.

regards,
Ulf