[Bug libc/33959] WAIT_FOR_DEBUGGER=1 doesn't work (gdb errors out; wait_for_debugger not found)

[sam at gentoo dot org]

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

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Sam James <sam at gentoo dot org> ---
(In reply to dj@redhat.com from comment #3)
> WAIT_FOR_DEBUGGER is intended to use with test-container tests, which this
> test is not.  For non-container tests you just run gdb (see debugglibc.sh). 

Ah, thanks. The wiki does say this (though maybe subtly; I'll make it clearer
anyhow), just I didn't realise, then I saw:

      if (inside_container)
        fprintf (gdb_script, "set sysroot %s/testroot.root\n",
support_objdir_root);

and assumed it must work outside to.o

> If you want to run this test in a container anyway, this works:
>

> $ WAIT_FOR_DEBUGGER=1 ./testrun.sh --tool=container nptl/tst-pthread-exited
> Waiting for debugger, test process is pid 2785891
> gdb -x nptl/tst-pthread-exited.gdb
> 
> 
> $ gdb -x nptl/tst-pthread-exited.gdb
> 
> Why?  Not sure, but I suspect that running it in a container removes the
> need to do the ld.so magic to use the correct loader and shared objects,
> which means the symbols are loaded in the "normal" way.
> 
> When you run outside the container, the exec-file is ld.so instead of your
> testcase, which probably confuses the script, and you get a backtrace that's
> valid for the wrong part of the call stack:

Thank you! That's what I was missing.

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