Add the `is_flag_enum` and `set_is_flag_enum` methods on `struct type`,
in order to remove the `TYPE_FLAG_ENUM` macro. In this patch, the macro
is changed to use the getter, so all the call sites of the macro that
are used as a setter are changed to use the setter method directly. The
next patch will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_flag_enum,
set_is_flag_enum>: New methods.
(TYPE_FLAG_ENUM): Use type::is_flag_enum, change all
write call sites to use type::set_is_flag_enum.
Change-Id: I9c56c91626c8d784947ba94fcb97818526b81d1c
Add the `is_declared_class` and `set_is_declared_class` methods on
`struct type`, in order to remove the `TYPE_DECLARED_CLASS` macro. In
this patch, the macro is changed to use the getter, so all the call
sites of the macro that are used as a setter are changed to use the
setter method directly. The next patch will remove the macro
completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_declared_class,
set_is_declared_class>: New methods.
(TYPE_DECLARED_CLASS): Use type::is_declared_class, change all
write call sites to use type::set_is_declared_class.
Change-Id: Idf08d32e137c885a0aba0a18f556a899c1cbfd68
Python 3.4 has deprecated the imp module in favour of importlib. This
patch avoids the DeprecationWarning. This warning is visible to users
whose libpython.so has been compiled with --with-pydebug.
Considering that even python 3.5 has reached end of life, would it be
better to just use importlib and drop support for python 3.0 to 3.3?
2021-02-28 Boris Staletic <boris.staletic@gmail.com>
* gdb/python/lib/gdb/__init__.py: Use importlib on python 3.4+
to avoid deprecation warnings.
The change in PR19011 changed the image load address from being in the lower
32-bit address space to the higher 64-bit address space.
However when you have a weak undef symbol which stays undef at the end of
linking the linker has to resolve this (Windows loader does not support undef
symbols). As such typically these would resolve to 0.
The relocation used for these weak symbols are the normal 32-bit PC_REL call
relocs. So when doing the overflow check LD checks if the distance between the
symbol and the call is within range. However now that the load address is
> 32-bits and the symbol val is 0 this overflow check will always fail.
As such the linker gives a bogus error. This patch makes the linker not emit
the overflow failure but chooses to still let the check be performed (as it's
mid-end code).
One down side of this is that it does break the common convention that the call
be to sym at 0x0. i.e. before you'd get
401015: 74 05 je 40101c
401017: e8 e4 ef bf ff callq 0
and now you get
140001015: 74 05 je 14000101c
140001017: e8 e4 ef ff bf call 100000000
since the call is PC_REL there's no way to get the range large enough to
resolve to 0. As such I have chosen to leave it as the furthest simple range
that we can still represent.
By only ignoring the error we leave the symbol value itself to still be 0
such that the if(<symbol>) checks still work correctly.
bfd/ChangeLog:
2021-04-01 Tamar Christina <tamar.christina@arm.com>
PR ld/26659
* cofflink.c (_bfd_coff_generic_relocate_section): Ignore overflow.
ld/ChangeLog:
2021-04-01 Tamar Christina <tamar.christina@arm.com>
PR ld/26659
* testsuite/ld-pe/pe.exp: Add test.
* testsuite/ld-pe/pr26659-weak-undef-sym.d: New test.
* testsuite/ld-pe/pr26659-weak-undef-sym.s: New test.
I see the following error for --target=microblaze-elf:
../../../sim/microblaze/interp.c: In function 'sim_engine_run':
../../../sim/microblaze/interp.c:147:39: error: passing argument 2 of 'get_insn_microblaze' from incompatible pointer type [-Werror=incompatible-pointer-types]
147 | op = get_insn_microblaze (inst, &imm_unsigned, &insn_type,
| ^~~~~~~~~~~~~
| |
| int *
In file included from ../../bfd/bfd.h:45,
from ../../../sim/microblaze/interp.c:24:
../../../sim/microblaze/../../opcodes/microblaze-dis.h:34:57: note: expected '_Bool *' but argument is of type 'int *'
34 | extern enum microblaze_instr get_insn_microblaze (long, bool *,
| ^
sim/microblaze/ChangeLog:
* interp.c (sim_engine_run): Use bool instead of int.
In commit cfcbd506fb "[gdb/testsuite] Ignore DEBUGINFOD_URLS" I added
unsetting of env(DEBUGINFOD_URLS), but it doesn't work because I forgot to
add :: in front.
Fix this, and rewrite using "unset -nocomplain" instead of unsetenv, which
allows us to drop the "info exists" test.
2021-04-01 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (default_gdb_init): Use ::env. Use unset
-nocomplain ::env(V) instead of unsetenv V.
This removes dw2_map_matching_symbols and dw2_expand_symtabs_matching,
merging them with their sole trivial callers.
gdb/ChangeLog
2021-03-31 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_gdb_index::map_matching_symbols): Merge
with dw2_map_matching_symbols.
(dwarf2_gdb_index::expand_symtabs_matching): Merge with
dw2_expand_symtabs_matching.
Pedro pointed out a typo in a comment in dwarf2/stringify.h. This
fixes it.
gdb/ChangeLog
2021-03-31 Tom Tromey <tromey@adacore.com>
* dwarf2/stringify.h: Fix typo.
I had written a DWARF location expression like
DW_OP_const1u
DW_OP_stack_value
... and was surprised to see that the DW_OP_stack_value didn't appear
in the "readelf" output.
The problem here is that DW_OP_const1u requires an operand, but
neither the DWARF assembler nor gas diagnosed this problem.
This patch adds some checking to Dwarf::_location to try to avoid this
in the future. The checking is done via a helper proc that also
dissects the argument list and sets an array in the caller's frame.
gdb/testsuite/ChangeLog
2021-03-31 Tom Tromey <tromey@adacore.com>
* lib/dwarf.exp (Dwarf::_get_args): New proc.
(Dwarf::_location): Use it.
On openSUSE Tumbleweed, DEBUGINFOD_URLS is now defined by default:
...
$ echo $DEBUGINFOD_URLS
https://debuginfod.opensuse.org/
...
With DEBUGINFOD_URLS defined we run into:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only \
(timeout)
...
as reported in PR27667.
There's a latency of ~0.5s per request, which is ok-ish for interactive usage.
But the symbol-info-functions command ends up issuing 21 source requests,
which means we easily run into the 10s timeout.
Fix this by unsetting DEBUGINFOD_URLS in default_gdb_init.
gdb/testsuite/ChangeLog:
2021-03-31 Tom de Vries <tdevries@suse.de>
PR testsuite/27667
* lib/gdb.exp (default_gdb_init): Unset DEBUGINFOD_URLS.
With this in place we can retire bfd_boolean one project at a time.
bfd/
* bfd-in.h: Include stdbool.h.
(bfd_boolean): Define as bool
* bfd-in2.h: Regenerate.
This fixes the issue that startswith depends on strncpy being
declared, and not all projects using bfd.h include string.h before
bfd.h. I've also deleted some macros that don't find much use
anywhere.
bfd/
* bfd-in.h: Include string.h.
(LITMEMCPY, LITSTRCPY): Delete.
* bfd-in2.h: Regenerate.
binutils/
* prdbg.c (pr_function_type): Replace LITSTTCPY with strcpy.
New in v2:
- Disable sharing only for -readnow objfiles, not all objfiles.
As described in PR 27541, we hit an internal error when loading a binary
the standard way and then loading it with the -readnow option:
$ ./gdb -nx -q --data-directory=data-directory ~/a.out -ex "set confirm off" -ex "file -readnow ~/a.out"
Reading symbols from /home/simark/a.out...
Reading symbols from ~/a.out...
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8098: internal-error: void create_all_comp_units(dwarf2_per_objfile*): Assertion `per_objfile->per_bfd->all_comp_units.empty ()' failed.
This is a recurring problem that exposes a design issue in the DWARF
per-BFD sharing feature. Things work well when loading a binary with
the same method (with/without index, with/without readnow) twice in a
row. But they don't work so well when loading a binary with different
methods. See this previous fix, for example:
efb763a5ea ("gdb: check for partial symtab presence in dwarf2_initialize_objfile")
That one handled the case where the first load is normal (uses partial
symbols) and the second load uses an index.
The problem is that when loading an objfile with a method A, we create a
dwarf2_per_bfd and some dwarf2_per_cu_data and initialize them with the
data belonging to that method. When loading another obfile sharing the
same BFD but with a different method B, it's not clear how to re-use the
dwarf2_per_bfd/dwarf2_per_cu_data previously created, because they
contain the data specific to method A.
I think the most sensible fix would be to not share a dwarf2_per_bfd
between two objfiles loaded with different methods. That means that two
objfiles sharing the same BFD and loaded the same way would share a
dwarf2_per_bfd. Two objfiles sharing the same BFD but loaded with
different methods would use two different dwarf2_per_bfd structures.
However, this isn't a trivial change. So to fix the known issue quickly
(including in the gdb 10 branch), this patch just disables all
dwarf2_per_bfd sharing for objfiles using READNOW.
Generalize the gdb.base/index-cache-load-twice.exp test to test all
the possible combinations of loading a file with partial symtabs, index
and readnow. Move it to gdb.dwarf2, since it really exercises features
of the DWARF reader.
gdb/ChangeLog:
PR gdb/27541
* dwarf2/read.c (dwarf2_has_info): Don't share dwarf2_per_bfd
with objfiles using READNOW.
gdb/testsuite/ChangeLog:
PR gdb/27541
* gdb.base/index-cache-load-twice.exp: Remove.
* gdb.base/index-cache-load-twice.c: Remove.
* gdb.dwarf2/per-bfd-sharing.exp: New.
* gdb.dwarf2/per-bfd-sharing.c: New.
Change-Id: I9ffcf1e136f3e75242f70e4e58e4ba1fd3083389
Since commit 27012aba8a "Remove Irix 6 workaround from DWARF abbrev reader"
we have:
...
(gdb) file dw2-cu-size^M
Reading symbols from dw2-cu-size...^M
DW_FORM_strp pointing outside of .debug_str section [in module dw2-cu-size]^M
(No debugging symbols found in dw2-cu-size)^M
(gdb) ptype noloc^M
No symbol table is loaded. Use the "file" command.^M
(gdb) FAIL: gdb.dwarf2/dw2-cu-size.exp: ptype noloc
...
The problem is a missing .debug_abbrev terminator in dw2-cu-size.S, which
causes the .debug_abbrev contribution to be merged with the next:
...
Number TAG (0x9b)
1 DW_TAG_compile_unit [has children]
DW_AT_name DW_FORM_string
DW_AT_producer DW_FORM_string
DW_AT_language DW_FORM_data1
DW_AT value: 0 DW_FORM value: 0
2 DW_TAG_variable [no children]
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_external DW_FORM_flag
DW_AT value: 0 DW_FORM value: 0
3 DW_TAG_base_type [no children]
DW_AT_name DW_FORM_string
DW_AT_byte_size DW_FORM_data1
DW_AT_encoding DW_FORM_data1
DW_AT value: 0 DW_FORM value: 0
4 DW_TAG_const_type [no children]
DW_AT_type DW_FORM_ref_udata
DW_AT value: 0 DW_FORM value: 0
1 DW_TAG_compile_unit [has children]
DW_AT_producer DW_FORM_strp
DW_AT_language DW_FORM_data1
DW_AT_name DW_FORM_strp
DW_AT_comp_dir DW_FORM_strp
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_data8
DW_AT_stmt_list DW_FORM_sec_offset
DW_AT value: 0 DW_FORM value: 0
...
and consequently, abbreviation code 1 no longer refers to a unique entry.
The eventually causes us to access the first attribute of this DIE:
...
<0><124>: Abbrev Number: 1 (DW_TAG_compile_unit)
<125> DW_AT_name : file1.txt
<12f> DW_AT_producer : GNU C 3.3.3
<13b> DW_AT_language : 1 (ANSI C)
...
which has form DW_FORM_string, using DW_FORM_strp.
Fix this by adding the missing .debug_abbrev terminator in dw2-cu-size.S.
gdb/testsuite/ChangeLog:
2021-03-30 Tom de Vries <tdevries@suse.de>
PR testsuite/27604
* gdb.dwarf2/dw2-cu-size.S: Add missing .debug_abbrev terminator.
During reviews, I changed the success/failure variables from int to bool, but
missed updating the code in a couple spots. Given the logic inversion, the
gdbserver code fails instead of succeeding.
Fixed with the following patch. Seems fairly obvious, so I'll push it soon.
gdbserver/ChangeLog:
2021-03-30 Luis Machado <luis.machado@linaro.org>
* server.cc (handle_general_set, handle_query): Update variable
to bool and fix verification logic.
The former two are unused anyway. And having such constants isn't very
helpful either, when they live in a place where updating the register
table wouldn't even allow noticing the need to adjust these constants.
st(1) ... st(7) will never be looked up in the hash table, so there's no
point inserting the entries. It's also not really necessary to do a 2nd
hash lookup after parsing the register number, nor is there a real
reason for having both st and st(0) entries. Plus we can easily do away
with the need for st to be first in the table.
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of rounding being in effect off of the type field
of the structure instead.
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of broadcast being in effect off of the type field
of the structure instead.
There's no need for the extra level of indirection and the extra storage
needed for the pointer, pointing from one piece of static data to
another. Key checking of masking being in effect off of the register
field of the structure instead.
All callers pass unsigned values (in some cases by virtue of passing
non-negative literal numbers).
This in turn requires struct {Mask,RC,Broadcast}_Operation's "operand"
fields to become unsigned, in turn allowing to reduce the amount of
casting needed (the two new casts that are necessary cast _to_
"unsigned" instead of _from_, as that's the form that'll never case
undefined behavior).
Seen after converting bfd_boolean to bool.
mmix +FAIL: ld-mmix/zeroehmmo
./ld-new -L/home/alan/src/binutils-gdb/ld/testsuite/ld-mmix -m mmo -Ttext 0xa00 -T /home/alan/src/binutils-gdb/ld/testsuite/ld-mmix/zeroeh.ld -o tmpdir/dump tmpdir/x.o tmpdir/y.o
/home/alan/src/binutils-gdb/bfd/linker.c:2294:8: runtime error: load of value 253, which is not a valid value for type '_Bool'
* elflink.c (elf_link_add_object_symbols): Don't set h->indx
unless is_elf_hash_table.
This patch supports linking powerpc64 glibc with gold, specifically
the __tls_get_addr call in elf/dl-sym.c. That call lacks marker
relocations tying it to the arg setup instructions, but the arg setup
insns are also contructed lacking the usual relocations on a Global
Dynamic TLS code sequence. So there is no chance that anything in
that sequence might be wrongly edited by the linker.
In fact, the aim of linking glibc could have been supported by simply
omitting the error whenever TLS optimisation is disabled, as it is
when linking a shared library. The patch goes further than that,
disabling TLS GD and LD sequence optimisation on a per-object basis
for object files lacking marker relocs.
PR gold/27625
* powerpc.cc (Powerpc_relobj): Add no_tls_marker_, tls_marker_,
and tls_opt_error_ variables and accessors.
(Target_powerpc::Scan::local, global): Call set_tls_marker and
set_no_tls_marker for GD and LD code sequence relocations.
(Target_powerpc::Relocate::relocate): Downgrade the "lacks marker
reloc" error to a warning when safe to do so, and omit the error
entirely if not optimising TLS sequences. Do not optimise GD and
LD sequences for objects lacking marker relocs.
(Target_powerpc::relocate_relocs): Heed no_tls_marker here too.
I noticed that language_info is only ever called with a value of '1'.
This patch removes the parameter.
2021-03-29 Tom Tromey <tromey@adacore.com>
* top.c (check_frame_language_change): Update.
* language.c (language_info): Remove parameter.
* language.h (language_info): Remove parameter.
On aarch64-linux, I noticed the compile command didn't work at all. It
always gave the following error:
aarch64-linux-gnu-g++: error: : No such file or directory
Turns out we're passing an empty argv entry to GCC (because aarch64 doesn't
have a -m64 option), and GCC's behavior is to think that is a file it needs
to open. One can reproduce it like so:
gcc "" "" "" ""
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: fatal error: no input files
compilation terminated.
The solution is to check for an empty string and skip adding that to argv.
Regression tested on aarch64-linux/Ubuntu 18.04/20.04.
gdb/ChangeLog:
2021-03-29 Luis Machado <luis.machado@linaro.org>
* compile/compile.c (get_args): Don't add empty argv entries.
It was reported to me that on Ubuntu 14.04 (fairly old) the documentation
fails to build with the following:
gdb/doc/gdb.texinfo:10888: warning: node `Memory' is up for `Memory Tagging' in sectioning but not in menu
gdb/doc/gdb.texinfo:10693: node `Memory' lacks menu item for `Memory Tagging' despite being its Up target
Makefile:491: recipe for target 'gdb.info' failed
make[3]: *** [gdb.info] Error 1
This doesn't seem to happen on Ubuntu 18.04/20.04, but it does make sense.
Fix this by turning @subsection into a @section and adding the
"Memory Tagging" entry to the menu.
gdb/doc/ChangeLog:
2021-03-29 Luis Machado <luis.machado@linaro.org>
* gdb.textinfo (Memory Tagging): Make it a @section.
