When running gdb.python/py-mi-events.exp with make check-read1, we get:
...
(gdb) ^M
python print ('test')^M
&"python print ('test')\n"^M
~"test\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: verify python support
^M
python print (sys.version_info[0])^M
&"python print (sys.version_info[0])\n"^M
~"2\n"^M
^done^M
(gdb) FAIL: gdb.python/py-mi-events.exp: check if python 3
^M
...
The FAILs happen as follows.
On one hand, skip_python_tests_prompt uses the prompt_regexp parameter for the
user_code argument of gdb_test_multiple:
...
proc skip_python_tests_prompt { prompt_regexp } {
global gdb_py_is_py3k
gdb_test_multiple "python print ('test')" "verify python support" {
-re "not supported.*$prompt_regexp" {
unsupported "Python support is disabled."
return 1
}
-re "$prompt_regexp" {}
}
gdb_test_multiple "python print (sys.version_info\[0\])" "check if python 3" {
-re "3.*$prompt_regexp" {
set gdb_py_is_py3k 1
}
-re ".*$prompt_regexp" {
set gdb_py_is_py3k 0
}
}
...
On the other hand, gdb_test_multiple itself uses $gdb_prompt:
...
-re "\r\n$gdb_prompt $" {
if ![string match "" $message] then {
fail "$message"
}
set result 1
}
...
So when mi_skip_python_test calls skip_python_tests_prompt with prompt_regexp
set to $mi_gdb_prompt:
...
proc mi_skip_python_tests {} {
global mi_gdb_prompt
return [skip_python_tests_prompt "$mi_gdb_prompt$"]
}
...
and expect reads "(gdb) " and tries to match it (due to the READ1=1 setting),
the user_code regexps using $prompt_regexp (set to $mi_gdb_prompt) don't match,
but the $gdb_prompt regexp in gdb_test_multiple does match.
Fix this by adding a prompt_regexp parameter to gdb_test_multiple, and using the
parameter in skip_python_tests_prompt.
Tested gdb.python/py-mi-events.exp with make check READ1=1 x86_64-linux.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-29 Tom de Vries <tdevries@suse.de>
PR gdb/24855
* lib/gdb.exp (gdb_test_multiple): Add prompt_regexp parameter.
(skip_python_tests_prompt): Add prompt_regexp argument to
gdb_test_multiple calls.
This fixes two cases where elf_link_add_object_symbols returns an
error, setting the catch-all bfd_error_bad_value without explaining
the error. The second one is an internal error that can only be
caused by a target elf_add_symbol_hook, so make that one abort. The
first one is my PR24339 fix. PR24339 is another of those fuzzing bugs
and the fix I made catches the problem when loading symbols, rather
than when symbols are used in relocs. While ld is correct to reject
the object file as not complying with the ELF standard, let's be a
little more forgiving for dynamic objects.
PR 24857
PR 24339
* elflink.c (elf_link_add_object_symbols): Report an informative
error on finding local symbols with index equal or greater than
symbol table sh_info. Correct comment. Allow such symbols in
dynamic objects. Abort on NULL section for symbol.
This adds a new test that checks that the "file" command will show the
program's "main".
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/main.exp: New file.
My original intent here was to add a test case to test that empty TUI
windows re-render their contents after a resize. However, this seems
pretty broken at the moment, so a lot of the test is actually
disabled.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (Term::clean_restart): Make "executable"
optional.
* gdb.tui/empty.exp: New file.
This adds a test case that resizes the terminal and then checks that
the TUI updates properly.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (spawn): New proc.
(Term::resize): New proc.
* gdb.tui/resize.exp: New file.
This adds a test to check that the "list" command will update the TUI
source window.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/list.exp: New file.
This adds a test of "layout split" to the TUI test suite.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/basic.exp: Add "layout split" test.
This adds a very simple test for "layout asm".
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* gdb.tui/basic.exp: Add "layout asm" test.
This patch implements a simple ANSI terminal emulator for the test
suite. It is still quite basic, but it is good enough to allow some
simple TUI testing to be done.
gdb/testsuite/ChangeLog
2019-07-27 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp: New file.
* gdb.tui/basic.exp: New file.
This patch fixes the following failures when testing with
"target_board unix/-m32" using a x86_64-pc-linux-gnu native GDB.
FAIL: gdb.python/py-thrhandle.exp: print thread for bogus handle thrs[3]
FAIL: gdb.python/py-thrhandle.exp: print thread for bogus handle thrs[4]
FAIL: gdb.python/py-thrhandle.exp: print thread id for thrs[0]
FAIL: gdb.python/py-thrhandle.exp: print thread id for thrs[1]
FAIL: gdb.python/py-thrhandle.exp: print thread id for thrs[2]
FAIL: gdb.python/py-thrhandle.exp: thread 0: fetch thread handle from thread
FAIL: gdb.python/py-thrhandle.exp: thread 0: verify that handles are the same
FAIL: gdb.python/py-thrhandle.exp: thread 1: fetch thread handle from thread
FAIL: gdb.python/py-thrhandle.exp: thread 1: verify that handles are the same
FAIL: gdb.python/py-thrhandle.exp: thread 2: fetch thread handle from thread
FAIL: gdb.python/py-thrhandle.exp: thread 2: verify that handles are the same
I've written it so that it might work for other 64-bit host / 32-bit target
combos too.
gdb/ChangeLog:
* linux-thread-db.c (thread_db_target::thread_handle_to_thread_info):
Add case for debugging 32-bit target on 64-bit host. Revise
comment.
I recently noticed the following behavior while debugging
dw2-ranges-func-low-cold. This is one of the test programs associated
with the test gdb.dwarf2/dw2-ranges-func.exp.
(gdb) b 70
Breakpoint 1 at 0x401129: file dw2-ranges-func-lo-cold.c, line 70.
(gdb) run
Starting program: dw2-ranges-func-lo-cold
Breakpoint 1, foo ()
at dw2-ranges-func-lo-cold.c:70
70 if (e) foo_cold (); /* foo foo_cold call */
(gdb) set var e=1
(gdb) step
[Inferior 1 (process 12545) exited normally]
This is incorrect. When stepping, we expect a step to occur. We do not
expect the program to exit. Instead, we should see the following behavior:
...
(gdb) set var e=1
(gdb) step
foo ()
at dw2-ranges-func-lo-cold.c:54
54 baz (); /* foo_cold baz call */
(Note that I've shortened the paths in the above sessions to improve
readability.)
The bug is in fill_in_stop_func() in infrun.c. While working on
non-contiguous address range improvements in 2018, I replaced the
call to find_pc_partial_function() with a call to
find_function_entry_range_from_pc(). Although this seemed like the
right thing to do at the time, I now think that calling
find_pc_partial_function (along with some other tweaks) is the right
thing to do.
For blocks with a single contiguous range, these functions do pretty
much the same thing: when the function succeeds, the function name,
start address, and end address are all filled in. Additionally,
find_pc_partial_function contains an additional output parameter
which is set to the block containing that PC.
For blocks with non-contiguous ranges, find_pc_partial_function
sets the start and end addresses to the start and end addresses
of the range containing the pc. find_function_entry_range_from_pc
does what it says; it sets the start and end addresses to those
of the range containing the entry pc.
The reason that I had thought that using the entry pc range was
correct is due to the fact that fill_in_stop_func() contains some
code for advancing past the function start and entry point. To do
this, we'd need the range that contains the entry pc.
However, when stepping, we actually want the range that contains the
stop pc. If that range also contains the entry pc, we should then
attempt to advance stop_func_start past the start offset and entry
point. (I haven't thought very hard about the reason for advancing
the stop_func_start in this manner. Since it's been there for quite
a while, I'm assuming that it's still a good idea.)
Back when I wrote the test case, I had included a test for doing the
step shown in the example above. I had problems with it, however. At
the time, I thought it was due to differing compiler versions, so I
disabled that portion of the test. I have now reenabled those tests,
but have left in place the logic which may be used to disable it.
The changes to dw2-ranges-func.exp depend on my other recent changes
to the file which have not been pushed yet.
Finally, I'll note that the only caller of
find_function_entry_range_from_pc() is/was fill_in_stop_func(). Once
this commit goes in, it'll be dead code. I considered removing it,
but I think that it ought to be used (instead of
find_pc_partial_function) for determining the correct range to scan
for prologue analysis, so I'm going to leave it in place for now.
gdb/ChangeLog:
* infrun.c (fill_in_stop_func): Use find_pc_partial_function
instead of find_function_entry_range_from_pc.
testsuite/ChangeLog:
* gdb.dwarf2/dw2-ranges-func.exp (enable_foo_cold_stepping):
Enable tests associated with this flag. Adjust regex
referencing "foo_low" to now refer to "foo_cold" instead.
The original dw2-ranges-func.exp test caused a function named foo to be
created with two non-contiguous address ranges. In the C source file,
a function named foo_low was incorporated into the function foo which
was also defined in that file. The DWARF assembler is used to do this
manipulation. The source file had been laid out so that foo_low would
likely be placed (by the compiler and linker) at a lower address than
foo().
The case where a range at a higher set of addresses (than foo) was not
being tested. In a recent discussion on gdb-patches, it became clear
that performing such tests are desirable because bugs were discovered
which only became evident when the other range was located at high(er)
addresses than the range containing the entry point for the function.
This other (non entry pc) address range is typically used for "cold"
code which executes less frequently. Thus, I renamed foo_low to
foo_cold and renamed the C source file from dw-ranges-func.c to
dw-ranges-func-lo.c. I then made a copy of this file, naming it
dw-ranges-func-hi.c. (That was my intent anyway. According to git,
I renamed dw-ranges-func.c to dw-ranges-func-hi.c and then modified it.
dw-ranges-func-lo.c shows up as an entirely new file.)
Within dw-ranges-func-hi.c, I changed the placement of foo_cold()
along with some of the other functions so that foo_cold() would be at
a higher address than foo() while also remaining non-contiguous. The
two files, dw-ranges-func-lo.c and dw-ranges-func-hi.c, are
essentially the same except for the placement of some of the functions
therein.
The tests in dw2-ranges-func.exp where then wrapped in a new proc named
do_test which was then called in a loop from the outermost level. The
loop causes each of the source files to have the same tests run upon
them.
I also added a few new tests which test functionality fixed by the other
commits to this patch series. Due to the reorganization of the file,
it's hard to identify these changes in the patch. So, here are the
tests which were added:
with_test_prefix "no-cold-names" {
# Due to the calling sequence, this backtrace would normally
# show function foo_cold for frame #1. However, we don't want
# this to be the case due to placing it in the same block
# (albeit at a different range) as foo. Thus it is correct to
# see foo for frames #1 and #2. It is incorrect to see
# foo_cold at frame #1.
gdb_test_sequence "bt" "backtrace from baz" {
"\[\r\n\]#0 .*? baz \\(\\) "
"\[\r\n\]#1 .*? foo \\(\\) "
"\[\r\n\]#2 .*? foo \\(\\) "
"\[\r\n\]#3 .*? main \\(\\) "
}
# Doing x/2i foo_cold should show foo_cold as the first symbolic
# address and an offset from foo for the second. We also check to
# make sure that the offset is not too large - we don't GDB to
# display really large offsets that would (try to) wrap around the
# address space.
set foo_cold_offset 0
set test "x/2i foo_cold"
gdb_test_multiple $test $test {
-re " (?:$hex) <foo_cold>.*?\n (?:$hex) <foo\[+-\](\[0-9\]+)>.*${gdb_prompt}" {
set foo_cold_offset $expect_out(1,string)
pass $test
}
}
gdb_assert {$foo_cold_offset <= 10000} "offset to foo_cold is not too large"
# Likewise, verify that second address shown by "info line" is at
# and offset from foo instead of foo_cold.
gdb_test "info line *foo_cold" "starts at address $hex <foo_cold> and ends at $hex <foo\[+-\].*?>.*"
}
When run against a GDB without the requisite bug fixes (from this patch
series), these 6 failures should be seen:
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: backtrace from baz (pattern 4)
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: x/2i foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: no-cold-names: info line *foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: backtrace from baz (pattern 3)
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: x/2i foo_cold
FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: no-cold-names: info line *foo_cold
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-ranges-func.c: Rename to...
* gdb.dwarf2/dw2-ranges-func-lo-cold.c: ...this.
* gdb.dwarf2/dw2-ranges-func-lo-cold.c (foo_low): Change name to
foo_cold. Revise comments to match.
* gdb.dwarf2/dw2-ranges-func-hi-cold.c: New file.
* gdb.dwarf2/dw2-ranges-func.exp (do_test): New proc. Existing tests
were wrapped into this proc; Call do_test in loop from outermost
level.
(foo_low): Rename all occurrences to "foo_cold".
(backtrace from baz): New test.
(x2/i foo_cold): New test.
(info line *foo_cold): New test.
In the course of revising the test case for
gdb.dwarf2/dw2-ranges-func.exp, I added a new .c file which would
cause the "cold" range to be at a higher address than the rest of the
function. In these tests, the range in question isn't really cold in
the sense that a compiler has determined that it'll be executed less
frequently. Instead, it's simply the range that does not include the
entry pc. These tests are intended to mimic the output of such a
compiler, so I'll continue to refer to this range as "cold" in the
following discussion.
The original test case had only tested a cold range placed
at lower addresses than the rest of the function. During testing of the
new code where the cold range was placed at higher addresses, I found
that I could produce the following backtrace:
(gdb) bt
#0 0x0000000000401138 in baz ()
at dw2-ranges-func-hi-cold.c:72
#1 0x0000000000401131 in foo_cold ()
at dw2-ranges-func-hi-cold.c:64
#2 0x000000000040111e in foo ()
at dw2-ranges-func-hi-cold.c:50
#3 0x0000000000401144 in main ()
at dw2-ranges-func-hi-cold.c:78
This is correct, except that we'd like to see foo() listed instead
of foo_cold(). (I handle that problem in another patch.)
Now look at what happens for a similar backtrace where the cold range
is at a lower address than the foo's entry pc:
(gdb) bt
#0 0x000000000040110a in baz ()
at dw2-ranges-func-lo-cold.c:48
#1 0x0000000000401116 in foo ()
at dw2-ranges-func-lo-cold.c:54
#2 0x00007fffffffd4c0 in ?? ()
#3 0x0000000000401138 in foo ()
at dw2-ranges-func-lo-cold.c:70
Note that the backtrace doesn't go all the way back to main(). Moreover,
frame #2 is messed up.
I had seen this behavior when I had worked on the non-contiguous
address problem last year. At the time I convinced myself that the
mangled backtrace was "okay" since we're doing strange things with
the DWARF assembler. We're taking a function called foo_cold (though
it was originally called foo_low - my recent changes to the test case
changed the name) and via the magic of the DWARF assembler, we're
combining it into a separate (non-contiguous) range for foo. Thus,
it was a surprise to me when I got a good and complete backtrace when
the cold symbol is placed at an address that's greater than entry pc.
The function dwarf2_frame_cache (in dwarf2-frame.c) is making this
call:
if (get_frame_func_if_available (this_frame, &entry_pc)) ...
If that call succeeds (returns a true value), the FDE is then
processed up to the entry pc. It doesn't make sense to do this,
however, when the FDE in question does not contain the entry pc. This
can happen when the function in question is comprised of more than one
(non-contiguous) address range.
My fix is to add some comparisons to the test above to ensure that
ENTRY_PC is within the address range covered by the FDE.
gdb/ChangeLog:
* dwarf2-frame.c (dwarf2_frame_cache): Don't decode FDE instructions
for entry pc when entry pc is out of range for that FDE.
build_address_symbolic contains some code which causes it to
prefer the minsym over the the function symbol in certain cases.
The cases where this occurs are the same as the "certain pathological
cases" that used to exist in find_frame_funname().
This commit largely disables that code; it will only prefer the
minsym when the address of minsym is identical to that of the address
under consideration AND the function address for the symbtab sym is
not the same as the address under consideration.
So, without this change, when using the dw2-ranges-func-lo-cold
executable from the gdb.dwarf2/dw2-ranges-func.exp test, GDB exhibits
the following behavior:
(gdb) x/5i foo_cold
0x40110d <foo+4294967277>: push %rbp
0x40110e <foo+4294967278>: mov %rsp,%rbp
0x401111 <foo+4294967281>: callq 0x401106 <baz>
0x401116 <foo+4294967286>: nop
0x401117 <foo+4294967287>: pop %rbp
On the other hand, still without this change, using the
dw2-ranges-func-hi-cold executable from the same test, GDB
does this instead:
(gdb) x/5i foo_cold
0x401128 <foo_cold>: push %rbp
0x401129 <foo_cold+1>: mov %rsp,%rbp
0x40112c <foo_cold+4>: callq 0x401134 <baz>
0x401131 <foo_cold+9>: nop
0x401132 <foo_cold+10>: pop %rbp
This is inconsistent behavior. When foo_cold is at a lower
address than the function's entry point, the symtab symbol (foo)
is displayed along with a large positive offset which would wrap
around the address space if the address space were only 32 bits wide.
(A later patch fixes this problem by displaying negative offsets.)
This commit makes the behavior uniform for both the "lo-cold" and
"hi-cold" cases:
lo-cold:
(gdb) x/5i foo_cold
0x40110d <foo_cold>: push %rbp
0x40110e <foo-18>: mov %rsp,%rbp
0x401111 <foo-15>: callq 0x401106 <baz>
0x401116 <foo-10>: nop
0x401117 <foo-9>: pop %rbp
hi-cold:
(gdb) x/5i foo_cold
0x401128 <foo_cold>: push %rbp
0x401129 <foo+35>: mov %rsp,%rbp
0x40112c <foo+38>: callq 0x401134 <baz>
0x401131 <foo+43>: nop
0x401132 <foo+44>: pop %rbp
In both cases, the symbol shown for the address at which foo_cold
resides is shown as <foo_cold>. Subsequent offsets are shown as
either negative or positive offsets from the entry pc for foo.
When disassembling a function, care must be taken to NOT display
<+0> as the offset for the second range. For this reason, I found
it necessary to add the "prefer_sym_over_minsym" parameter to
build_address_symbolic. The type of this flag is a bool; do_demangle
ought to be a bool also, so I made this change at the same time.
gdb/ChangeLog:
* valprint.h (build_address_symbolic): Add "prefer_sym_over_minsym"
parameter. Change type of "do_demangle" to bool.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn):
Pass suitable "prefer_sym_over_minsym" flag to
build_address_symbolic(). Don't output "+" for negative offsets.
* printcmd.c (print_address_symbolic): Update invocation of
build_address_symbolic to include a "prefer_sym_over_minsym"
flag.
(build_address_symbolic): Add "prefer_sym_over_minsym" parameter.
Restrict cases in which use of minimal symbol is preferred to that
of a found symbol. Update comments.
The discussion on gdb-patches which led to this patch may be found
here:
https://www.sourceware.org/ml/gdb-patches/2019-05/msg00018.html
Here's a brief synopsis/analysis:
Eli Zaretskii, while debugging a Windows emacs executable, found
that functions comprised of more than one (non-contiguous)
address range were not being displayed correctly in a backtrace. This
is the example that Eli provided:
(gdb) bt
#0 0x76a63227 in KERNELBASE!DebugBreak ()
from C:\Windows\syswow64\KernelBase.dll
#1 0x012e7b89 in emacs_abort () at w32fns.c:10768
#2 0x012e1f3b in print_vectorlike.cold () at print.c:1824
#3 0x011d2dec in print_object (obj=<optimized out>, printcharfun=XIL(0),
escapeflag=true) at print.c:2150
The function print_vectorlike consists of two address ranges, one of
which contains "cold" code which is expected to not execute very often.
There is a minimal symbol, print_vectorlike.cold.65, which is the address
of the "cold" range.
GDB is prefering this minsym over the the name provided by the
DWARF info due to some really old code in GDB which handles
"certain pathological cases". This comment reads as follows:
/* In certain pathological cases, the symtabs give the wrong
function (when we are in the first function in a file which
is compiled without debugging symbols, the previous function
is compiled with debugging symbols, and the "foo.o" symbol
that is supposed to tell us where the file with debugging
symbols ends has been truncated by ar because it is longer
than 15 characters). This also occurs if the user uses asm()
to create a function but not stabs for it (in a file compiled
with -g).
So look in the minimal symbol tables as well, and if it comes
up with a larger address for the function use that instead.
I don't think this can ever cause any problems; there
shouldn't be any minimal symbols in the middle of a function;
if this is ever changed many parts of GDB will need to be
changed (and we'll create a find_pc_minimal_function or some
such). */
In an earlier version of this patch, I had left the code for the
pathological case intact, but those who reviwed that patch recommended
removing it. So that's what I've done - I've removed it.
gdb/ChangeLog:
* stack.c (find_frame_funname): Remove code which preferred
minsym over symtab sym in "certain pathological cases".
To recap the bug report:
Commit a068643 introduced a small typo that breaks the gdb build on OpenBSD.
Line 38 of obsd-nat.c needs to be changed from std::sring to std::string.
gdb/ChangeLog
2019-07-26 Brian Callahan <bcallah@openbsd.org>
PR gdb/24839:
* gdb/obsd-nat.c (obsd_nat_target::pid_to_str): Fix typo in return
type.
I ran into this error:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.arch/i386-pkru.exp.
ERROR: missing "
while executing
"untested ""
invoked from within
"if { [prepare_for_testing "failed to prepare" ${testfile} ${srcfile} \
[list debug additional_flags=${comp_flags}]] } {
untested "failed to c..."
(file "gdb/testsuite/gdb.arch/i386-pkru.exp" line 25)
invoked from within
...
caused by:
...
untested "failed to compile x86 PKEYS test.
...
Fix the unterminated string.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-26 Tom de Vries <tdevries@suse.de>
* gdb.arch/i386-pkru.exp: Fix unterminated string.
PR 24798
* dwarf.c (process_cu_tu_index): Avoid integer overflow on 64-bit
systems by casting ncols and nslots expressions to size_t. Display
number of columns and slots before giving up due to buffer overflow.
Use %u to display unsigned ints. Perform more pointer wrap tests.
This field effectively became usused a long time ago, perhaps as early
as 1994.
* elf-bfd.h (struct output_elf_obj_tdata): Delete "linker" field.
(elf_linker): Don't define.
* elflink.c (bfd_elf_final_link): Don't set elf_linker.
Also fixes the date in the changelog of my last commit.
gdb/ChangeLog:
2019-07-25 Christian Biesinger <cbiesinger@google.com>
* python/py-objfile.c (add_separate_debug_file): Fix comment about
this function's Python signature.
On a system without SDT probes in libstdc++, we run into:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
breakpoint in main (unknown output after running)
...
The test-case uses a regexp argument for the catch throw/rethrow/catch
command, which is only supported on systems with SDT probes in libstdc++.
Fix this by marking the portions of the test-case that use a regexp argument
as unsupported on a system without SDT probes.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-25 Tom de Vries <tdevries@suse.de>
PR testsuite/24830
* gdb.mi/mi-catch-cpp-exceptions.exp: Call
mi_skip_libstdcxx_probe_tests, and skip unsupported tests.
* lib/gdb.exp (skip_libstdcxx_probe_tests_prompt): Factor out of ...
(skip_libstdcxx_probe_tests): ... here.
* lib/mi-support.exp (mi_skip_libstdcxx_probe_tests): New proc.
This has no behavior change in itself, but allows a future patch
to add a function to the Python API to look up symbols in the
static block.
gdb/ChangeLog:
2019-07-24 Christian Biesinger <cbiesinger@google.com>
* compile/compile-object-load.c (compile_object_load): Pass GLOBAL_SCOPE.
* solib-spu.c (spu_lookup_lib_symbol): Pass GLOBAL_SCOPE.
* solib-svr4.c (elf_lookup_lib_symbol): Pass GLOBAL_SCOPE.
* symtab.c (lookup_global_symbol_from_objfile): Add a scope parameter.
* symtab.h (lookup_global_symbol_from_objfile): Likewise.
When running gdb.objc/objcdecode.exp we get:
...
objcdecode.m: In function '-[Decode multipleDef]':
objcdecode.m:14:3: warning: incompatible implicit declaration of built-in \
function 'printf'
printf("method multipleDef\n");
^~~~~~
objcdecode.m:14:3: note: include '<stdio.h>' or provide a declaration of \
'printf'
...
Fix this in the three gdb.objc/*.m test-cases by including stdio.h.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24807
* gdb.objc/basicclass.m: Include stdio.h.
* gdb.objc/nondebug.m: Same.
* gdb.objc/objcdecode.m: Same.
Revert
commit 8c728a9d93
Author: Martin Liska <mliska@suse.cz>
Date: Mon Jul 22 14:23:32 2019 +0200
Remove tests that test __gnu_lto_v1 symbol.
since outputs of these tests are used by later tests. Check the normal
symbol, foo, instead of __gnu_lto_v.*, which GCC stopped emitting after
r273662.
* testsuite/ld-plugin/lto-3r.d: Restored. Check foo instead
of __gnu_lto_v.*.
* testsuite/ld-plugin/lto-5r.d: Likewise.
* testsuite/ld-plugin/lto.exp: Run lto-3r and lto-5r tests.
When running gdb.base/infoline-reloc-main-from-zero.exp, I see:
...
Running gdb/testsuite/gdb.base/infoline-reloc-main-from-zero.exp ...
gdb compile failed, ld: infoline-reloc-main-from-zero: \
not enough room for program headers, try linking with -N
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: infoline-reloc-main-from-zero.exp
UNTESTED: gdb.base/infoline-reloc-main-from-zero.exp: failed to compile
...
Fix this by following the suggestion:
...
-set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00"}
+set opts {debug "additional_flags=-nostdlib -emain -Wl,-Ttext=0x00 -Wl,-N"}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24612
* gdb.base/infoline-reloc-main-from-zero.exp: Add -Wl,-N to
additional_flags.
New instruction are added, and some of them are overlapping. Update
disassembler to correctly recognize them. Introduce nps400 option.
opcodes/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* arc-dis.c (skip_this_opcode): Check also for 0x07 major opcodes,
and MPY class instructions.
(parse_option): Add nps400 option.
(print_arc_disassembler_options): Add nps400 info.
gas/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* testsuite/gas/arc/nps400-6.d: Update test.
Add linker relaxation. The first relaxation added is converting
GOTPC32 to PCREL relocations. This relaxation doesn't change the size of
the binary.
bfd/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* elf32-arc.c (bfd_get_32_me): New function.
(bfd_put_32_me): Likewise.
(arc_elf_relax_section): Likewise.
(bfd_elf32_bfd_relax_section): Define.
ld/testsuite/
xxxx-xx-xx Claudiu Zissulescu <claziss@synopsys.com>
* ld-arc/relax-local-pic.d: New test.
* ld-arc/relax-local-pic.s: New file.
H8/300H general register name "ER0" - "ER7".
But gdb using "R0" - "R7".
This changes register name "ER0" - "ER7" in h8300h machine mode.
gdb/ChangeLog:
* h8300-tdep.c (h8300_register_name_common): New.
h8300_register_name): Use h8300_register_name_common.
(h8300s_register_name): Likewise.
(h8300sx_register_name): Likewise.
(h8300h_register_nam): New.
(h8300_gdbarch_init): Use h8300h_register_name in h8300h machine.
I missed some early exits from final_write_processing that mean
_bfd_elf_final_write_processing could be missed.
* elf-vxworks.c (elf_vxworks_final_write_processing): Don't return
early.
* elf32-arc.c (arc_elf_final_write_processing): Likewise.
* elf32-xtensa.c (elf_xtensa_final_write_processing): Likewise.
We currently have these FAILs:
...
FAIL: gdb.multi/tids.exp: two inferiors: info threads -1
FAIL: gdb.multi/tids.exp: two inferiors: info threads -$one
...
because we're expecting:
...
Invalid thread ID: -1
...
but instead we have:
...
Unrecognized option at: -1
...
This error message for info threads has changed since commit 54d6600669
'Make "info threads" use the gdb::option framework'.
Update the test accordingly.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
PR testsuite/24831
* gdb.multi/tids.exp: Update error messages for info threads.
On openSUSE Leap 15.0, I get:
...
FAIL: gdb.base/info-types.exp: l=c: info types
FAIL: gdb.base/info-types.exp: l=c++: info types
...
because the info type command prints info for files info-types.c, stddef.h,
elf-init.c and init.c, while the regexp in the test-case expect only info for
info-types.c.
Fix this by extending the regexp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-07-24 Tom de Vries <tdevries@suse.de>
* gdb.base/info-types.exp: Allow info types to print info for more than
one file.
