When using the executable from test-case gdb.ada/access_to_packed_array.exp
(read-in using -readnow) and printing the symbols using "maint print symbols",
we run into a segv:
...
$ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols"
...
info: array (<>) of character; computed at runtime
ptr: range 0 .. 2147483647; computed at runtime
Aborted (core dumped)
...
What happens is that dwarf2_evaluate_property gets called and sets the local
frame variable to the current frame, which happens to be NULL. Subsequently
the PROP_LOCLIST handling code is executed, where get_frame_address_in_block
gets called with argument NULL, and the segv is triggered.
Fix this by handling a NULL frame in the PROP_LOCLIST handling code in
dwarf2_evaluate_property.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in
PROP_LOCLIST handling code.
gdb/testsuite/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* gdb.ada/access_to_packed_array.exp: Test printing of expanded
symtabs.
This commit brings support for the DWARF line table is_stmt field to
GDB. The is_stmt field is used by the compiler when a single source
line is split into multiple assembler instructions, especially if the
assembler instructions are interleaved with instruction from other
source lines.
The compiler will set the is_stmt flag false from some instructions
from the source lines, these instructions are not a good place to
insert a breakpoint in order to stop at the source line.
Instructions which are marked with the is_stmt flag true are a good
place to insert a breakpoint for that source line.
Currently GDB ignores all instructions for which is_stmt is false.
This is fine in a lot of cases, however, there are some cases where
this means the debug experience is not as good as it could be.
Consider stopping at a random instruction, currently this instruction
will be attributed to the last line table entry before this point for
which is_stmt was true - as these are the only line table entries that
GDB tracks. This can easily be incorrect in code with even a low
level of optimisation.
With is_stmt tracking in place, when stopping at a random instruction
we now attribute the instruction back to the real source line, even
when is_stmt is false for that instruction in the line table.
When inserting breakpoints we still select line table entries for
which is_stmt is true, so the breakpoint placing behaviour should not
change.
When stepping though code (at the line level, not the instruction
level) we will still stop at instruction where is_stmt is true, I
think this is more likely to be the desired behaviour.
Instruction stepping is, of course, unchanged, stepping one
instruction at a time, but we should now report more accurate line
table information with each instruction step.
The original motivation for this work was a patch posted by Bernd
here:
https://sourceware.org/ml/gdb-patches/2019-11/msg00792.html
As part of that thread it was suggested that many issues would be
resolved if GDB supported line table views, this isn't something I've
attempted in this patch, though reading the spec, it seems like this
would be a useful feature to support in GDB in the future. The spec
is here:
http://dwarfstd.org/ShowIssue.php?issue=170427.1
And Bernd gives a brief description of the benefits here:
https://sourceware.org/ml/gdb-patches/2020-01/msg00147.html
With that all said, I think that there is benefit to having proper
is_stmt support regardless of whether we have views support, so I
think we should consider getting this in first, and then building view
support on top of this.
The gdb.cp/step-and-next-inline.exp test is based off a test proposed
by Bernd Edlinger in this message:
https://sourceware.org/ml/gdb-patches/2019-12/msg00842.html
gdb/ChangeLog:
* buildsym-legacy.c (record_line): Pass extra parameter to
record_line.
* buildsym.c (buildsym_compunit::record_line): Take an extra
parameter, reduce duplication in the line table, and record the
is_stmt flag in the line table.
* buildsym.h (buildsym_compunit::record_line): Add extra
parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Ignore
non-statement lines.
* dwarf2/read.c (dwarf_record_line_1): Add extra parameter, pass
this to the symtab builder.
(dwarf_finish_line): Pass extra parameter to dwarf_record_line_1.
(lnp_state_machine::record_line): Pass a suitable is_stmt flag
through to dwarf_record_line_1.
* infrun.c (process_event_stop_test): When stepping, don't stop at
a non-statement instruction, and only refresh the step info when
we land in the middle of a line's range. Also add an extra
comment.
* jit.c (jit_symtab_line_mapping_add_impl): Initialise is_stmt
field.
* record-btrace.c (btrace_find_line_range): Only record lines
marked as is-statement.
* stack.c (frame_show_address): Show the frame address if we are
in a non-statement sal.
* symmisc.c (dump_symtab_1): Print the is_stmt flag.
(maintenance_print_one_line_table): Print a header for the is_stmt
column, and include is_stmt information in the output.
* symtab.c (find_pc_sect_line): Find lines marked as statements in
preference to non-statements.
(find_pcs_for_symtab_line): Prefer is-statement entries.
(find_line_common): Likewise.
* symtab.h (struct linetable_entry): Add is_stmt field.
(struct symtab_and_line): Likewise.
* xcoffread.c (arrange_linetable): Initialise is_stmt field when
arranging the line table.
gdb/testsuite/ChangeLog:
* gdb.cp/step-and-next-inline.cc: New file.
* gdb.cp/step-and-next-inline.exp: New file.
* gdb.cp/step-and-next-inline.h: New file.
* gdb.dwarf2/dw2-is-stmt.c: New file.
* gdb.dwarf2/dw2-is-stmt.exp: New file.
* gdb.dwarf2/dw2-is-stmt-2.c: New file.
* gdb.dwarf2/dw2-is-stmt-2.exp: New file.
* gdb.dwarf2/dw2-ranges-base.exp: Update line table pattern.
This commit adds the ability to set and toggle the DWARF line table
is-stmt flag.
A DWARF line table can now be created with the attribute
'default_is_stmt' like this:
lines {version 2 default_is_stmt 0} label {
...
}
If 'default_is_stmt' is not specified then the current default is 1,
which matches the existing behaviour.
Inside the DWARF line table program you can now make use of
{DW_LNS_negate_stmt} to toggle the is-stmt flag, for example this
meaningless program:
lines {version 2 default_is_stmt 0} label {
include_dir "some_directory"
file_name "some_filename" 1
program {
{DW_LNS_negate_stmt}
{DW_LNE_end_sequence}
}
}
This new functionality will be used in a later commit.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::lines) Add support for modifying the
is-stmt flag in the line table.
Change-Id: Ia3f61d523826382dd2333f65b9aae368ad29c4a5
ubsan complains about memcpy with a NULL src even when size is zero.
* objdump.c (disassemble_section): Don't call qsort unless
sym count is at least two.
(disassemble_data): Don't call memcpy with NULL src.
ihex_set_section_contents sorts records stored on the tdata.ihex_data
list by address, but ihex_write_object_contents went too far in
assuming they were not overlapping. This patch fixes the problem by
not assuming anything about addresses in ihex_write_object_contents.
PR 25648
* ihex.c (ihex_write_object_contents): Don't assume ordering of
addresses here. Remove dead code.
Since i386-opc.tbl contains '\' to avoid very long lines and i386-gen
requires that each instruction must be in one line, also pass -P to
$(CPP) to inhibit generation of linemarkers in the output from the
preprocessor to support i386-gen.
* Makefile.am ($(srcdir)/i386-init.h): Also pass -P to $(CPP).
* Makefile.in: Regenerated.
When trying to run tests using target board cc-with-dwz after a clean build, I
run into:
...
ERROR: tcl error sourcing board description file for target cc-with-tweaks.exp.
couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \
no such file or directory
couldn't open "build/gdb/testsuite/cache/gdb.sh.17028": \
no such file or directory
while executing
"open $tmp_filename w"
(procedure "cached_file" line 9)
invoked from within
"cached_file gdb.sh "$GDB $INTERNAL_GDBFLAGS $GDBFLAGS \"\$@\"" 1"
...
The problem is that cached_file is trying to create a file
build/gdb/testsuite/cache/gdb.sh.17028 in a non-existing directory.
Fix this by creating the cache dir in cached_file.
Tested on x86_64-linux, with target board cc-with-tweaks, and native.
gdb/testsuite/ChangeLog:
2020-03-09 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (cached_file): Create cache dir.
PR 25645
* readelf.c (dump_ia64_vms_dynamic_fixups): Pass size and nmemb
to get_data rather than multiplying.
(dump_ia64_vms_dynamic_relocs): Likewise.
(process_version_sections): Correct order of size and nmemb args
in get_data call.
(process_mips_specific): Likewise.
These all follow an almost common pattern, again with the exception of
being commutative, which can be easily taken care of.
Note that, as an intended side effect (and in fact one of the reason to
introduce templates), AVX long-form pseudo-ops get introduced alongside
the already existing AVX512 ones.
In order to reduce redundancy as well as the chance of things going out
of sync (see a later patch for an example), make the opcode table
generator capable of recognizing and expanding templated templates. Use
the new capability for compacting the general purpose conditional insns.
* wasm-module.c (wasm_scan): Sanity check file name length
before allocating memory. Move common section setup code. Do
without bfd_tell to calculate section size.
I noticed a couple of typos in gdb_binary_search.h. This fixes them.
gdbsupport/ChangeLog
2020-03-08 Tom Tromey <tom@tromey.com>
* gdb_binary_search.h: Fix two typos.
When running with target board unix/-feliminate-dwarf2-dups, we run into these
FAILs:
...
FAIL: gdb.cp/rvalue-ref-params.exp: print value of f1 on Child&& in f2
FAIL: gdb.cp/ref-params.exp: print value of f1 on Child in main
FAIL: gdb.cp/ref-params.exp: print value of f2 on Child in main
FAIL: gdb.cp/ref-params.exp: print value of f1 on Child& in f2
FAIL: gdb.cp/ref-params.exp: print mf1(MQ)
FAIL: gdb.cp/ref-params.exp: print mf2(MQ)
FAIL: gdb.cp/ref-params.exp: print f1(MQR)
FAIL: gdb.cp/ref-params.exp: print mf1(MQR)
FAIL: gdb.cp/ref-params.exp: print mf2(MQR)
...
This is due to comparing the result of build_executable to 1, while
build_executable returns either 0 for success, or -1 for failure.
Fix this by comparing with -1 instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-03-07 Tom de Vries <tdevries@suse.de>
* gdb.cp/ref-params.exp: Compare build_executable result with -1.
* gdb.cp/rvalue-ref-params.exp: Same.
Gcc supports an option -feliminate-dwarf2-dups (up until gcc-7, removed in
gcc-8).
When running tests with target board unix/-feliminate-dwarf2-dups, we run
into:
...
(gdb) PASS: gdb.ada/arraydim.exp: print m'length(3)
ptype global_3dim_for_gdb_testing^M
type = array (Unexpected type in ada_discrete_type_low_bound.^M
(gdb) FAIL: gdb.ada/arraydim.exp: ptype global_3dim_for_gdb_testing
...
The DWARF for the variable global_3dim_for_gdb_testing looks as follows:
...
<0><824>: Abbrev Number: 1 (DW_TAG_compile_unit)
<825> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><832>: Abbrev Number: 2 (DW_TAG_array_type)
<833> DW_AT_type : <0x874>
<2><837>: Abbrev Number: 3 (DW_TAG_subrange_type)
<838> DW_AT_type : <0x84a>
<83c> DW_AT_upper_bound : 0
<2><83d>: Abbrev Number: 3 (DW_TAG_subrange_type)
<83e> DW_AT_type : <0x84a>
<842> DW_AT_upper_bound : 1
<2><843>: Abbrev Number: 3 (DW_TAG_subrange_type)
<844> DW_AT_type : <0x84a>
<848> DW_AT_upper_bound : 2
<2><849>: Abbrev Number: 0
<1><84a>: Abbrev Number: 4 (DW_TAG_typedef)
<84b> DW_AT_type : <0x86d>
<1><84f>: Abbrev Number: 0
<0><85b>: Abbrev Number: 5 (DW_TAG_compile_unit)
<861> DW_AT_name : src/gdb/testsuite/gdb.ada/arraydim/inc.c
<1><86d>: Abbrev Number: 6 (DW_TAG_base_type)
<86e> DW_AT_byte_size : 8
<86f> DW_AT_encoding : 7 (unsigned)
<870> DW_AT_name : long unsigned int
<1><874>: Abbrev Number: 7 (DW_TAG_base_type)
<875> DW_AT_byte_size : 4
<876> DW_AT_encoding : 5 (signed)
<877> DW_AT_name : int
<1><87b>: Abbrev Number: 8 (DW_TAG_variable)
<87c> DW_AT_name : global_3dim_for_gdb_testing
<882> DW_AT_type : <0x832>
<886> DW_AT_external : 1
...
The DWARF contains an anonymous typedef at 0x84a, referring to 0x86d.
Strictly speaking, the anonymous typedef is illegal DWARF, because a
DW_TAG_typedef is defined to have an DW_AT_name attribute containing the name
of the typedef as it appears in the source program.
The DWARF reading code creates a corresponding type for this typedef, which
goes on to confuse the code handling arrays.
Rather than trying to support the type representing this anonymous typedef in
all the locations where it causes problems, fix this by treating the anonymous
typedef as a forwarder DIE in the DWARF reader.
Tested on x86_64-linux, with target boards unix and
unix/-feliminate-dwarf2-dups.
This fixes ~85 failures for unix/-feliminate-dwarf2-dups.
gdb/ChangeLog:
2020-03-07 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (read_typedef): Treat anonymous typedef as forwarder
DIE.
While working on complex number support, I found a couple of
apparently obsolete coments. This removes them.
2020-03-07 Tom Tromey <tom@tromey.com>
* valops.c (value_literal_complex): Remove obsolete comment.
* gdbtypes.h (enum type_code) <TYPE_CODE_FLT>: Remove obsolete
comment.
Fixes a fail on hppa64-hp-hpux, where anything in the first column is
a label.
* testsuite/gas/elf/dwarf-5-file0.s: Don't start directives in
first column.
In commit 2b44a6a237 (" binutils: doc: make `make clean` clean more
things"), I moved the doc build artifacts to MOSTLYCLEANFILES, which
made them get removed by "make clean".
Because generating binutils.info requires makeinfo, and we do not want
to require makeinfo when building from the tarball, binutils.info should
not get removed by "make clean" (otherwise, it won't be included in the
tarball).
And to be consistent with other projects (e.g. ld and gas), we also want
to ship the built man pages in the tarball.
This patch puts back all these in MAINTAINERCLEANFILES, so that they are
bundled in the tarball, and only cleaned if you use "make
maintainer-clean".
Tested by building a source release and confirming they are present.
binutils/ChangeLog:
PR 25491
* doc/Makefile.am: Rename MOSTLYCLEANFILES to MAINTAINERCLEANFILES.
* doc/Makefile.in: Re-generate.
[ Migrating this from Gerrit: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/321 ]
I noticed that some functions in infcmd and infrun call each other and
all call inferior_thread, while they could just get the thread_info
pointer from their caller. That means less calls to inferior_thread, so
less reliance on global state, since inferior_thread reads
inferior_ptid.
The paths I am unsure about are:
- fetch_inferior_event calls...
- step_command_fsm::should_stop calls...
- prepare_one_step
and
- process_event_stop_test calls...
- set_step_info
Before this patch, prepare_one_step gets the thread pointer using
inferior_thread. After this patch, it gets it from the
execution_control_state structure in fetch_inferior_event. Are we sure
that the thread from the execution_control_state structure is the same
as the one inferior_thread would return? This code path is used when a
thread completes a step, but the user had specified a step count (e.g.
"step 5") so we decide to do one more step. It would be strange (and
even a bug I suppose) if the thread in the ecs structure in
fetch_inferior_event was not the same thread that is prepared to stepped
by prepare_one_step. So I believe passing the ecs thread is fine.
The same logic applies to process_event_stop_test calling
set_step_info.
gdb/ChangeLog:
* infrun.h: Forward-declare thread_info.
(set_step_info): Add thread_info parameter, add doc.
* infrun.c (set_step_info): Add thread_info parameter, move doc
to header.
* infrun.c (process_event_stop_test): Pass thread to
set_step_info call.
* infcmd.c (set_step_frame): Add thread_info pointer, pass it to
set_step_info.
(prepare_one_step): Add thread_info parameter, pass it to
set_step_frame and prepare_one_step (recursive) call.
(step_1): Pass thread to prepare_one_step call.
(step_command_fsm::should_stop): Pass thread to
prepare_one_step.
(until_next_fsm): Pass thread to set_step_frame call.
(finish_command): Pass thread to set_step_info call.
The target_get_tib_address call always fails in this case, and there is an
error when changing the program with the file command:
(gdb) file allocer64.exe
Reading symbols from allocer64.exe...
You can't do that when your target is `exec'
Now it will skip this part, there is no need to rebase the executable without
an inferior anyways.
gdb/ChangeLog:
2020-03-06 Hannes Domani <ssbssa@yahoo.de>
* windows-tdep.c (windows_solib_create_inferior_hook):
Check if inferior is running.
PR 25614
* dwarf2dbg.c (dwarf2_directive_filename): Allow a file number of
0 if the dwarf_level is 5 or more. Complain if a filename follows
a file 0.
* testsuite/gas/elf/dwarf-5-file0.s: New test.
* testsuite/gas/elf/dwarf-5-file0.d: New test driver.
* testsuite/gas/elf/elf.exp: Run the new test.
PR 25612
* config/tc-ia64.h (DWARF2_VERISION): Fix typo.
* doc/as.texi: Fix another typo.
When using target board cc-with-gdb-index.exp and running tests in parallel,
we run into:
...
gdb compile failed, gdb/contrib/gdb-add-index.sh: line 86: \
build/gdb/testsuite/gdb.sh: Text file busy
...
The problem is that because of the parallel test run, gdb.sh is created for
every single test-case, and eventually gdb.sh is overwritten while being
executed.
Fix this by creating gdb.sh only once.
Tested on x86_64-linux with target board cc-with-gdb-index.exp, using both a
serial and parallel -j 5 test run.
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (tentative_rename, cached_file): New proc.
* boards/cc-with-tweaks.exp: Use cached_file to create gdb.sh.
PR 25612
* as.c (dwarf_level): Define.
(show_usage): Add --gdwarf-3, --gdwarf-4 and --gdwarf-5.
(parse_args): Add support for the new options.
as.h (dwarf_level): Prototype.
* dwarf2dbg.c (DWARF2_VERSION): Use dwarf_level as default version
value.
* config/tc-ia64.h (DWARF2_VERISION): Update definition.
(DWARF2_LINE_VERSION): Remove definition.
* doc/as.texi: Document the new options.
Replace "the the" by "the".
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* NEWS: Fix "the the".
* ctfread.c: Same.
gdb/doc/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* gdb.texinfo: Fix "the the".
gdb/testsuite/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* README: Fix "the the".
* gdb.base/dprintf.exp: Same.
Using verbose, we get some detail on symbol loading:
...
$ gdb a.out -iex "set verbose on"
Reading symbols from a.out...
Reading in symbols for /home/vries/hello.c...done.
(gdb)
...
And using debug symtab-create, much more detail:
...
$ gdb a.out -iex "set verbose on" -iex "set debug symtab-create 1"
Reading symbols from a.out...
Reading minimal symbols of objfile /data/gdb_versions/devel/lto/a.out ...
Installing 30 minimal symbols of objfile /data/gdb_versions/devel/lto/a.out.
Done reading minimal symbols.
Creating one or more psymtabs for objfile /data/gdb_versions/devel/lto/a.out ...
Created psymtab 0x35a3de0 for module ../sysdeps/x86_64/start.S.
Created psymtab 0x353e4e0 for module init.c.
Created psymtab 0x353e560 for module ../sysdeps/x86_64/crti.S.
Created psymtab 0x353e5e0 for module /home/vries/hello.c.
Created psymtab 0x35bd530 for module elf-init.c.
Created psymtab 0x35bd5b0 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...Created compunit symtab 0x354bd20 for hello.c.
done.
(gdb)
...
The "Created compunit symtab" message gets inbetween the "Reading in symbols"
and the trailing "done.". [ Strictly speaking this is a regression since
commit faa17681cc "Make gdb_flush also flush the wrap buffer", but the
same problem happens when using -batch before this commit. ]
Fix this by removing the trailing "done." altogether, such that we get:
...
Created psymtab 0x3590520 for module ../sysdeps/x86_64/crtn.S.
Reading in symbols for /home/vries/hello.c...
Created compunit symtab 0x359dd20 for hello.c.
(gdb)
...
[ Alternatively, we could fix this emitting a "Done reading in symbols" line
or some such, like is done for minimal symbols. See above. ]
[ Note: Removing the trailing "done." for the "Reading symbols from" message
was done in commit 3453e7e409 'Clean up "Reading symbols" output'. ]
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-06 Tom de Vries <tdevries@suse.de>
* psymtab.c (psymtab_to_symtab): Don't print "done.".
Copy the .dir-locls.el file from gdb/ to gdbserver/ and gdbsupport/ so
that we get the GNU/GDB style when editing these files in Emacs.
I initially wanted to remove the (c-mode . ((mode . c++))) that
switches c-mode files into c++-mode as we store C++ code in *.cc files
in the gdbserver/ directory, unlike gdb/ where we use *.c, however, I
was forgetting about the header files - we still use *.h for our C++
header files, so for now I left the settings in place to open all C
files in c++-mode.
We now have three copies of this file, which are all identical. It
would be nice if we could remove this duplication, however, for now we
haven't found a good way to do this.
Some options considered were:
1. Use symlinks to only have one copy of the file. This was
rejected as not all targets support symlinks in the way.
2. Have two of the .dir-locals.el files contain some mechanism by
which the third copy of the file is sourced. Though this would, in
theory, be possible, it would involve some advanced Emacs scripting,
would be fragile, and a maintenance burdon.
3. Move the .dir-locals up into top level src/ directory, then use
Emacs dir-locals directory pattern matching to only apply the rules
for the three directories we care about. The problem is that each
directory has to be listed separately, so we still end up having to
duplicate all the rules.
In the end, it was decided that having three copies of the file,
though not ideal, is probably easiest for now. This was all discussed
in this mailing list thread:
https://sourceware.org/ml/gdb-patches/2020-03/msg00024.html
The copyright date in the new files is left as for gdb/.dir-locals.el,
as the new files are a copy of the old, this is inline with this rule:
https://sourceware.org/gdb/wiki/ContributionChecklist#Copyright_Header
gdb/ChangeLog:
* .dir-locals.el: Add a comment referencing the other copies of
this file.
gdbserver/ChangeLog:
* .dir-locals.el: New file.
gdbsupport/ChangeLog:
* .dir-locals.el: New file.
binutils* objcopy.c (check_new_section_flags): New function. Reject the
SEC_COFF_SHARED flag if the target is not a COFF binary.
(copy_object): Call check_new_section_flags.
(setup_section): Likewise.
* doc/binutils.texi (objcopy): Add a note that the 'share' section
flag cannot be applied to ELF binaries.
bfd * elf.c (_bfd_elf_set_section_contents): Replace call to abort
with error messages and failure return values.
Presumably as a result of various changes over the last several months,
and - for some of them - with a generalization of logic in
match_mem_size() plus mirroring of this generalization into the
broadcast handling logic of check_VecOperands(), various register-only
templates can be foled into their respective memory forms. This in
particular then also allows dropping a few more instances of IgnoreSize.
Even after commit dc2be329b9 ("i386: Only check suffix in instruction
mnemonic"), by which many of its uses have become unnecessary (some were
unnecessary even before), IgnoreSize is still used for various slightly
different purposes:
- to suppress emission of an operand size prefix,
- in Intel syntax mode to zap "derived" suffixes in certain cases and to
skip certain checks of remaining "derived" suffixes,
- to suppress ambiguous operand size / missing suffix diagnostics,
- for prefixes to suppress the "stand-alone ... prefix" warning.
Drop entirely unnecessary ones and where possible also replace instances
by the more focused (because of having just a single purpose) NoRex64.
To further restrict when IgnoreSize is needed, also generalize the logic
when to skip a template because of a present or derived L or Q suffix,
by skipping immediate operands. Additionally consider mask registers and
VecSIB there.
Note that for the time being the attribute needs to be kept in place on
MMX/SSE/etc insns (but not on VEX/EVEX encoded ones unless an operand
template of them allows for only non-SIMD-register actuals) allowing for
Dword operands - the logic when to emit a data size prefix would need
further adjustment first.
Note also that the memory forms of {,v}pinsrw get their permission for
an L or Q suffix dropped. I can only assume that it being this way was a
cut-and-paste mistake from the register forms, as the latter
specifically have NoRex64 set, and the {,v}pextrw counterparts don't
allow these suffixes either.
Convert VexW= again to their respective VexW* on lines touched anyway.
The Q and L suffix exclusion checks in match_template() ought to be
(kept) in sync as far as their FPU and SIMD aspects go. This was
already violated by only the Q one checking for active broadcast.
Convert the code such that there'll be only one instance of the logic,
the more that subsequently the logic is liable to need further
refinement / extension. (The alternative would be to drop all SIMD-ness
from the L part, but it is in principle possible to enable all sorts of
SIMD support with just a pre-386 CPU, via suitable .arch directives.)
As of commit dc2be329b9 ("i386: Only check suffix in instruction
mnemonic") these have been accepted even with "qword ptr" operand size
specifier, but in 64-bit mode they're now wrongly having a REX prefix
(with REX.W set) emitted in this case. These aren't Intel syntax
mnemonics, so rather than fixing code generation, let's simply reject
them. As a result, the Qword attribute can then be dropped, too.
When the template specifies any of the possible VexW settings, we can
use this instead of a separate NoRex64 to suppress the setting of REX_W.
Note that this ends up addressing an inconsistency between VEX- and
EVEX-encoded VEXTRACTPS, VPEXTR{B,W}, and VPINSR{B,W} - while the former
avoided setting VEX.W, the latter pointlessly set EVEX.W when there is a
64-bit GPR operand. Adjust the testcase to cover both cases.
Convert VexW= to their respective VexW* on lines touched anyway.
It is almost entirely redundant with Size64, and the sole case (CRC32)
where direct replacement isn't possible can easily be taken care of in
another way.
Since 16-bit addressing isn't allowed, Disp32 needs to be forced; Disp16
fails to match the templates.
The SDM leaves open whether BNDC[LNU] with a GPR operand require an
operand size override; this aspect is therefore left untouched here.
For proper code generation in 16-bit mode (or to avoid the "same type of
prefix used twice" diagnostic there), IgnoreSize is needed on certain
templates allowing for just 32-(and maybe 64-)bit operands.
Beyond adding tests for the previously broken cases, also add ones for
the previously working cases where IgnoreSize is needed for the same
reason (leaving out MPX for now, as that'll require an assembler change
first). Some minor adjustments to tests get done such that re-use of the
same code for 16-bit code generation testing becomes easier.
Allowing 64-bit registers is misleading here: Elsewhere these get allowed
when there's no difference between either variant, because of 32-bit
destination registers having their upper halves zeroed in 64-bit mode.
Here, however, they're source registers, and hence specifying 64-bit
registers would lead to the ambiguity of whether the upper 32 bits
actually matter.
Additionally, for proper code generation in 16-bit mode, IgnoreSize is
needed on both.
And finally, just like for e.g. MONITOR/MWAIT, add variants with all
input registers explicitly specified.
bfd/
2020-03-05 Max Filippov <jcmvbkbc@gmail.com>
* elf32-xtensa.c (shrink_dynamic_reloc_sections): Shrink dynamic
relocation sections for any removed reference to a dynamic symbol.
[Commit message by Simon Marchi]
The GDB build in non-development mode (turn development to false in
bfd/development.sh if you want to try) is currently broken:
CXXLD gdb
/home/smarchi/src/binutils-gdb/gdb/disasm-selftests.c:218: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
/home/smarchi/src/binutils-gdb/gdb/disasm-selftests.c:220: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
/home/smarchi/src/binutils-gdb/gdb/dwarf2/frame.c:2310: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
/home/smarchi/src/binutils-gdb/gdb/gdbarch-selftests.c:168: error: undefined reference to 'selftests::register_test_foreach_arch(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, void (*)(gdbarch*))'
/home/smarchi/src/binutils-gdb/gdbsupport/selftest.cc:96: error: undefined reference to 'selftests::reset()'
This is because the gdbsupport configure script doesn't source
bfd/development.sh to set the development variable. When $development
is unset, GDB_AC_SELFTEST defaults to enabling selftests. I don't think
the macro was written with this intention in mind, it just happens to be
that way.
So gdbsupport thinks selftests are enabled, while gdb thinks they are
disabled. gdbsupport compiles in code that calls selftests:: functions,
which are normally provided by gdb, but gdb doesn't provide them, hence
the undefined references.
Fix this by sourcing bfd/development.sh in gdbsupport/configure.ac, so
that the development variable is set.
gdbsupport/ChangeLog:
* configure.ac: Added call development.sh.
* configure: Regenerate.
* elf-bfd.h (struct elf_backend_data): Add new fields:
init_secondary_reloc_section, slurp_secondary_reloc_section,
write_secondary_reloc_section.
(_bfd_elf_init_secondary_reloc_section): Prototype.
(_bfd_elf_slurp_secondary_reloc_section): Prototype.
(_bfd_elf_write_secondary_reloc_section): Prototype.
* elf.c ( bfd_section_from_shdr): Invoke the new
init_secondary_reloc_section backend function, if defined, when a
second reloc section is encountered.
(swap_out_syms): Invoke the new symbol_section_index function, if
defined, when computing the section index of an OS/PROC specific
symbol.
(_bfd_elf_init_secondary_reloc_section): New function.
(_bfd_elf_slurp_secondary_reloc_section): New function.
(_bfd_elf_write_secondary_reloc_section): New function.
(_bfd_elf_copy_special_section_fields): New function.
* elfcode.h (elf_write_relocs): Invoke the new
write_secondary_relocs function, if defined, in order to emit
secondary relocs.
(elf_slurp_reloc_table): Invoke the new slurp_secondary_relocs
function, if defined, in order to read in secondary relocs.
* elfxx-target.h (elf_backend_copy_special_section_fields):
Provide a non-NULL default definition.
(elf_backend_init_secondary_reloc_section): Likewise.
(elf_backend_slurp_secondary_reloc_section): Likewise.
(elf_backend_write_secondary_reloc_section): Likewise.
(struct elf_backend_data elfNN_bed): Add initialisers for the new
fields.
* configure.ac (score_elf32_[bl]e_vec): Add elf64.lo
* configure: Regenerate.
Create .gitattributes files in gdb/, gdbserver/, and gdbsupport/.
The files specify cpp-style diffs for .h and .c files. This is
particularly helpful if a class in a header file is modified.
For instance, if the `stop_requested` field of `thread_info` in
gdb/gdbthread.h is modified, we get the following diff with
'git diff' (using git version 2.17.1):
@@ -379,7 +379,7 @@ public:
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
Note that the context of the change shows up as 'public:'; not so
useful. With the .gitattributes file, we get:
@@ -379,7 +379,7 @@ class thread_info : public refcounted_object
struct target_waitstatus pending_follow;
/* True if this thread has been explicitly requested to stop. */
- int stop_requested = 0;
+ bool stop_requested = 0;
/* The initiating frame of a nexting operation, used for deciding
which exceptions to intercept. If it is null_frame_id no
The context is successfully shown as 'class thread_info'.
This patch creates a .gitattributes file per each of gdb, gdbserver,
and gdbsupport folders. An alternative would be to define the
attributes in the root folder -- this would impact all the top-level
folders, though. I opted for the more conservative approach.
gdb/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbserver/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
gdbsupport/ChangeLog:
2020-03-05 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* .gitattributes: New file.
