[v2] gdb.python/py-unwind: Disable stack protection

Message ID 1500028181-20419-1-git-send-email-simon.marchi@ericsson.com
State New, archived
Headers

Commit Message

Simon Marchi July 14, 2017, 10:29 a.m. UTC
  [I made some typo fixes but forgot to amend my commit before sending the patch,
 hence this v2.]

I see the following failure on Ubuntu 16.04's gcc 5.4.0:

Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.python/py-unwind.exp ...
FAIL: gdb.python/py-unwind.exp: continue to breakpoint: break backtrace-broken
FAIL: gdb.python/py-unwind.exp: Backtrace restored by unwinder (pattern 1)

The problem is that the test expects a very particular stack layout.
When stack protection is enabled, it adds a canary value which looks
like an additional local variable.  This makes the test complain about
a bad stack layout and fail.

The simple solution is to disable stack protection for that test using
-fno-stack-protector.  I checked older compilers (gcc 4.4, clang 3.5)
and they support that flag, so I don't think it's necessary to probe for
whether the compiler supports it.

Maybe a better solution would be to change the test to make it cope with
different stack layouts (perhaps it could save addresses of stuff in
some global variables which GDB/the unwinder would read).  I'll go with
the simple solution for now though.

gdb/testsuite/ChangeLog:

	* gdb.python/py-unwind.exp: Disable stack protection when
	building test file.
---
 gdb/testsuite/gdb.python/py-unwind.exp | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
  

Comments

Yao Qi July 19, 2017, 10:09 a.m. UTC | #1
Simon Marchi <simon.marchi@ericsson.com> writes:

> Maybe a better solution would be to change the test to make it cope with
> different stack layouts (perhaps it could save addresses of stuff in
> some global variables which GDB/the unwinder would read).  I'll go with
> the simple solution for now though.

I prefer moving this test to unit test, and the input is a series of
instructions (copied from py-unwind.exe).  The unit test or self test can
somehow test python unwinder works as expected.

>
> gdb/testsuite/ChangeLog:
>
> 	* gdb.python/py-unwind.exp: Disable stack protection when
> 	building test file.

The patch is good to me, but I think the test itself is still a little
fragile.
  
Simon Marchi July 21, 2017, 9:59 p.m. UTC | #2
On 2017-07-19 12:09, Yao Qi wrote:
> Simon Marchi <simon.marchi@ericsson.com> writes:
> 
>> Maybe a better solution would be to change the test to make it cope 
>> with
>> different stack layouts (perhaps it could save addresses of stuff in
>> some global variables which GDB/the unwinder would read).  I'll go 
>> with
>> the simple solution for now though.
> 
> I prefer moving this test to unit test, and the input is a series of
> instructions (copied from py-unwind.exe).  The unit test or self test 
> can
> somehow test python unwinder works as expected.

Ok, I take a note to try that eventually.

>> gdb/testsuite/ChangeLog:
>> 
>> 	* gdb.python/py-unwind.exp: Disable stack protection when
>> 	building test file.
> 
> The patch is good to me, but I think the test itself is still a little
> fragile.

Yes, it's still very fragile.  I'll push the current patch anyhow, since 
it fixes it for now.

Thanks,

Simon
  

Patch

diff --git a/gdb/testsuite/gdb.python/py-unwind.exp b/gdb/testsuite/gdb.python/py-unwind.exp
index 625b04c..86e695c 100644
--- a/gdb/testsuite/gdb.python/py-unwind.exp
+++ b/gdb/testsuite/gdb.python/py-unwind.exp
@@ -20,7 +20,12 @@  load_lib gdb-python.exp
 
 standard_testfile
 
-if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile}] } {
+# Stack protection can make the stack look a bit different, breaking the
+# assumptions this test has about its layout.
+
+set flags "additional_flags=-fno-stack-protector"
+
+if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} "debug $flags"] } {
     return -1
 }