Question about the gdb.base/nodebug.exp test

Question about the gdb.base/nodebug.exp test

[Carl Love]

Alan:

I have been looking into why gdb.base/nodebug.exp fails on PowerPC. 
Specifically, it gives a segmentation fault


   (gdb) PASS: gdb.base/nodebug.exp: whatis array_index("abcdef",2)
   p/c (int) array_index("abcdef",2)

   Program received signal SIGSEGV, Segmentation fault.
   0x0000000000000000 in ?? ()
   The program being debugged was signaled while in a function called from GDB.
   GDB remains in the frame where the signal was received.
   To change this behavior use "set unwindonsignal on".
   CARLL 6 Evaluation of the expression containing the function
   (malloc@plt) will be abandoned.
   When the function is done executing, GDB will silently stop.
   (gdb) FAIL: gdb.base/nodebug.exp: p/c (int) array_index("abcdef",2)

The issue seems to be a result of the call 

   gdb_test_no_output "nosharedlibrary" \
               "unload symbols from system libraries"

in 

   proc nodebug_runto {func}

I created a patch to do the array_index test before the nosharedlibrary
call.  This fixes the issue on PowerPC but I am concerned that this may
be breaking the intent of the test?

I have been looking for documentation on the nosharedlibrary call but
have not found much.  Based on the context of the test, it seems to
tell gdb to forget about the various sysetem shared libraries.  On
PowerPC it seems to include the malloc function.  The patch also makes
reference to intl/plural-exp.h and enum expression_operator.  I have
looked at the copies of this file I find on a PowerPC system but don't
see any reference to expression_operator.

Would it be acceptable, i.e. not violate the spirit of the test to move
the array_index call before the nosharedlibrary call?

                Carl Love

-------------------------------------------------
Fix gdb.base/nodebug.exp failures for ppc64

   [gdb/testsuite] Fix test sequence in gdb.base/nodebug.exp

    Move array_index test before call to noshardlibrary.
---
 gdb/testsuite/gdb.base/nodebug.exp | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp
index 6255b6842df..2ba48c20519 100644
--- a/gdb/testsuite/gdb.base/nodebug.exp
+++ b/gdb/testsuite/gdb.base/nodebug.exp
@@ -88,6 +88,24 @@ proc test_call_promotion {} {
     gdb_test "p /d ((uint8 (*) ()) add8_noproto)((uint8) 2, (uint8) 3)" " = 5"
 }
 
+    # Run to main and do the array_index test before calling nodebug_runto.
+    # Proc nodebug_runto calls noshardlibrary which will cause a segmenation
+    # fault on the malloc call in array_index() when running on Powerpc.
+    if ![runto_main] then {
+	return
+    }
+
+    if [target_info exists gdb,cannot_call_functions] {
+	unsupported "p/c (int) array_index(\"abcdef\",2)"
+    } else {
+	# We need to up this because this can be really slow on some boards.
+	# (malloc() is called as part of the test).
+	set prev_timeout $timeout
+	set timeout 60
+	gdb_test {p/c (int) array_index("abcdef",2)} " = 99 'c'"
+	set timeout $prev_timeout
+    }
+
 if [nodebug_runto inner] then {
     
     # Expect to find global/local symbols in each of text/data/bss.
@@ -273,16 +291,6 @@ if [nodebug_runto inner] then {
 	gdb_test "$cmd array_index(\"abcdef\",2)" \
 	    "'array_index' has unknown return type; cast the call to its declared return type"
     }
-    if [target_info exists gdb,cannot_call_functions] {
-	unsupported "p/c (int) array_index(\"abcdef\",2)"
-    } else {
-	# We need to up this because this can be really slow on some boards.
-	# (malloc() is called as part of the test).
-	set prev_timeout $timeout
-	set timeout 60
-	gdb_test {p/c (int) array_index("abcdef",2)} " = 99 'c'"
-	set timeout $prev_timeout
-    }
 
     test_call_promotion
 
-- 
2.30.2

Re: Question about the gdb.base/nodebug.exp test

[Simon Marchi]

On 2021-10-18 5:07 p.m., Carl Love via Gdb-patches wrote:
> Alan:
>
> I have been looking into why gdb.base/nodebug.exp fails on PowerPC.
> Specifically, it gives a segmentation fault
>
>
>    (gdb) PASS: gdb.base/nodebug.exp: whatis array_index("abcdef",2)
>    p/c (int) array_index("abcdef",2)
>
>    Program received signal SIGSEGV, Segmentation fault.
>    0x0000000000000000 in ?? ()
>    The program being debugged was signaled while in a function called from GDB.
>    GDB remains in the frame where the signal was received.
>    To change this behavior use "set unwindonsignal on".
>    CARLL 6 Evaluation of the expression containing the function
>    (malloc@plt) will be abandoned.
>    When the function is done executing, GDB will silently stop.
>    (gdb) FAIL: gdb.base/nodebug.exp: p/c (int) array_index("abcdef",2)
>
> The issue seems to be a result of the call
>
>    gdb_test_no_output "nosharedlibrary" \
>                "unload symbols from system libraries"
>
> in
>
>    proc nodebug_runto {func}
>
> I created a patch to do the array_index test before the nosharedlibrary
> call.  This fixes the issue on PowerPC but I am concerned that this may
> be breaking the intent of the test?
>
> I have been looking for documentation on the nosharedlibrary call but
> have not found much.  Based on the context of the test, it seems to
> tell gdb to forget about the various sysetem shared libraries.  On
> PowerPC it seems to include the malloc function.  The patch also makes
> reference to intl/plural-exp.h and enum expression_operator.  I have
> looked at the copies of this file I find on a PowerPC system but don't
> see any reference to expression_operator.
>
> Would it be acceptable, i.e. not violate the spirit of the test to move
> the array_index call before the nosharedlibrary call?

From the comment above nodebug_runto, it sounds like that wouldn't break
the spirit of the test per-se.  The test is about testing debugging a
program compiled without -g.  The nosharedlibrary call is not there to
remove the symbols of the thing we try to call, but because of that
expression_operator conflict that you referred to, which I don't really
understand.

But the SIGSEGV you see is perhaps a symptom of an actual problem, and
just changing the test to avoid it doesn't sound right.  We would at
least need to know what happens.  Even without the shared library
symbols loaded, GDB seems to be able to call malloc on other
architectures, so why does it fail on ppc64?

Simon

RE: Question about the gdb.base/nodebug.exp test

[Carl Love]

Simon:

On Tue, 2021-10-19 at 13:12 -0400, Simon Marchi wrote:
> From the comment above nodebug_runto, it sounds like that wouldn't
> break
> the spirit of the test per-se.  The test is about testing debugging a
> program compiled without -g.  The nosharedlibrary call is not there
> to
> remove the symbols of the thing we try to call, but because of that
> expression_operator conflict that you referred to, which I don't
> really
> understand.
> 
> But the SIGSEGV you see is perhaps a symptom of an actual problem,
> and
> just changing the test to avoid it doesn't sound right.  We would at
> least need to know what happens.  Even without the shared library
> symbols loaded, GDB seems to be able to call malloc on other
> architectures, so why does it fail on ppc64?

So, I have done some more experiments.  It seems that the issue occurs
on both Power 9 and Power 10 systems running Ubuntu.  However, it works
fine on Power 9 and Power 10 systems running RHEL distros.   

I am still tring to figure out the root cause of the failure but it
looks like it maybe a functution of the distro???  Not really sure what
at this point.

                     Carl 

Re: Question about the gdb.base/nodebug.exp test

[Simon Marchi]

On 2021-10-22 16:39, Carl Love wrote:
> So, I have done some more experiments.  It seems that the issue occurs
> on both Power 9 and Power 10 systems running Ubuntu.  However, it works
> fine on Power 9 and Power 10 systems running RHEL distros.   
> 
> I am still tring to figure out the root cause of the failure but it
> looks like it maybe a functution of the distro???  Not really sure what
> at this point.

That's not uncommon.  Sometimes it's whether you have the debug info
package for libc installed or not, things like that.

Since the difference is that a call to malloc seems to result in a
SIGSEGV on one side, I'd try to look side by side (stepping in each GDB
side by side) if they are doing anything different.  Does one GDB choose
some way to pass the argument that is right, and the other some way that
is wrong?

I also find that the infcall.c file (responsible for GDB doing functions
calls in the inferior) lacks debug output.  I have wanted for a while
to add a "set debug infcall" setting that would print details about the
inferior call.  If you'd like to do that, maybe that would allow you to
spot easily what the two GDBs are doing different.

Simon

Re: Question about the gdb.base/nodebug.exp test

[Tom de Vries]

On 10/23/21 2:29 AM, Simon Marchi via Gdb-patches wrote:
> 
> 
> On 2021-10-22 16:39, Carl Love wrote:
>> So, I have done some more experiments.  It seems that the issue occurs
>> on both Power 9 and Power 10 systems running Ubuntu.  However, it works
>> fine on Power 9 and Power 10 systems running RHEL distros.   
>>
>> I am still tring to figure out the root cause of the failure but it
>> looks like it maybe a functution of the distro???  Not really sure what
>> at this point.
> 
> That's not uncommon.  Sometimes it's whether you have the debug info
> package for libc installed or not, things like that.
> 
> Since the difference is that a call to malloc seems to result in a
> SIGSEGV on one side, I'd try to look side by side (stepping in each GDB
> side by side) if they are doing anything different.  Does one GDB choose
> some way to pass the argument that is right, and the other some way that
> is wrong?
> 

FWIW, I recently debugged a failure in this testcase (with target board
unix/-m32/-fPIE/-pie), similar to what you describe.  Filed at
https://sourceware.org/bugzilla/show_bug.cgi?id=28467 .

The problem is roughly that malloc gets resolved to malloc@plt in the
executable, which seems to assume that the caller has the pic register
setup.  And gdb fails to do that.

The test-case uses nosharedlibrary, so I'd expect whether
glibc-debuginfo is installed or not, not to make a difference.

Perhaps the difference between distros is PIE vs no-PIE by default?

Thanks,
- Tom

RE: Question about the gdb.base/nodebug.exp test

[Carl Love]

Tom, Simon:

The debug info package is installed.

The bug that Tom pointed to looks exactly like what I am seeing.  
> 
> FWIW, I recently debugged a failure in this testcase (with target
> board
> unix/-m32/-fPIE/-pie), similar to what you describe.  Filed at
> https://sourceware.org/bugzilla/show_bug.cgi?id=28467  .
> 
> The problem is roughly that malloc gets resolved to malloc@plt in the
> executable, which seems to assume that the caller has the pic
> register
> setup.  And gdb fails to do that.
> 
> The test-case uses nosharedlibrary, so I'd expect whether
> glibc-debuginfo is installed or not, not to make a difference.
> 
> Perhaps the difference between distros is PIE vs no-PIE by default?

I am not sure what the pic is but I am guessing that is an X86 term?

I am guessing the pic is the equivalent of the contents of r2 on
Powerpc.  r2 is called the TOC (table of contents).  I am guessing the
r2 is not setup.  Anyway, I am guessing the GDB routines in infcall.c
is where the calls are made to evaluate the inferior function that
calls malloc.  I am guessing somewhere in there GDB needs to setup a
frame for the call and r2 is not getting set.  Not sure if you have any
hints from Intel that might be helpful to figure out how all this
works.   Thanks for the help.

                          Carl