aboutsummaryrefslogtreecommitdiff
path: root/gprof
diff options
context:
space:
mode:
authorUlrich Weigand <ulrich.weigand@de.ibm.com>2015-08-27 19:12:49 +0200
committerUlrich Weigand <ulrich.weigand@de.ibm.com>2015-08-27 19:12:49 +0200
commite0fd7c47bd01e0a6eecf5dec4a4be958f8b3bbc8 (patch)
tree8e740be415fcae9cf50120b49a19ad82eaa09c93 /gprof
parent4e83a1e776c0acdaca9e69be9576db9efcd5f511 (diff)
downloadgdb-e0fd7c47bd01e0a6eecf5dec4a4be958f8b3bbc8.zip
gdb-e0fd7c47bd01e0a6eecf5dec4a4be958f8b3bbc8.tar.gz
gdb-e0fd7c47bd01e0a6eecf5dec4a4be958f8b3bbc8.tar.bz2
Fix assertion failure in linux-thread-db
Since we are no longer using thread events by default in linux-thread-db, the find_new_threads_once routine contains an assertion that it should never be called on a live inferior unless using thread events: gdb_assert (!target_has_execution || thread_db_use_events ()); However, there is a code path from thread_db_get_thread_local_address that will in fact call find_new_threads_once in some scenarios. In particular, this is currently always triggered when starting up any Cell/B.E. combined exeuctable. To fix this, this patch removes the call to thread_db_find_new_threads_1 when the current thread was not yet detected. In its place, we now just call thread_from_lwp to detect this one thread if necessary. ChangeLog: * linux-thread-db.c (thread_db_get_thread_local_address): If the thread was not yet discovered, use thread_from_lwp instead of calling thread_db_find_new_threads_1.
Diffstat (limited to 'gprof')
0 files changed, 0 insertions, 0 deletions