They are relevant only when multiple operands permit registers:
operand_type_register_match() returns true if either operand is not a
register one. IOW
grep -i CheckRegSize i386-opc.tbl | grep -Ev "(Reg[8136]|Acc).*,.*(Reg|Acc)"
should produce no output.
I'm rather certain the missing ! was just a typo, the more with the
similar check in mind that's in the same function a few hundred lines
down (in the body of "if (vex_reg != (unsigned int) ~0)"). Of course
this can't be demonstrated by a test case - internal data structure
consistency is being checked here, and neither form of the check
triggers with any current template.
It is also not really clear to me why operand_type_equal() is being used
in the {X,Y,Z}MM register check here, rather than just testing the
respective bits: Just like Reg32|Reg64 is legal in an operand template,
I don't see why e.g. RegXMM|RegYMM wouldn't be. For example it ought to
be possible to combine
vaddpd, 3, 0x6658, None, 1, CpuAVX, Modrm|Vex|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Xmmword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|RegXMM, RegXMM, RegXMM }
vaddpd, 3, 0x6658, None, 1, CpuAVX, Modrm|Vex=2|VexOpcode=0|VexVVVV=1|VexW=1|IgnoreSize|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf, { Ymmword|Unspecified|BaseIndex|Disp8|Disp16|Disp32|Disp32S|RegYMM, RegYMM, RegYMM }
into a single template (with setting of VEX.L suitably handled elsewhere
if that's not already happening anyway).
Additionally I don't understand why this uses abort() instead of
gas_assert().
Both of these latter considerations then also apply to the
aforementioned other check in the same function.
We never need to resolve_forwards() a symbol found by hash table lookup
such as target->tls_get_addr_opt() but we do potentially need to do so
for random symbols seen on relocs. So these calls were in the wrong
order, resulting in missing stubs and an assertion failure.
PR 22602
* powerpc.cc (Target_powerpc::Branch_info::mark_pltcall): Resolve
forwards before replacing __tls_get_addr.
(Target_powerpc::Branch_info::make_stub): Likewise.
Consider the following code:
type Top_T is tagged record
N : Integer := 1;
U : Integer := 974;
A : Integer := 48;
end record;
type Middle_T is new Top.Top_T with record
N : Character := 'a';
C : Integer := 3;
end record;
type Bottom_T is new Middle.Middle_T with record
N : Float := 4.0;
C : Character := '5';
X : Integer := 6;
A : Character := 'J';
end record;
Tagged records in Ada provide object-oriented features, and what
is interesting in the code above is that a child tagged record
introduce additional components (fields) which sometimes have
the same name as one of the components in the parent. For instance,
Bottom_T introduces a component named "C", while at the same time
inheriting from Middle_T which also has a component named "C";
so, in essence, type Bottom_T has two components with the same name!
And before people start wondering why the language can possibly
be allowing that, this can only happen if the parent type has
a private definition. In our case, this was brought to our attention
when the parent was a generic paramenter.
With that in mind... Let's say we now have a variable declared
and initialized as follow:
TC : Top_A := new Bottom_T;
And then we use this variable to call this function
procedure Assign (Obj: in out Top_T; TV : Integer);
as follow:
Assign (Top_T (B), 12);
Now, we're in the debugger, and we're inside that procedure
(Top.Assign in our gdb testcase), and we want to print
the value of obj.c:
Usually, the tagged record or one of the parent type owns the
component to print and there's no issue but in this particular
case, what does it mean to ask for Obj.C ? Since the actual
type for object is type Bottom_T, it could mean two things: type
component C from the Middle_T view, but also component C from
Bottom_T. So in that "undefined" case, when the component is
not found in the non-resolved type (which includes all the
components of the parent type), then resolve it and see if we
get better luck once expanded.
In the case of homonyms in the derived tagged type, we don't
guaranty anything, and pick the one that's easiest for us
to program.
This patch fixes the behavior like described above.
gdb/ChangeLog:
* ada-lang.c (ada_value_primitive_field): Handle field search
in case of homonyms.
(find_struct_field): Ditto.
(ada_search_struct_field): Ditto.
(ada_value_struct_elt): Ditto.
(ada_lookup_struct_elt_type): Ditto.
gdb/testsuite/ChangeLog:
* gdb.ada/same_component_name: New testcase.
Tested on x86_64-linux.
In Python 3, the 'p' format specifier can be passed to
PyArg_ParseTupleAndKeywords to test the argument for truth and convert
it to a boolean value (the p stands for predicate). However, it is not
available in Python 2, causing this error:
Traceback (most recent call last):
File "test.py", line 1, in <module>
b1 = gdb.Breakpoint("foo", qualified=False)
TypeError: argument 10 (impossible<bad format char>)
This patch changes it to the 'O' specifier, which returns the Python
object passed in without transformation, and uses PyObject_IsTrue on it.
This is what is done for the other boolean parameters of this function
(internal and temporary).
This fixes the test gdb.python/py-breakpoint.exp for Python 2.
gdb/ChangeLog:
* python/py-breakpoint.c (bppy_init): Use 'O' format specifier
for "qualified" and use PyObject_IsTrue.
We can run the gnu_unique_object symbol test on all ELF targets.
Those that don't support the symbol type and fail to assemble can just
be resolved as "unsupported". This means binutils_assemble can't
report an error on assembly failure, but it probably should never have
done that anyway.
* testsuite/lib/utils-lib.exp (default_binutils_assemble_flags):
Don't perror on assembler diagnostic output.
* testsuite/binutils-all/nm.exp: Run unique symbol test on all
ELF targets. Resolve as "unsupported" on assembly failure.
The .debug_names completely misses its support as it did not even produce
DW_IDX_type_unit.
gdb/ChangeLog
2017-12-14 Jan Kratochvil <jan.kratochvil@redhat.com>
* dwarf2read.c (dw2_debug_names_iterator::next): Support
DW_IDX_type_unit.
(debug_names::dwarf5_offset_size, unit_kind): New.
(debug_names::insert): Add parameter kind.
(debug_names::build): Support DW_IDX_type_unit.
(debug_names::recursively_write_psymbols): Update
(debug_names::write_psymbols caller.
(debug_names::write_one_signatured_type_data)
(debug_names::write_one_signatured_type): New.
(debug_names::index_key, debug_names::symbol_value)
(debug_names::write_psymbols): Add kind.
(debug_names::write_one_signatured_type): New.
(write_debug_names): Move dwarf5_offset_size to debug_names.
Use debug_names::write_one_signatured_type for type units.
Consider the following Ada Code:
type Str is new String (1 .. 4);
My_str : Str := "ABCD";
This simply declares a 4-character string type. Trying to perform
equality tests using it currently yield an error:
(gdb) p my_str = my_str
Attempt to compare array with non-array
(gdb) p my_str = "ABCD"
Attempt to compare array with non-array
The error occurs because my_str is defined as an object whose
type is a typdef to a TYPE_CODE_ARRAY, which ada_value_equal
is not expecting at all (yet). This patch fixes this oversight.
gdb/ChangeLog:
* ada-lang.c (ada_value_equal): Add handling of typedef types
when comparing array objects.
gdb/testsuite/ChangeLog:
* gdb.ada/str_binop_equal: New testcase.
Tested on x86_64-linux.
The reasons for not supporting task switching when debugging core files
appear to now mostly be OBE. In particular, on GNU/Linux, the thread
layer is now able to retrieve the same thread info as in the live
process. So, this patch is mostly about just removing the guard
that limited the use of task switching to live processes.
gdb/ChangeLog:
* ada-tasks.c (read_atcb): Properly set task_info->ptid
when !target_has_execution as well.
(task_command): Remove error when !target_has_execution.
gdb/testsuite/ChangeLog:
* gdb.ada/task_switch_in_core: New testcase.
This patch adds the possibility to pass a qualified=True|False parameter
when creating a breakpoint in Python. It is equivalent to using
-qualified in a linespec. The parameter actually accepts any Python
value, and converts it to boolean using Python's standard rules for
that (https://docs.python.org/3/library/stdtypes.html#truth).
Unlike the -source/-line/-function/-label parameters, it is possible to
use -qualified with a "normal" (non-explicit) linespec. Therefore, it
is possible (unlike these other parameters) to use this new parameter
along with the spec parameter.
I updated the py-breakpoint.exp test. To be able to test multiple
locations using a namespace, I had to switch the test case to compile as
C++. If we really wanted to, we could run it as both C and C++, but
omit the C++-specific parts when running it as C.
gdb/ChangeLog:
* location.h (string_to_event_location): Add match_type
parameter.
* location.c (string_to_event_location): Likewise.
* python/py-breakpoint.c (bppy_init): Handle qualified
parameter.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Document
qualified parameter to gdb.Breakpoint.
gdb/testsuite/ChangeLog:
* gdb.python/py-breakpoint.c (foo_ns::multiply): New function.
* gdb.python/py-breakpoint.exp: Compile the test case as c++,
call test_bkpt_qualified.
(test_bkpt_qualified): New proc.
While writing the tests included in the previous commit, I noticed
that test_gdb_complete_tab_multiple would not FAIL if GDB happens to
show more completions than expected before the expected list.
E.g., with something like this, expecting "p foo" to complete to
"foo2" and "foo3":
test_gdb_complete_tab_multiple "p foo" "" {
"foo2"
"foo3"
}
and then if foo actually completes to:
(gdb) p foo[TAB]
foo1 foo2 foo3
^^^^
we'd still PASS. (Note the spurious "foo1" above.)
This tightens the regexp with a beginning anchor thus making the
completions above cause a FAIL. Other similar functions in
completion-support.exp already do something like this; I had just
missed this one originally. Thankfully, this did not expose any
problems in the gdb.linespec/ tests. Phew.
gdb/testsuite/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* lib/completion-support.exp (test_gdb_complete_tab_multiple):
Tighten regexp by matching with an anchor.
I noticed this regression in the expression completer:
"(gdb) p std::[TAB]" => "(gdb) p std::std::"
obviously we should have not completed to "std::std::".
The problem is that in the earlier big completer rework, I missed
taking into account the fact that with expressions, the completion
word point is not always at the start of the symbol name (it is with
linespecs).
The fix is to run the common prefix / LCD string (what readline uses
to expand the input line) through make_completion_match_str too.
New testcase included, exercising both TAB completion and the complete
command.
gdb/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* completer.c (completion_tracker::maybe_add_completion): New
'text' and 'word' parameters. Use make_completion_match_str.
(completion_tracker::add_completion): New 'text' and 'word'
parameters. Pass down.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref. Adjust.
* completer.h (completion_tracker::add_completion): New 'text' and
'word' parameters.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref.
(completion_tracker::recompute_lowest_common_denominator): Change
parameter type to gdb::unique_xmalloc_ptr rval ref.
* symtab.c (completion_list_add_name): Pass down 'text' and 'word'
as well.
gdb/testsuite/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* gdb.cp/cpcompletion.exp: Load completion-support.exp.
("expression with namespace"): New set of tests.
* gdb.cp/pr9594.cc (Test_NS::foo, Test_NS::bar)
(Nested::Test_NS::qux): New.
* lib/completion-support.exp (test_gdb_complete_cmd_multiple): Add
defaults to 'start_quote_char' and 'end_quote_char' parameters.
We have several places doing essentially the same thing; factor them
out to a central place. Some of the places overallocate for no good
reason, or use strcat unnecessarily. The centralized version is more
precise and to the point.
(I considered making the gdb::unique_xmalloc_ptr overload version of
make_completer_match_str try to realloc (not xrealloc) probably
avoiding an allocation in most cases, but that'd be probably overdoing
it, and also, now that I'm writing this I thought I'd try to see how
could we ever get to filename_completer with "text != word", but I
couldn't figure it out. Running the testsuite with 'gdb_assert (text
== word);' never tripped on the assertion either. So post gdb 8.1,
I'll probably propose a patch to simplify filename_completer a bit,
and the gdb::unique_xmalloc_str overload can be removed then.)
gdb/ChangeLog:
2017-12-13 Pedro Alves <palves@redhat.com>
* cli/cli-decode.c (complete_on_cmdlist, complete_on_enum): Use
make_completion_match_str.
* completer.c: Use gdb::unique_xmalloc_ptr and
make_completion_match_str.
(make_completion_match_str_1): New.
(make_completion_match_str(const char *, const char *,
const char *)): New.
(make_completion_match_str(gdb::unique_xmalloc_ptr<char> &&,
const char *, const char *)): New.
* completer.h (make_completion_match_str(const char *,
const char *, const char *)): New.
(make_completion_match_str(gdb::unique_xmalloc_ptr<char> &&,
const char *, const char *)): New.
* interps.c (interpreter_completer): Use make_completion_match_str.
* symtab.c (completion_list_add_name, add_filename_to_list): Use
make_completion_match_str.
I find the documentation of the gdb.Breakpoint constructor hard to read
and not very informative, especially since we have added the new
linespec parameters. There are multiple problems (some are subjective):
- It's not clear that you should use either the spec string or the
explicit arguments, not both.
- It's not clear what combination of parameters you can use.
- The big block of text describing the arguments is hard to read.
- Currently, it seems like the "spec" argument is mandatory, even though
it is not (if you use explicit linespec).
- The square bracket nesting
[arg1 [, arg2[, arg3]]]
makes it seems like if you specify arg3, you must specify arg1 and
arg2 (it's not the case here).
This patch tries to address these problems.
gdb/doc/ChangeLog:
* python.texi (Manipulating breakpoints using Python): Split doc
of Breakpoint.__init__ in two, split text in multiple
paragraphs, don't nest parameter square brackets.
R_AARCH64_ABS64, R_AARCH64_ABS32 and R_AARCH64_ABS16 are data relocations
supported in AArch64 elf ABI.
R_AARCH64_ABS64 under LP64 is allowed in shared object and a dynamic relocation entry
will be generated. This allows the dynamic linker to do further symbol resolution.
R_AARCH64_ABS32 likewise is allowed in shared object, however under ILP32 abi.
The original behavior for R_AARCH64_ABS32 under LP64 is that, it's allowed
in shared object and silently resolved at static linking time.
No dynamic relocation entry is generate for it.
R_AARCH64_ABS16 is allowed in shared object under both L64 and ILP32.
It's resolved at static linking time as well.
Under LP64, the address should be 64-bit. R_AARCH64_ABS32 relocation indicates
an address that is only sized 32 bits which is meaningless in LP64 shared object.
It's useful to error out.
I have checked glibc dynamic linker code, R_AARCH64_ABS16 is not supported at all. So
R_AARCH64_ABS16 should be reject in shared object completely.
In this patch, R_AARCH64_ABS32 is rejected under LP64 in constant section of shared object.
R_AARCH64_ABS16 is rejected in constant section of shared object in both ABI.
This will sometimes provide useful information for buggy code.
Fix a few issues not using the gettext _() wrapper and issues where
we are using %p directly instead of the dedicated host/target functions.
gdb/ChangeLog:
yyyy-mm-dd Stafford Horne <shorne@gmail.com>
* or1k-tdep.c (or1k_analyse_inst): Use _() wrapper for message
strings.
(or1k_unwind_pc): Use paddress() instead of %p.
(or1k_unwind_sp): Likewise.
(or1k_frame_cache): Use host_address_to_string()/paddress()
instead of %p and use _() wrapper for message strings.
opcodes * disassemble.c: Enable disassembler_needs_relocs for PRU.
gas * testsuite/gas/pru/extern.s: New test for print of U16_PMEMM
relocation.
* testsuite/gas/pru/extern.d: New test driver.
This fixes these failures on 64 bit which currently occur when running
the Binutils testsuite with a default PIE compiler.
< FAIL: Build rdynamic-1
< FAIL: Build dynamic-1
< FAIL: Build pr22269-1
bfd/ChangeLog:
2017-12-13 Andreas Krebbel <krebbel@linux.vnet.ibm.com>
* elf64-s390.c (elf_s390_adjust_dynamic_symbol): Use
UNDEFWEAK_NO_DYNAMIC_RELOC.
(allocate_dynrelocs): Likewise.
(elf_s390_relocate_section): Check resolved_to_zero.
(elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if
UNDEFWEAK_NO_DYNAMIC_RELOC.
The "server" command prefix no longer turns confirmation queries off.
We can reproduce this with any program by tring to delete all breakpoints,
for instance:
(gdb) break main
Breakpoint 1 at 0x40049b: file /[...]/break-fun-addr1.c, line 21.
(gdb) server delete breakpoints
Delete all breakpoints? (y or n)
GDB should not be asking "Delete all breakpoints? (y or n)", but
instead just delete all breakpoints without asking for confirmation.
Looking at utils.c::defaulted_query gives a glimpse of how this feature
is expected to work:
/* Automatically answer the default value if the user did not want
prompts or the command was issued with the server prefix. */
if (!confirm || server_command)
return def_value;
So, it relies on the server_command global to be set when the "server "
command prefix is used, which is no longer the case since the following
commit:
commit b69d38afde
Date: Wed Mar 9 18:25:00 2016 +0000
Subject: Command line input handling TLC
The patch was simplifying the handling for the command line, and
I believe there was just a small oversight of removing the setting
of the server_command global.
This patch restores that, and adds a testcase to make sure we test
that feature.
gdb/ChangeLog:
* event-top.c (handle_line_of_input): Set server_command.
gdb/testsuite/ChangeLog:
* gdb.base/server-del-break.c: New file.
* gdb.base/server-del-break.exp: New file.
Tested on x86_64-linux, no regression.
This is the testsuite for the or1k sim, it tests running many of the
basic architecture instructions on the openrisc sim.
sim/testsuite/sim/or1k/ChangeLog:
2017-12-12 Peter Gavin <pgavin@gmail.com>
Stafford Horne <shorne@gmail.com>
* add.S: New file.
* alltests.exp: New file.
* and.S: New file.
* basic.S: New file.
* div.S: New file.
* ext.S: New file.
* find.S: New file.
* flag.S: New file.
* fpu.S: New file.
* jump.S: New file.
* load.S: New file.
* mac.S: New file.
* mfspr.S: New file.
* mul.S: New file.
* or.S: New file.
* or1k-asm-test-env.h: New file.
* or1k-asm-test-helpers.h: New file.
* or1k-asm-test.h: New file.
* or1k-asm.h: New file.
* or1k-test.ld: New file.
* ror.S: New file.
* shift.S: New file.
* spr-defs.h: New file.
* sub.S: New file.
* xor.S: New file.
sim/testsuite/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* configure: Regenerated.
These are separted out to make the patch easier to read and smaller.
sim/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* configure: Regenerated.
* or1k/aclocal.m4: Generated.
* or1k/config.in: Generated.
* or1k/configure: Generated.
These are the simulator files generated by cgen. These are split out
from the main sim patch to make the patch easier to review and smaller.
sim/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* or1k/arch.c: Generated.
* or1k/arch.h: Generated.
* or1k/cpu.c: Generated.
* or1k/cpu.h: Generated.
* or1k/cpuall.h: Generated.
* or1k/decode.c: Generated.
* or1k/decode.h: Generated.
* or1k/model.c: Generated.
* or1k/sem-switch.c: Generated.
* or1k/sem.c: Generated.
This adds the OpenRISC 32-bit sim target. The OpenRISC sim is a CGEN
based sim so the bulk of the code is generated from the .cpu files by
CGEN. The engine decode and execute logic in mloop uses scache with
pseudo-basic-block extraction and supports both full and fast (switch)
modes.
The sim does not implement an mmu at the moment. The sim does implement
fpu instructions via the common sim-fpu implementation.
sim/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Peter Gavin <pgavin@gmail.com>
* configure.tgt: Add or1k sim.
* or1k/README: New file.
* or1k/Makefile.in: New file.
* or1k/configure.ac: New file.
* or1k/mloop.in: New file.
* or1k/or1k-sim.h: New file.
* or1k/or1k.c: New file.
* or1k/sim-if.c: New file.
* or1k/sim-main.h: New file.
* or1k/traps.c: New file.
The test case requires adding a nop instruction. For or1k the
instruction is `l.nop`. This change uses the correct operation.
gdb/testsuite/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
* gdb.base/bp-permanent.c: Define nop of or1k.
This patch prepares the current GDB port of the OpenRISC processor from
https://github.com/openrisc/binutils-gdb for upstream merging.
Testing has been done with a cgen sim provided in a separate patch. This
has been tested with 2 toolchains. GCC [1] 5.4.0 from the OpenRISC
project with Newlib [2] and GCC 5.4.0 with Musl [3] 1.1.4.
It supports or1knd (no delay slot target).
The default target is or1k (with delay slot).
You can change the target arch with:
(gdb) set architecture or1knd
The target architecture is assumed to be or1knd
[1] https://github.com/openrisc/or1k-gcc
[2] https://github.com/openrisc/newlib
[3] https://github.com/openrisc/musl-cross
gdb/doc/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Stefan Wallentowitz <stefan@wallentowitz.de>
Franck Jullien <franck.jullien@gmail.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
* gdb.texinfo: Add OpenRISC documentation.
gdb/ChangeLog:
2017-12-12 Stafford Horne <shorne@gmail.com>
Stefan Wallentowitz <stefan@wallentowitz.de>
Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Franck Jullien <franck.jullien@gmail.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
* configure.tgt: Add targets for or1k and or1knd.
* or1k-tdep.c: New file.
* or1k-tdep.h: New file.
* features/Makefile: Add or1k.xml to build.
* features/or1k.xml: New file.
* features/or1k-core.xml: New file.
* features/or1k.c: Generated.
The TOC pointer register, r2, on powerpc64 is generally not mentioned
in debug info. It is saved and restored by call linkage code, and
set to the callee value either by call stub code (ELFv1) or in the
callee global entry point code (ELFv2). A call stub uses the caller
TOC pointer to access the PLT. So for gdb to read the correct PLT
entry in order to determine the destination of the trampoline, gdb
needs to know the caller r2. When skipping over trampolines in the
normal forward direction, the caller r2 is simply the current value of
r2 (at the start of the trampoline). However, when reversing over
trampolines the current value of r2 is that for the callee. Using
that value results in wild reads of memory rather than the correct PLT
entry.
This patch corrects the value of r2 by using the value saved on the
stack for reverse execution. Note that in reverse execution mode it
isn't really necessary for skip_trampoline_code to return the actual
destination, so we're doing a little more work than needed here. Any
non-zero return value would do (and it would be nicer if the interface
was changed to return the start of the stub).
PR tdep/22576
* ppc64-tdep.c (ppc64_plt_entry_point): Rewrite to take TOC-relative
PLT offset, and retrieve r2 from stack when executing in reverse.
(ppc64_standard_linkage1_target): Drop pc param. Calculate offset
rather than PLT address.
(ppc64_standard_linkage2_target): Likewise.
(ppc64_standard_linkage3_target): Likewise.
(ppc64_standard_linkage4_target): Likewise.
(ppc64_skip_trampoline_code_1): Adjust to suit.
Commit
remote: C++ify thread_item and threads_listing_context
21fe1c752e
broke the test gdb.threads/names.exp. The problem is that since we now
use an std::string to hold the extra_info, an empty string is returned
by target_extra_thread_info to print_thread_info_1 when the remote stub
didn't send any extra info, instead of NULL before. Because of that,
print_thread_info_1 prints the extra info between parentheses, which
results in some spurious empty parentheses.
Expected: * 1 Thread 22752.22752 "main" all_threads_ready () at ...
Actual : * 1 Thread 22752.22752 "main" () all_threads_ready () a ...
Since the bug was introduced by a behavior change in the remote target,
I chose to fix it on the remote target side by making it return NULL
when the extra string is empty. This will avoid possibly changing the
behavior of the common code and affecting other targets.
The name field has the same problem. If a remote stub returns no thread
names, remote_thread_name will return an empty string instead of NULL,
so print_thread_info_1 will show empty quotes ("") instead of nothing.
gdb/ChangeLog:
PR gdb/22556
* remote.c (remote_thread_name): Return NULL if name is empty.
(remote_threads_extra_info): Return NULL if extra info is empty.
Gold plugins may wish to further process an input file added by a plugin. For
example, the plugin may need to assign a unique segment for sections in a
plugin-generated input file. This patch adds a plugin callback that the linker
will call when reading symbols from a new input file added after the
all_symbols_read event (i.e. an input file added by a plugin).
2017-12-11 Stephen Crane <sjc@immunant.com>
* plugin-api.h: Add new plugin hook to allow processing of input
files added by a plugin.
(ld_plugin_new_input_handler): New function hook type.
(ld_plugin_register_new_input): New interface.
(LDPT_REGISTER_NEW_INPUT_HOOK): New enum val.
(tv_register_new_input): New member.
* plugin.cc (Plugin::load): Include hooks for register_new_input
in transfer vector.
(Plugin::new_input): New function.
(register_new_input): New function.
(Plugin_manager::claim_file): Call Plugin::new_input if in
replacement phase.
* plugin.h (Plugin::set_new_input_handler): New function.
* testsuite/plugin_new_section_layout.c: New plugin to test
new_input plugin API.
* testsuite/plugin_final_layout.sh: Add new input test.
* testsuite/Makefile.am (plugin_layout_new_file): New test case.
* testsuite/Makefile.in: Regenerate.
When checking mapping symbols backwardly, the section which defines the symbol
is not considerted. This patch fixes this by moving the section checking code
into get_sym_code_type () function which is shared by forward and backword
mapping symbol searching.
opcodes/
2017-12-11 Petr Pavlu <petr.pavlu@arm.com>
Renlin Li <renlin.li@arm.com>
* aarch64-dis.c (print_insn_aarch64): Move symbol section check ...
(get_sym_code_type): Here.
binutils/
2017-12-11 Renlin Li <renlin.li@arm.com>
* testsuite/binutils-all/aarch64/objdump.d: New.
* testsuite/binutils-all/aarch64/objdump.s: New.
As reported at
<https://sourceware.org/ml/gdb-patches/2017-12/msg00229.html>, this
commit:
~~~~
commit abccd1e7b7
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
AuthorDate: Fri Dec 8 22:44:11 2017 +0000
Change dwarf2_initialize_objfile's return value
dwarf2_initialize_objfile was returning boolean whether it is psymtabs
or .gdb_index while now it needs to return also whether it is
.debug_names.
~~~~
breaks non-ELF-target builds:
dwarf2read.o: In function `dwarf2_initialize_objfile(objfile*)':
/home/yao.qi/SourceCode/gnu/binutils-gdb/gdb/dwarf2read.c:6486:
undefined reference to `elf_sym_fns_gdb_index'
/home/yao.qi/SourceCode/gnu/binutils-gdb/gdb/dwarf2read.c:6490:
undefined reference to `elf_sym_fns_debug_names'
/home/yao.qi/SourceCode/gnu/binutils-gdb/gdb/dwarf2read.c:6495:
undefined reference to `elf_sym_fns_lazy_psyms'
collect2: error: ld returned 1 exit status
Makefile:1920: recipe for target 'gdb' failed
because gdb/elfread.c is not included in the gdb build unless bfd also
includes elf support.
Fix this by reverting the patch mentioned above and at the same time
re-adding .debug_names support by adding a new output parameter to
dwarf2_initialize_objfile to indicate the index variant in use. We
can reuse the new dw_index_kind enum in dwarf2read.c for that.
gdb/ChangeLog:
2017-12-11 Pedro Alves <palves@redhat.com>
* defs.h (elf_sym_fns_lazy_psyms, elf_sym_fns_gdb_index)
(elf_sym_fns_debug_names): Move to elfread.c.
* dwarf2read.c (dwarf2_initialize_objfile): Return a boolean
instead of a sym_fns and add 'index_kind' output parameter. Fill
the latter in with the index variant kind if using an index.
(enum dw_index_kind): Moved to symfile.h.
* elfread.c (elf_sym_fns_gdb_index, elf_sym_fns_debug_names)
(elf_sym_fns_lazy_psyms): Move from defs.h.
(elf_symfile_read): Adjust to new dwarf2_initialize_objfile
interface.
* symfile.h (enum class dw_index_kind): New, moved from
dwarf2read.c.
(dwarf2_initialize_objfile): Change prototype.
When converting parts of the mantissa to MPFR, we need to make sure to do
an *unsigned* conversion. Since we convert at most 32 bits at a time,
stored in an unsigned long, this doesn't matter on systems where "long"
is larger than 32 bits. But on systems where it is 32 bits, we can get
conversion errors.
gdb/ChangeLog
2017-12-11 Ulrich Weigand <uweigand@de.ibm.com>
* target-float.c (mpfr_float_ops::from_target): Use mpfr_set_ui
instead of mpfr_set_si to convert mantissa bits.
Recent versions of GNAT are capable of reordering record components
to make their access for efficient. This patch adapts this test to
accept both cases (reordered or not).
gdb/testsuite/ChangeLog:
* gdb.ada/variant_record_packed_array.exp: Adapt test to accept
output with components being reordered.
Tested on x86_64-linux.
There was a difference between C++ dispatch table and Ada's in the
way the Offset_To_Top field is used to determined the base address
of an object:
* in C++ it is a negative offset, so converting abstract interface to
deriving object requires adding this offset to “this”;
* in Ada, it was a positive offset, so the same conversion required
subtracting the offset value.
So in ada, the base address for a tagged type was computed using this formula:
base_address = value_address (obj) - offset_to_top;
The offset_to_top value was previously set to 0 or a positive value.
With recent version of AdaCore's GNAT compiler, the offset has been
changed to match C++, which means it's set to zero or a negative value
As a result, the new formula has to be:
base_address = value_address (obj) + offset_to_top;
Because we want to support old code compiled before GNAT compiler change
done in 19.0w (20171023-64) with this version and future versions of gdb,
then we change the sign of the offset_to_top if required. Required here
means if offset_to_top is positive since it indicates that the code has
been compiled with an old GNAT compiler.
This patch changes the formula as described above.
Also, one side-effect of offset_to_top now being negative is that
we now have to worry about the sign when we read its value from the
inferior. Up to now, we have been reading its value using the data
address builtin type. But since addresses are not always signed, we
now need to make sure we use the proper type (type Storage_Offset
from System.Storage_Elements). Ideally, we would be looking this type
up from the inferior, and then use that type. However, it is not
guaranteed that this type always be described in the debugging
information, so this patch just builds our own, adding it to Ada's
list of primitive types.
gdb/ChangeLog:
* ada-lang.c (ada_tag_value_at_base_address): Change the way
tagged type base address is computed.
(enum ada_primitive_types) <ada_primitive_type_storage_offset>:
New enumerate.
(ada_language_arch_info): Set the ada_primitive_type_storage_offset
element of lai->primitive_type_vector.
Tested on x86_64-linux. Fixes the following tests when using the newer
version of the compiler.
gdb.ada/iwide.exp: print My_Drawable
gdb.ada/iwide.exp: print d_access.all
gdb.ada/iwide.exp: print dp_access.all
gdb.ada/mi_interface.exp: create ggg1 varobj (unexpected output)
gdb.ada/mi_interface.exp: list ggg1's children (unexpected output)
gdb.mi/mi-var-rtti.exp: run to mi-var-rtti.cc:63 (set breakpoint) (unexpected output)
gdb.mi/mi-var-rtti.exp: run to mi-var-rtti.cc:63 (set breakpoint)
Recent versions of GNAT are capable of reordering record components
to make their access for efficient. This patch adapts this test to
accept both cases (reordered or not).
gdb/testsuite/ChangeLog:
* gdb.ada/pkd_arr_elem.exp: Adapt "print test" test to accept
output with components being reordered.
Jan Beulich
Alan Modra
Xavier Roirand
GDB Administrator
Simon Marchi
Nick Clifton
Jan Kratochvil
Joel Brobecker
Jim Wilson
Pedro Alves
Renlin Li
Stafford Horne
Dimitar Dimitrov
Andreas Krebbel
Peter Gavin
Franck Jullien
Stephen Crane
Ulrich Weigand
Sangamesh Mallayya