Not so long ago we started to insert these artificially when expanding
certain macro-like constructs; zap them as cluttering what actually
results from user input.
In "-alm" listings I've noticed an odd blank line following the inserted
.linefile one. This results from the explicit NL inserted being
redundant with the one left in place from the original input line by all
respective callers. Note that we need to compensate for the removed line
by bumping the directive argument (which in turn is decremented again in
s_linefile() before calling new_logical_line_flags(), and I have to
confess that when putting together the original change I was a little
puzzled by the imbalance of increments/decrements, but then I forgot to
actually go look for the cause).
While there also switch to sb_add_string() instead of effectively open-
coding it to some degree.
This commit adds disassembler styling support for MIPS. After this
commit objdump and GDB will style disassembler output.
This is a pretty straight forward change, we switch to use the
disassemble_info::fprintf_styled_func callback, and pass an
appropriate style through as needed. No additional tricks were
needed (compared to say i386, or ARM).
Tested by running all of the objdump commands used by the gas
testsuite and manually inspecting the styled output, everything looks
reasonable, though I'm not a MIPS expert, so it is possible that I've
missed some corner cases. Worst case though is that something will be
styled incorrectly, the actual content should be unchanged.
All the gas, ld, and binutils tests still pass for me.
While working on disassembler styling for MIPS, I noticed that
undefined instructions are printed by the disassembler as raw number
with no assembler directive prefix (e.g. without .word or .short).
I think adding something like .word, or .short, helps to make it
clearer the size of the value that is being displayed, and is inline
with what many of the other libopcode disassemblers do.
In this commit I've added the .word and .short directives, and updated
all the tests that I spotted that failed as a result.
Fixes a fuzzed object file problem where plt relocs were manipulated
in such a way that two synthetic symbols were generated at the same
plt location. Won't occur in real object files.
PR 29846
PR 20337
* objdump.c (compare_symbols): Test symbol flags to exclude
section and synthetic symbols before attempting to check flavour.
Since commit 4bea06d73c COFF support for compressed debug sections
has been broken due to the "flags" variable not getting SEC_HAS_CONTENTS.
* coffgen.c (make_a_section_from_file): Correct section flags
handling. Delete extraneous condition. Update error messages
to be the same as in elf.c.
Move a couple of elf.c functions to compress.c.
* compress.c (bfd_debug_name_to_zdebug): New inline function.
(bfd_zdebug_name_to_debug): Likewise.
* elf.c (convert_debug_to_zdebug, convert_zdebug_to_debug): Delete.
(_bfd_elf_make_section_from_shdr, elf_fake_sections),
(_bfd_elf_assign_file_positions_for_non_load): Adjust to suit.
* coffgen.c (make_a_section_from_file): Use new inlines here.
Since LAR and LSL only access 16 bits of the source operand, regardless
of operand size, allow 16-bit register source for LAR and LSL, and always
disassemble LAR and LSL with 16-bit source operand.
gas/
PR gas/29844
* testsuite/gas/i386/i386.s: Add tests for LAR and LSL.
* testsuite/gas/i386/x86_64.s: Likewise.
* testsuite/gas/i386/intelbad.s: Remove "lar/lsl eax, ax".
* testsuite/gas/i386/i386-intel.d: Updated.
* testsuite/gas/i386/i386.d: Likewise.
* testsuite/gas/i386/intel-intel.d: Likewise.
* testsuite/gas/i386/intel.d: Likewise.
* testsuite/gas/i386/intelbad.l: Likewise.
* testsuite/gas/i386/x86_64-intel.d: Likewise.
* testsuite/gas/i386/x86_64.d: Likewise.
opcodes/
PR gas/29844
* i386-dis.c (MOD_0F02): Removed.
(MOD_0F03): Likewise.
(dis386_twobyte): Restore larS and lslS.
(mod_table): Remove MOD_0F02 and MOD_0F03.
* i386-opc.tbl: Allow 16-bit register source for LAR and LSL.
* i386-tbl.h: Regenerated.
Add a pid parameter to linux_proc_xfer_memory_partial, making the
inferior_ptid reference bubble up close to the target_ops::xfer_partial
boundary. No behavior change expected.
Change-Id: I58171b00ee1bba1ea22efdbb5dcab8b1ab3aac4c
Add a few debug statements that were useful to me when debugging why the
glibc probes interface wasn't getting used.
Change-Id: Ic20744f9fc80a90f196896b0829949411620c540
solib implementations are typically used one at a time. So it will be
rare that you will want to enable debug for one solib kind, and
absolutely want to keep the others disabled. To make things simpler,
instead of adding separate variables / macros / commands for each solib
implementation, merge the existing ones (frv and aix) into a unified
"set/show debug solib", with the solib_debug_printf macro.
Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa
With the general use of C99 there's no need anymore to have i386-gen
produce these. For more frequently used ones introduce local #define-s,
while others are simply spelled out directly. While doing this move
some static constants into more narrow scopes.
Note that as a "side effect" this corrects type_names[]'es imm8s entry.
For one, because of CheckRegSize, there's no need to check the size of
both (register) operands. And then in process_suffix() check opcode
space rather than the (potentially ambiguous) extension opcode.
Leverage the C (commutative) attribute to also reduce the number of XCHG
and TEST templates we have. This way the reg <-> r/m (and reg <-> reg for
XCHG) forms can also be folded into a single template each, utilizing D.
Recent commit 32a5aa2625 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
for powerpc64le") started using command "maint print architecture", which
produces ~275 lines.
Rewrite the corresponding gdb_test_multiple to read line-by-line, to prevent
timeouts on slower test setups.
Note that this doesn't fix a timeout in the test-case on aarch64 due to:
...
gdbarch_dump: read_core_file_mappings = <0x817438>
(gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000
...
Tested on x86_64-linux.
The tests set a break point with the command break *func. This sets a
breakpoint on the first instruction of the function. PowerPC uses
Global Entry Points (GEP) and Local Entry Points (LEP). The first
instruction in the function is the GEP. The GEP sets up register
r2 before reaching the LEP. When the function is called with func() the
function is entered via the LEP and the test fails because GDB does not
see the breakpoint on the GEP. However, if the function is called via a
function pointer, execution begins at the GEP as the test expects.
Currently finish-reverse-bkpt.exp uses source file finish-reverse.c and
next-reverse-bpkt-over-sr.exp uses source file step-reverse.c A new
source file was created for tests finish-reverse-bkpt.exp and
next-reverse-bkpt-over-sr.exp. The new files use the new function
pointer method to call the functions so the tests will work correctly on
both PowerPC with a GEP and LEP as well as on other systems. The GEP is
the same as the LEP on non PowerPC systems.
The expect files were changed to use the new source files and to set the
initial break point for the rest of the test on the function pointer call
for the function.
This patch fixes two PowerPC test failures in each of the tests
gdb.reverse/finish-reverse-bkpt.exp and
gdb.reverse/next-reverse-bkpt-over-sr.exp.
Patch tested on PowerPC and Intel X86-64 with no regressions.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
I noticed that windows_nat_target::interrupt calls registers_changed.
However, I don't think there's any reason to do this, because this
will happen automatically when the inferior stop is processed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I belatedly realized that the "the_windows_nat_target" global isn't
really necessary. It's only used in one place, where 'this' would be
simpler and clearer. This patch removes the global entirely.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR symtab/29105 shows a number of situations where symbol lookup can
result in the expansion of too many CUs.
What happens is that lookup_signed_typename will try to look up a type
like "signed int". In cooked_index_functions::expand_symtabs_matching,
when looping over languages, the C++ case will canonicalize this type
name to be "int" instead. Then this method will proceed to expand
every CU that has an entry for "int" -- i.e., nearly all of them. A
crucial component of this is that the caller, objfile::lookup_symbol,
does not do this canonicalization, so when it tries to find the symbol
for "signed int", it fails -- causing the loop to continue.
This patch fixes the problem by introducing name canonicalization for
C. The idea here is that, by making C and C++ agree on the canonical
name when a symbol name can have multiple spellings, we avoid the bad
behavior in objfile::lookup_symbol (and any other such code -- I don't
know if there is any).
Unlike C++, C only has a few situations where canonicalization is
needed. And, in particular, due to the lack of overloading (thus
avoiding any issues in linespec) and due to the way c-exp.y works, I
think that no canonicalization is needed during symbol lookup -- only
during symtab construction. This explains why lookup_name_info is not
touched.
The stabs reader is modified on a "best effort" basis.
The DWARF reader needed one small tweak in dwarf2_name to avoid a
regression in dw2-unusual-field-names.exp. I think this is adequately
explained by the comment, but basically this is a scenario that should
not occur in real code, only the gdb test suite.
lookup_signed_typename is simplified. It used to search for two
different type names, but now gdb can search just for the canonical
form.
gdb.dwarf2/enum-type.exp needed a small tweak, because the
canonicalizer turns "unsigned integer" into "unsigned int integer".
It seems better here to use the correct C type name.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29105
Tested-by: Simon Marchi <simark@simark.ca>
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
This refactors cooked_index::do_finalize, reordering an 'if' to make
it a little less redundant. This change makes a subsequent patch
easier to read.
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
dwarf2_compute_name has a redundant check of the CU's language -- this
is also checked in dwarf2_canonicalize_name. Removing this slightly
simplifies a future patch.
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
While testing the fix for PR 29105, I noticed I couldn't ctrl-C my way
out of GDB expanding many symtabs. GDB was busy in a loop in
cooked_index_functions::expand_symtabs_matching. Add a QUIT there. I
also happened to see a spot in
cooked_index_functions::expand_matching_symbols where a QUIT would be
useful too, since we iterate over a potentially big number of index
entries and expand CUs in the loop. Add one there too.
Change-Id: Ie1d650381df7f944c16d841b3e592d2dce7306c3
Approved-By: Kevin Buettner <kevinb@redhat.com>
Pedro mentioned that this prune_threads call in
thread_db_target::update_thread_list was not needed, and it was probably
an oversight to leave it there in the work following commit e8032dde10
("Push pruning old threads down to the target"). That commit changed
the "find new threads" target operation to "update thread list", making
the target responsible of adding new threads and removing exited
threads, rather than just adding new threads. Commit e8032dde10 moved
the prune_threads calls previously done in common code into each
target's update_thread_list method, in order to keep the existing
behavior, which is why this prune_threads call ended up there.
In the mean time, the linux-nat target was taught to update_thread_list,
and thread_db_target::update_thread_list defers to that for any live
inferior, so the prune_threads call is not needed there. Otherwise, the
thread_db_target::update_thread_list implementation based on
td_ta_thr_iter_p only knows how to add new threads, not how to delete
exited threads, but that is only used for non-live inferiors, where
threads can't exit anyway. So the prune_threads call is not needed for
that case either.
Change-Id: I127fd4f84c25086f97853dadf34c5cec6816840d
Approved-By: Pedro Alves <pedro@palves.net>
i386-init.h and i386-tbl.h are generated files. There is nothing to
translate. Remove them from HFILES (POTFILES).
* Makefile.am (HFILES): Remove i386-init.h and i386-tbl.h.
* Makefile.in: Regenerated.
* po/POTFILES.in: Likewise.
PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed. This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.
Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.
Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs. This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.
Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29541
skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build"). This patch removes the obsolete
test.
I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite. This removes one from
gdb.exp, in favor of the one in compile-support.exp.
The previous warnings about holes in .debug_loclists sections don't
take into account the headers of each CU and could include the locviews
if they precede the loclist.
The following warning can be triggered between two CU.
... <previous CU views> ...
0000001d <End of list>
0000002a v000000000000000 v000000000000000 location view pair
0000002c v000000000000000 v000000000000000 location view pair
readelf: Warning: There is a hole [0x1e - 0x2e] in .debug_loclists section.
0000002e v000000000000000 v000000000000000 views at 0000002a for:
...
But [0x1e - 0x2a] corresponds to the CU header and [0x2a - 0x2e] are
the locviews. Thus there is no hole here.
binutils/ChangeLog:
* dwarf.c (display_debug_loc): Adjust holes detections for
headers and locviews.
PR 25202
bfd * bfd.c (VerilogDataEndianness): New variable.
(verilog_write_record): Use VerilogDataEndianness, if set, to
choose the endianness of the output.
(verilog_write_section): Adjust the address by the data width.
binutils* objcopy.c (copy_object): Set VerilogDataEndianness to the
endianness of the input file.
(copy_main): Verifiy the value set by the --verilog-data-width
option.
* testsuite/binutils-all/objcopy.exp: Add tests of the new behaviour.
* testsuite/binutils-all/verilog-I4.hex: New file.
(Ab)using i386_opcode_modifier for this has been overkill, as the logic
doesn't really require the full structure. With the removal of
LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf there's no good reason at all
anymore to pull out such a loop invariant: We're dealing a check of a
bit in the loop for a simple comparison. Do the original compares inside
the loop, thus also making it easier to understand what is actually
being checked.
With the removal of its use for FPU insns the suffix is now finally
properly misnamed. Drop its use altogether, replacing it by a separate
boolean instead.
As a comment near the top of match_template() already says: We really
only need this pseudo-suffix for far branch handling. Stop "deriving" it
for floating point insns. (Don't bother renaming the now properly
misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
to disappear anyway.)
When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...
Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.
Tested on powerpc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>
On powerpc64le-linux, I run into:
...
(gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M
$9 = <invalid float value>^M
(gdb) FAIL: gdb.ada/float-bits.exp: print \
16llf#4000921fb54442d18469898cc51701b8#
...
The problem is that we're using a hex string for the 128-bit IEEE quad long
double format, but the actual long double float format is:
...
gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M
...
Fix this by using the hex string obtained by compiling test.c:
...
long double a = 5.0e+25L;
...
like so:
...
$ gcc -mlittle test.c -c -g
...
and running gdb:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0xc1e1c000000000004544adf4b7320335
...
and likewise for -mbig:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0x4544adf4b7320335c1e1c00000000000
...
Tested on powerpc64le-linux.
I excercised the case of floatformat_ibm_long_double_big by
using "set endian big" in the test-case.
Note that for this patch to work correctly, recent commit aaa79cd62b ("[gdb]
Improve printing of float formats") is required.
PR testsuite/29816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816
Approved-By: Tom Tromey <tom@tromey.com>
On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...
Fix this by using with_test_prefix.
Tested on s390x-linux.
