I noticed a few ui_out methods that are just trivial wrappers. This
patch moves these to ui-out.h, as it seems like they should be
inlineable.
Approved-By: Andrew Burgess <aburgess@redhat.com>
The added check fixes the case when an unqualified lookup
name without template arguments causes expansion of many CUs
which contain the name with template arguments.
This is similar to what dw2_expand_symtabs_matching_symbol does
before expanding the CU.
In the referenced issue the lookup name was wxObjectDataPtr and many
CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused
their expansion and the lookup took around a minute. The added check
helps to avoid the expansion and makes the symbol lookup to return in
a second or so.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520
When printing complaints with one of the execs from test-case
gdb.dwarf2/macro-source-path.exp, we run into:
...
$ gdb -q -batch \
-iex "set complaints 100" \
macro-source-path-clang14-dw4-absolute-cwd-32 \
-ex "p main"
During symbol reading: debug info runs off end of .debug_macro section \
[in module macro-source-path-clang14-dw4-absolute-cwd-32]
$1 = {int ()} 0x4004b7 <main>
...
and readelf complains more specifically:
...
Contents of the .debug_macro section:
Offset: 0
Version: 5
Offset size: 4
Offset into .debug_line: 0xe3
DW_MACRO_define - lineno : 0 macro : ONE 1
DW_MACRO_define_strp - lineno : 0 macro : THREE 3
DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c
DW_MACRO_define - lineno : 1 macro : TWO 2
DW_MACRO_end_file
readelf: Error: .debug_macro section not zero terminated
...
Fix this by adding the missing terminator in Dwarf::_macro_unit.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
The 'univeral_compile_options' in gdb.exp file only verifies the support
of '-fdiagnostics-color=never' for the "C" source file. So while running
tests with assembly source file (.s), many of them are not able to run
on icx/clang compilers because '-fdiagnostics-color=never' option is not
supported. This problem is not seen for the ".S" assembly source files so
these files are not handled separately. After this change, this function
is split into multiple functions to check the support for different type
of sources individually.
Before this change, in the case of clang and ICX compiler, this error is
shown for assembly source files (.s):
'''
icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o
amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300)
icx: warning: argument unused during compilation: '-fdiagnostics-color=never'
[-Wunused-command-line-argument]
gdb compile failed, icx: warning: argument unused during compilation:
'-fdiagnostics-color=never' [-Wunused-command-line-argument]
UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare
'''
Similarly this error is shown for the clang compiler:
'''
clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0
-o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s
clang: warning: argument unused during compilation:
'-fdiagnostics-color=never' [-Wunused-command-line-argument]
'''
Approved-By: Tom Tromey <tom@tromey.com>
The `fork_inferior()` function accepts multiple callbacks, making its
signature a bit hard to read. Define some type aliases to make it a bit
clearer. Use function view for all, while at it.
Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce
Approved-By: Tom Tromey <tom@tromey.com>
When building GDB with -O2 and --enable-ubsan, I get some random errors
in the packet_result self test:
/home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool'
This happens because packet_result::m_textual_err_msg is uninitialized
when using the second constructor. When such a packet_result object
gets copied, an invalid value for m_textual_err_msg (a bool field) is
loaded, which triggers ubsan.
Avoid this by initializing m_textual_err_msg.
Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85
Approved-By: Tom Tromey <tom@tromey.com>
Commit 8971d2788e ("gdb: link so_list using intrusive_list")
mistakenly removed the line that moves the lm_info unique pointer to
sop->lm_info, probably due to a bad conflict resolution. Restore that
line.
Unfortunately, this code is only used for TI C66, which is not widely
tested (if used at all).
Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb
Approved-By: Tom Tromey <tom@tromey.com>
Currently, if you configure gdb with explicit --enable-threading, but
then configure detects std::thread does not work, configure silently
disables threading support and continues configuring.
This patch makes that scenario cause a configuration error, like so:
$ /home/pedro/gdb/src/configure --enable-threading && make
...
configure: error: std::thread does not work; disable threading
make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1
make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads'
make: *** [Makefile:1041: all] Error 2
$
Additionally, if you don't explicitly pass --enable-threading, and
std::thread does not work, we will now get a warning (and the build
continues):
$ /home/pedro/gdb/src/configure && make
...
configure: WARNING: std::thread does not work; disabling threading
...
This is similar to how we handle --enable-tui and missing curses. The
code and error/warning messages were borrowed from there.
Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22
Approved-By: Tom Tromey <tom@tromey.com>
Add support for DW_MACRO_define_strp in dwarf assembly, and use it in
test-case gdb.dwarf2/macro-source-path.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
While debugging gdb, I saw this:
During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >'
This happens because cp-name-parser.y does not handle the spaceship
operator. This patch implements this.
Approved-By: John Baldwin <jhb@FreeBSD.org>
C++14 allows the use of the apostrophe as a numeric separator; that
is, "23000" and "23'000" represent the same number. This patch
implements this for gdb's C++ parser and the C++ name canonicalizer.
I did this unconditionally for all C variants because I think it's
unambiguous.
For the name canonicalizer, there's at least one compiler that can
emit constants with this form, see bug 30845.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845
Approved-By: John Baldwin <jhb@FreeBSD.org>
Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to
different things. I think it's nicer for them to be the same.
Differences between types can be done using suffixes like "ll" and "u"
-- it's not really possible to implement C++ rules in the
canoncalizer, because no gdbarch is available. Possibly gdb should
even drop the type here and just represent all integers the same way
in names.
Approved-By: John Baldwin <jhb@FreeBSD.org>
cpname_state::parse_number allocates nodes for various types and then
only uses one of them. This patch reduces the number of allocations
by not performing the unnecessary ones.
Approved-By: John Baldwin <jhb@FreeBSD.org>
The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should
canonicalize to the same string, but currently they do not -- the
former remains unchanged and the latter is transformed to
"void C<(char)'\001'>::m()".
This patch fixes the bug and also adds some unit tests.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843
Approved-By: John Baldwin <jhb@FreeBSD.org>
This changes demangle_component objects to be stored on the obstack
that is part of demangle_info. It also arranges for a demangle_info
object to be kept alive by cp_merge_demangle_parse_infos. This way,
other data on the obstack can be kept while an "outer" demangle_info
needs it.
Acked-By: John Baldwin <jhb@FreeBSD.org>
If you add an initialization function to a .y file, it will not show
up in init.c, because if the yacc output is in the build tree, it
won't be found.
This patch changes the Makefile to be more robust in this situation.
This removes the current test 'main' from cp-name-parser.y. There
aren't any tests using this, and nowadays it would be better as a unit
test.
Approved-By: John Baldwin <jhb@FreeBSD.org>
This patch changes the docstring self-test to verify that there is no
trailing whitespace at the end of lines. A few existing docstrings
had to be updated.
tui_refresh_cmd_win calls fflush, but there's a comment explaining
that the reason for the call is unknown. This patch removes the call.
I don't think it can be useful, since gdb doesn't generally use stdout
in this way -- only through ui_file.
When doing 'make -C gdb/doc man' to build the man pages, I noticed
that the outputs were being rebuilt each time the make command was
rerun, even when the input files hadn't changed.
This was caused by this commit:
commit 824083f34c
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
Which split the generation of the .pod file from the actual creation
of the man page file. Prior to this split it was OK to delete the
.pod file at the end of the recipe, the rule depending on the .texi
input file, and output was the .1 or .5 man page file.
Now however, with the split, the man page creation depends on the .pod
file, if we delete this after creating the .1 or .5 man page file then
the next time we run 'make' the .pod file is missing and is
regenerated, which in turn triggers the regeneration of the man page
file.
Fix this by leaving the .pod file around, and only cleaning up these
files in the 'mostlyclean' target.
Which leads to a second problem, the POD_FILE_TMPS is not created
correctly, so we don't actually clean up the .pod files! This too is
fixed in this commit.
After this commit running 'make -C gdb/doc man' will build the manual
pages the first time, and each subsequent run will do nothing.
Running 'make -C gdb/doc mostlyclean' will now delete the .pod files.
Approved-By: Tom Tromey <tom@tromey.com>
While working on another patch I needed to pass -Wl,-soname,NAME as a
compiler flag. I initially looked for other tests that did this, and
found a few examples, so I copied what they did.
But when I checked the gdb.log file I noticed that we were actually
getting -Wl,-soname passed twice.
I tracked the repeated option to 'proc gdb_compile_shlib_1' in
lib/gdb.exp. It turns out that we always add -Wl,-soname when
compiling a shared library.
Here's an example of a build command from gdb.base/prelink.exp:
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
/tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \
-fdiagnostics-color=never -shared -g \
-Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \
-o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so
Notice that '-Wl,-soname,prelink.so' is repeated.
I believe that all of the places where tests add '-Wl,-soname,NAME' as
a build option, are unnecessary.
In this commit I propose we remove them all.
As part of this change I've switched from calling gdb_compile_shlib
directly, to instead call build_executable and adding the 'shlib'
flag.
I've tested with gcc and clang and see no changes in the test results
after this commit. All the compile commands still have -Wl,-soname
added, but now it's only added once, from within lib/gdb.exp.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge"
parameter from destructors of classes with no virtual bases; Linaro's CI
informed me that the gdb testsuite needs to be adjusted to match.
Teested against GCC 13.2 and GCC 15 trunk.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Due to the recent commit in aix-thread.c, we see a segmentation fault
in AIX while debugging multiple process involving multiple threads.
One example is a thread that can fork. The GDB output in AIX for the same is
Reading symbols from //gdb_tests/multi-thread-fork...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New Thread 258 (tid 67110997)]
[New Thread 515 (tid 127404289)]
[New inferior 2 (process 16580940)]
Hello from Parent!
[process 16580940 exited]
[New inferior 3 (process 14549318)]
Hello from Parent!
[process 14549318 exited]
Fatal signal: Segmentation fault
----- Backtrace -----
This is because in sync_threadlists () in aix-thread.c there when we
delete threads in unknown state we iterate through all the threads.
When we have one or more threads with the same user thread ID but of different
process then we delete a wrong thread. Since we just check only the pdtid
in in_queue_threads.count (priv->pdtid) == 0 this happened.
This patch is a fix for the same.
The output after we apply this patch is:
Reading symbols from //gdb_tests/multi-thread-fork...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /gdb_tests/multi-thread-fork
[New Thread 258 (tid 75565441)]
[New Thread 515 (tid 63244397)]
[New inferior 2 (process 10813892)]
Hello from Parent!
[New inferior 3 (process 19005888)]
Hello from Parent!
Thread 1.1 received signal SIGINT, Interrupt.
0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50
2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o)
(gdb) q
A debugging session is active.
When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide
container, I run into:
...
temp/$pid/static-libc.c: In function 'main':
temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function
returning void [-Wreturn-mismatch]
2 | void main (void) { return 0; }
| ^
...
UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link
...
Fix this by changing the return type to int.
Tested on x86_64-linux.
A recent patch from Andrew pointed out that gdbarch_inner_than returns
'int', while it should really return 'bool'.
Approved-By: Pedro Alves <pedro@palves.net>
This removes tui_refresh_all. There is only a single caller,
tui_refresh_all_win, so inlining the code there simplifies gdb at no
cost.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The DAP spec allows a number of attributes on the resulting
instructions that gdb currently does not emit. A user requested some
of these, so this patch adds the 'symbol', 'line', and 'location'
attributes. While the spec lets the implementation omit 'location' in
some cases, it was simpler in the code to just always emit it, as then
no extra tracking was needed.
I noticed that two gdb.Block objects will never compare as equal with
'=='. This patch fixes the problem by implementing tp_richcompare, as
was done for gdb.Frame.
A couple callers of make_source call basename by hand. Rather than
add another caller like this, I thought it would be better to put this
ability into make_source itself.
I noticed that remote_target::rcmd did not pass its ui_file argument
down to remote_console_output. This patch fixes this oversight.
Tested-By: Ciaran Woodward <ciaranwoodward@xmos.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
In another patch I'm working on I needed to ask: does the stack grow
down, or grow up?
Looking around I found in infcall.c some code where we needed to ask
the same question, what we do there is ask:
gdbarch_inner_than (gdbarch, 1, 2)
which should do the job. However, I don't particularly like copying
this, it feels like we're asking something slightly different that
just happens to align with the question we're actually asking.
I propose adding a new function `gdbarch_stack_grows_down`. This is
not going to be a gdbarch method that can be overridden, instead, this
will just call the gdbarch_inner_than function. We already have some
gdbarch methods like this, checkout arch-utils.c for examples.
I think it's now clearer what we're actually doing.
A new self-test ensures that all architectures have a stack that
either grows down, or grows up.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Bernd reported that when testing with riscv-unknown-elf target using
the simulator, before commit c7a2ee6491 ("gdb_is_target_native ->
gdb_protocol_is_native"), he had:
PASS: gdb.base/load-command.exp: probe for target native
PASS: gdb.base/load-command.exp: check initial value of the_variable
PASS: gdb.base/load-command.exp: manually change the_variable
PASS: gdb.base/load-command.exp: check manually changed value of the_variable
PASS: gdb.base/load-command.exp: reload: re-load binary
PASS: gdb.base/load-command.exp: reload: check initial value of the_variable
and now:
UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command
The problem is that the sim board/config isn't setting gdb_protocol
anywhere, so gdb_protocol_is_native returns true.
This commit fixes it by making gdb/testsuite/config/sim.exp set
gdb_protocol to "sim".
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
In commit 2236c5e384 ("[gdb/python] Make gdb.UnwindInfo.add_saved_register
more robust") I added this code in unwind_infopy_add_saved_register:
...
if (value->optimized_out () || !value->entirely_available ())
...
which may throw c++ exceptions.
This needs to be caught and transformed into a python exception.
Fix this by using GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Fixes: 2236c5e384 ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
Replace the global function address_in_mem_range with the member
function mem_range::contains. The implementation of the function
doesn't change.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Add two versions of a new function build_id_equal which can be used to
compare build-ids, then make use of these functions in GDB. It seems
better to have a specific function for the task of comparing build-ids
rather than having a length check followed by a memcmp call.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Make use of silent-rules.mk when building the GDB docs.
During review it was requested that there be more specific rules than
just reusing the general 'GEN' rule everywhere in the doc/ directory,
so I've added:
ECHO_DVIPS = @echo " DVIPS $@";
ECHO_TEX = @echo " TEX $@";
ECHO_PDFTEX = @echo " PDFTEX $@";
ECHO_TEXI2DVI = @echo " TEXI2DVI $@";
ECHO_MAKEHTML = @echo " MAKEHTML $@";
ECHO_TEXI2POD = @echo " TEXI2POD $@";
ECHO_TEXI2MAN = @echo " TEXI2MAN $@";
ECHO_MAKEINFO = @echo " MAKEINFO $@";
Then I've made use of these new silent rules and added lots of uses of
SILENT to reduce additional clutter.
As the man page generation is done in two phases, first the creation
of a .pod file, then the creation of the final man page file, I've
restructured the man page rules. Previously we had one rule for each
of the 5 man pages. I now have one general rule that will generate
all of the 5 .pod files, then I have two rules that convert the .pod
files into the final man pages.
I needed two rules for the man page generation as some man pages match
%.1 and some match %.5. I could combine these by using the GNU Make
.SECONDARYEXPANSION extension, but I think having two rules like this
is probably clearer, and the duplication is minimal.
Cleaning up the temporary .pod files is now moved into the
'mostlyclean' target rather than being done as soon as the man page is
created.
I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like
SILENT_FLAG, but is set to '-q' when in silent mode, this can be used
with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to
mean: only report errors.
As with the rest of the GDB makefiles, I've only converted the
"generation" rules to use silent-rules.mk, the install / uninstall
rules are left unchanged.
When looking at the 'diststuff' target, which generates the info and
man pages, I noticed the recipe for this rule just deleted a temporary
file. As that temporary file is already cleaned up as part of the
'clean' rule I've removed the deletion from the 'diststuff' target.
There are still a few "generation" targets that produce output, there
seems to be no flag to silence the 'tex' and 'pdftex' commands which
some recipes use, I've not worried about these for now, e.g. the
refcard.dvi and refcard.pdf targets still produce some output.
Luckily, when doing a 'make all' in the gdb/ directory, we only build
the info docs by default, and those rules are now nice and silent, so
a complete GDB build is now looking nice and quiet by default.
While working on this patch I noticed that 'make -j all-doc' doesn't
work (reliably), this is a preexisting bug in the way that dvi/pdf
targets are generated. For example gdb.dvi and gdb.pdf both use the
texi2dvi tool, which relies on temporary files to hold state. If both
these rules run in parallel then one (or both) of the recipes will
fail.
Luckily, the default docs target (all), which is what gets run when we
do 'make all' in the gdb/ directory, doesn't build the dvi and pdf
targets, so we're OK in that case.
I've not tried to fix this problem in this commit as it already
existed, and I don't want to do too much in one commit. I mention it
only because I ran into this issue while testing this commit.
Currently, when a user tries to list the current location, there are 2
different error messages that can happen, either:
(gdb) list .
No symbol table is loaded. Use the "file" command.
or
(gdb) list .
No debug information available to print source lines.
The difference here is if gdb can find any symtabs at all or not, which
is not something too important for end-users - and isn't informative at
all. This commit changes it so that the error always says that there
isn't debug information available, with these two variants:
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x55555555511d).
or
(gdb) list .
Insufficient debug info for showing source lines at default location.
The difference now is if the inferior has started already, which is
controlled by the user and may be useful.
Unfortunately, it isn't as easy to differentiate if the symtab found for
other list parameters is correct, so other invocations, such as "list +"
still retain their original error message.
Co-Authored-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
I spotted a few places in solib.c and build-id.c where we could apply
file name styling.
Other than the extra styling, there should be no user visible changes
after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Add a regression test for commit d68f983f88 ("Fix heap-use-after-free because
all_objfiles_removed triggers tui_display_main").
When building with address sanitizer, and reverting the commit it triggers the
heap-use-after-free.
Tested on aarch64-linux.
PR symtab/31697
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697
In AIX when a thread exits we were not showing that a thread exit event happened
and GDB continued to keep the terminated threads.
If we have terminated threads then the UI on info threads command will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.)
If we see the frame is not getting displayed correctly.
The reason for the same is that in AIX we were not managing thread states. In particular we do not know
when a thread terminates.
The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit.
This patch is a fix to the same.
Also certain UI is changed.
On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information.
[New Thread 258 (tid 32178533)]
[New Thread 515 (tid 30343651)]
[New Thread 772 (tid 33554909)]
[New Thread 1029 (tid 24969489)]
[New Thread 1286 (tid 18153945)]
[New Thread 1543 (tid 30736739)]
[Thread 258 (tid 32178533) exited]
[Thread 515 (tid 30343651) exited]
[Thread 772 (tid 33554909) exited]
[Thread 1029 (tid 24969489) exited]
[Thread 1286 (tid 18153945) exited]
[Thread 1543 (tid 30736739) exited]
and info threads will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well.
