Bug 18987 - GDB 7.10 cannot debug programs under X32 (internal-error: find_new_threads_once...)
Summary: GDB 7.10 cannot debug programs under X32 (internal-error: find_new_threads_on...
Status: RESOLVED DUPLICATE of bug 19676
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.10
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-20 22:40 UTC by Jeffrey Walton
Modified: 2016-03-01 16:54 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeffrey Walton 2015-09-20 22:40:51 UTC
We received a few bug reports from a Debian maintainer who was testing our software under Debian's X32 chroot environment. Related, see Debian's X32 Port page at https://wiki.debian.org/X32Port.

Using Debian's X32 port of GDB 7.10 resulted in:

    (gdb) r
    Starting program: .../cryptest.exe
    warning: linux_ptrace_test_ret_to_nx: Cannot PTRACE_PEEKUSER: Input/output error
     /build/gdb-gaG2aU/gdb-7.10/gdb/linux-thread-db.c:1675: internal-error:
    find_new_threads_once: Assertion `!target_has_execution ||
    thread_db_use_events ()' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

The issue was duplicated with a fresh download and build of GDB 7.10.

It appears the issue is with `gdb/linux-thread-db.c`, and the assert placed around line 1675:

    /* See comment in thread_db_update_thread_list.  */
    gdb_assert (!target_has_execution || thread_db_use_events ());

After reading the appropriate comments, its readily apparent (to me) that I'm not really qualified to hack GDB. However, I needed to get our gear under the debugger, so:

    #if !defined(__ILP32__) && !defined(_ILP32)
      /* See comment in thread_db_update_thread_list.  */
      gdb_assert (!target_has_execution || thread_db_use_events ());
    #endif

It worked like a charm, and I was able to get our gear running under GDB.

We used `__ILP32__` and `_ILP32` because:

    # cpp -dM < /dev/null | egrep "(ILP|i386|i686|x86_64|amd64|LP64)"
    #define __x86_64 1
    #define __amd64 1
    #define __x86_64__ 1
    #define __ILP32__ 1
    #define _ILP32 1
    #define __amd64__ 1

Finally, Debian's bug report on the GDB 7.10 issue can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799556.

My apologies for two bug reports. According to the Debian wiki page, Debian wants the bug reports too (https://www.debian.org/Bugs/Reporting). (I probably jumped the gun by not allowing the Debian folks to file this).
Comment 1 Pedro Alves 2015-09-21 08:35:49 UTC
I believe this is fixed in master (commit e0fd7c47bd):

 https://sourceware.org/ml/gdb-patches/2015-08/msg00762.html

Could you give that a try?
Comment 2 Jeffrey Walton 2015-09-21 23:24:39 UTC
(In reply to Pedro Alves from comment #1)
> I believe this is fixed in master (commit e0fd7c47bd):
> 
>  https://sourceware.org/ml/gdb-patches/2015-08/msg00762.html
> 
> Could you give that a try?

Yes sir. From a Debian chroot for X32 (https://wiki.debian.org/X32Port):

  git clone git://sourceware.org/git/binutils-gdb.git gdb-git
  ...
  cd gdb-git

Then

  # ./configure --target=x32-linux
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking target system type... Invalid configuration `x32-linux': machine `x32' not recognized

Retry:

  # ./configure
  checking build system type... x86_64-pc-linux-gnu
  checking host system type... x86_64-pc-linux-gnu
  checking target system type... x86_64-pc-linux-gnu
  ...
  make[2]: Entering directory '/home/gdb-git/libiberty'
  ...
  make[2]: Entering directory '/home/gdb-git/zlib'
  ...
  make[2]: Entering directory '/home/gdb-git/bfd'
  creating bfdver.h
  rm -f elf32-target.h
  ...
  .../gdb-git/missing: 81: /home/gdb-git/missing: makeinfo: not found
  WARNING: 'makeinfo' is missing on your system.

Yep, no makeinfo for this platform, and no apparent configure option to disable it:

  # ./configure --help | egrep -i "(info|doc)"
    -V, --version           display version information and exit
    --infodir=DIR           info documentation [DATAROOTDIR/info]
    --mandir=DIR            man documentation [DATAROOTDIR/man]
    --docdir=DIR            documentation root [DATAROOTDIR/doc/PACKAGE]
    --htmldir=DIR           html documentation [DOCDIR]
    --dvidir=DIR            dvi documentation [DOCDIR]
    --pdfdir=DIR            pdf documentation [DOCDIR]
    --psdir=DIR             ps documentation [DOCDIR]
                            map A to B, C to D ... in debug information

Continuing with build:

  Makefile:443: recipe for target 'bfd.info' failed
  make[3]: *** [bfd.info] Error 127
  ...
  Makefile:1673: recipe for target 'info-recursive' failed
  make[2]: *** [info-recursive] Error 1
  ..
  Makefile:2712: recipe for target 'all-bfd' failed
  make[1]: *** [all-bfd] Error 2
  ...
  Makefile:845: recipe for target 'all' failed
  make: *** [all] Error 2

The complete log is available at https://www.cryptopp.com/drop/gdb-config.log.zip.

Any suggestions to proceed? I'm not really concerned about the docs; rather I need the debugger.

**********

And one other note... A dirty compile for getruntime.c under X32:

gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I./../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -D_GNU_SOURCE ./getruntime.c -o getruntime.o
./getruntime.c: In function ‘get_run_time’:
./getruntime.c:98:14: warning: enum conversion when passing argument 1 of ‘getrusage’ is invalid in C++ [-Wc++-compat]
   getrusage (0, &rusage);
              ^
In file included from ./getruntime.c:47:0:
/usr/include/x86_64-linux-gnux32/sys/resource.h:87:12: note: expected ‘__rusage_who_t {aka enum __rusage_who}’ but argument is of type ‘int’
 extern int getrusage (__rusage_who_t __who, struct rusage *__usage) __THROW;
            ^
Comment 3 Jeffrey Walton 2015-09-22 01:12:04 UTC
> The complete log is available at
> https://www.cryptopp.com/drop/gdb-config.log.zip.
> 

I uploaded a new log. It should be more complete. The new log is the result of:

   ./configure 2>&1 | tee gdb-config.log
   ./make 2>&1 | tee -a gdb-config.log

The log was fairly boring without the tee.
Comment 4 Pedro Alves 2015-09-22 08:31:36 UTC
'configure MAKEINFO=true' is the standard workaround.  I don't know about the other issues -- it sounds like x32 needs local patches that may be missing upstream.  Those are orthogonal issues though, best moved to separate bugs.

Could you try whether applying the patch I pointed at (e0fd7c47bd) on the 7.10 branch fixes the internal error?
Comment 5 Jeffrey Walton 2015-09-22 16:47:34 UTC
(In reply to Pedro Alves from comment #4)
> 'configure MAKEINFO=true' is the standard workaround.  

Thanks.

> Could you try whether applying the patch I pointed at (e0fd7c47bd) on the
> 7.10 branch fixes the internal error?

No joy. Git is getting in the way while trying to follow https://stackoverflow.com/questions/3489173/how-to-clone-git-repository-with-specific-revision-changeset:

    # git fetch origin e0fd7c47bdfatal: Couldn't find remote ref e0fd7c47bd

Sorry about the extra grief.

We might as well close this report since it appears to be fixed.
Comment 6 Sergio Durigan Junior 2015-09-22 20:36:13 UTC
(In reply to Jeffrey Walton from comment #5)
> > Could you try whether applying the patch I pointed at (e0fd7c47bd) on the
> > 7.10 branch fixes the internal error?
> 
> No joy. Git is getting in the way while trying to follow
> https://stackoverflow.com/questions/3489173/how-to-clone-git-repository-with-
> specific-revision-changeset:
> 
>     # git fetch origin e0fd7c47bdfatal: Couldn't find remote ref e0fd7c47bd

Jeffrey,

You can clone the upstream git repository normally:

#> git clone git://sourceware.org/git/binutils-gdb.git

Then switch to the 7.10 branch:

#> git checkout gdb-7.10-branch

After that, you can apply the patch mentioned by Pedro.  There are many ways to do that; for example:

#> git show e0fd7c47bd | git apply --exclude='*ChangeLog*'

This command should reduce the number of conflicts you get because of the ChangeLog files; however, be aware because you may still see conflicts.

After that, you can finally perform the compilation on your machine (using the MAKEINFO=true trick that Pedro mentioned).

> We might as well close this report since it appears to be fixed.

It is important to make sure that the issue has been fixed upstream.  Once we know that, we can close this report.

Since you are using Debian, you may want to perform a "apt-get build-dep gdb" in order to fetch the necessary packages to build GDB.  That should make things easier.

Thanks.
Comment 7 Pedro Alves 2016-03-01 16:54:09 UTC
I just sent a fix for 19676, before I realized it was partly a dup of this one.  Closing this one instead now.

*** This bug has been marked as a duplicate of bug 19676 ***