binutils-gdb.git
2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 12 Jul 2022 00:00:22 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agoAlways emit =thread-exited notifications, even if silent
Pedro Alves [Wed, 22 Jun 2022 17:10:00 +0000 (18:10 +0100)]
Always emit =thread-exited notifications, even if silent

[Note: the testcased added by this commit depends on
https://sourceware.org/pipermail/gdb-patches/2022-June/190259.html,
otherwise GDB just crashes when detaching the core]

Currently, in MI, =thread-created are always emitted, like:

 =thread-group-started,id="i1",pid="195680"
 =thread-created,id="1",group-id="i1"
 ...

but on teardown, if the target uses exit_inferior_silent, then you'll
only see the inferior exit notification (thread-group-exited), no
notification for threads.

The core target is one of the few targets that use
exit_inferior_silent.  Here's an example session:

 -target-select core $corefile
 =thread-group-started,id="i1",pid="195680"
 =thread-created,id="1",group-id="i1"
 ...
 ^connected,frame=....
 (gdb)
 -target-detach
 =thread-group-exited,id="i1"
 ^done
 (gdb)

This imbalance of emitting =thread-created but then not =thread-exited
seems off to me.  (And, it complicates changes I want to do to
centralize emitting thread exit notifications for the CLI, which is
why I'm looking at this.)

And then, since most other targets use exit_inferior instead of
exit_inferior_silent, MI is already emitting =thread-exited
notifications when tearing down an inferior, for most targets.

This commit makes MI always emit the =thread-exited notifications,
even for exit_inferior_silent.

Afterwards, when debugging a core, MI outputs:

 (gdb)
 -target-detach
 =thread-exited,id="1",group-id="i1"    << new line
 =thread-group-exited,id="i1"
 ^done
 (gdb)

Surprisingly, there's no MI testcase debugging a core file.  This
commit adds the first.

Change-Id: I5100501a46f07b6bbad3e04d120c2562a51c93a4

2 years agoFix core-file -> detach -> crash (corefiles/29275)
Pedro Alves [Wed, 22 Jun 2022 17:44:37 +0000 (18:44 +0100)]
Fix core-file -> detach -> crash (corefiles/29275)

After loading a core file, you're supposed to be able to use "detach"
to unload the core file.  That unfortunately regressed starting with
GDB 11, with these commits:

 1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
 408f66864a1a - detach in all-stop with threads running

resulting in a GDB crash:

 ...
 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
 2899          if (proc_target->commit_resumed_state)
 (top-gdb) bt
 #0  0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
 #1  0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023
 #2  0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049
 #3  0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791
 #4  0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95
 #5  0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514
 #6  0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699

The code that crashes looks like:

 static void
 maybe_set_commit_resumed_all_targets ()
 {
   scoped_restore_current_thread restore_thread;

   for (inferior *inf : all_non_exited_inferiors ())
     {
       process_stratum_target *proc_target = inf->process_target ();

       if (proc_target->commit_resumed_state)
           ^^^^^^^^^^^

With 'proc_target' above being null.  all_non_exited_inferiors filters
out inferiors that have pid==0.  We get here at the end of
detach_command, after core_target::detach has already run, at which
point the inferior _should_ have pid==0 and no process target.  It is
clear it no longer has a process target, but, it still has a pid!=0
somehow.

The reason the inferior still has pid!=0, is that core_target::detach
just unpushes, and relies on core_target::close to actually do the
getting rid of the core and exiting the inferior.  The problem with
that is that detach_command grabs an extra strong reference to the
process stratum target, so the unpush_target inside
core_target::detach doesn't actually result in a call to
core_target::close.

Fix this my moving the cleaning up the core inferior to a shared
routine called by both core_target::close and core_target::detach.  We
still need to cleanup the inferior from within core_file::close
because there are paths to it that want to get rid of the core without
going through detach.  E.g., "core-file" -> "run".

This commit includes a new test added to gdb.base/corefile.exp to
cover the "core-file core" -> "detach" scenario.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29275

Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893

2 years agoFix non-existent "@var{thread-id}" in stop reply descriptions
Pedro Alves [Mon, 11 Jul 2022 15:05:00 +0000 (16:05 +0100)]
Fix non-existent "@var{thread-id}" in stop reply descriptions

In the description of stop replies, where the "thread" register is
explained, and where the fork and vfork stop reasons are detailed,
there are references to "@var{thread-id}", but such variable does not
actually exist.  This commit fixes it.

Change-Id: If679944aaf15f6f64aabe506339a9e7667864cab

2 years agoTry a couple PAuth compilation flags for gdb.arch/aarch64-pauth.exp
Luis Machado [Thu, 30 Jun 2022 14:23:56 +0000 (15:23 +0100)]
Try a couple PAuth compilation flags for gdb.arch/aarch64-pauth.exp

The -msign-return-address switch has been dropped from GCC, but some
older compiler may still support it.  Make sure we try both
-msign-return-address and -mbranch-protection before bailing out when
running gdb.arch/aarch64-pauth.exp.

2 years agogdb: add support for disassembler styling using libopcodes
Andrew Burgess [Mon, 14 Feb 2022 14:40:52 +0000 (14:40 +0000)]
gdb: add support for disassembler styling using libopcodes

This commit extends GDB to make use of libopcodes styling support
where available, currently this is just i386 based architectures, and
RISC-V.

For architectures that don't support styling using libopcodes GDB will
fall back to using the Python Pygments package, when the package is
available.

The new libopcodes based styling has the disassembler identify parts
of the disassembled instruction, e.g. registers, immediates,
mnemonics, etc, and can style these components differently.
Additionally, as the styling is now done in GDB we can add settings to
allow the user to configure which colours are used right from the GDB
CLI.

There's some new maintenance commands:

  maintenance set libopcodes-styling enabled on|off
  maintenance show libopcodes-styling

These can be used to manually disable use of libopcodes styling.  This
is a maintenance command as it's not anticipated that a user should
need to do this.  But, this could be useful for testing, or, in some
rare cases, a user might want to override the Python hook used for
disassembler styling, and then disable libopcode styling so that GDB
falls back to using Python.  Right now I would consider this second
use case a rare situation, which is why I think a maintenance command
is appropriate.

When libopcodes is being used for styling then the user can make use
of the following new styles:

  set/show style disassembler comment
  set/show style disassembler immediate
  set/show style disassembler mnemonic
  set/show style disassembler register

The disassembler also makes use of the 'address' and 'function'
styles to style some parts of the disassembler output.  I have also
added the following aliases though:

  set/show style disassembler address
  set/show style disassembler symbol

these are aliases for:

  set/show style address
  set/show style function

respectively, and exist to make it easier for users to discover
disassembler related style settings.  The 'address' style is used to
style numeric addresses in the disassembler output, while the 'symbol'
or 'function' style is used to style the names of symbols in
disassembler output.

As not every architecture supports libopcodes styling, the maintenance
setting 'libopcodes-styling enabled' has an "auto-off" type behaviour.
Consider this GDB session:

  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386:x86-64").
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "on".

the setting defaults to "on" for architectures that support libopcodes
based styling.

  (gdb) set architecture sparc
  The target architecture is set to "sparc".
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off" (not supported on architecture "sparc")

the setting will show as "off" if the user switches to an architecture
that doesn't support libopcodes styling.  The underlying setting is
still "on" at this point though, if the user switches back to
i386:x86-64 then the setting would go back to being "on".

  (gdb) maintenance set libopcodes-styling enabled off
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off".

now the setting is "off" for everyone, even if the user switches back
to i386:x86-64 the setting will still show as "off".

  (gdb) maintenance set libopcodes-styling enabled on
  Use of libopcodes styling not supported on architecture "sparc".
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off".

attempting to switch the setting "on" for an unsupported architecture
will give an error, and the setting will remain "off".

  (gdb) set architecture auto
  The target architecture is set to "auto" (currently "i386:x86-64").
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off".
  (gdb) maintenance set libopcodes-styling enabled on
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "on".

the user will need to switch back to a supported architecture before
they can one again turn this setting "on".

2 years agogdb: have gdb_disassemble_info carry 'this' in its stream pointer
Andrew Burgess [Tue, 5 Apr 2022 10:06:16 +0000 (11:06 +0100)]
gdb: have gdb_disassemble_info carry 'this' in its stream pointer

The gdb_disassemble_info class is a wrapper around the libopcodes
disassemble_info struct.  The 'stream' field of disassemble_info is
passed as an argument to the fprintf_func and fprintf_styled_func
callbacks when the disassembler wants to print anything.

Previously, GDB would store a pointer to a ui_file object in the
'stream' field, then, when the disassembler wanted to print anything,
the content would be written to the ui_file object.  An example of an
fprintf_func callback, from gdb/disasm.c is:

  int
  gdb_disassembler::dis_asm_fprintf (void *stream, const char *format, ...)
  {
    /* Write output to STREAM here.  */
  }

This is fine, but has one limitation, within the print callbacks we
only have access to STREAM, we can't access any additional state
stored within the gdb_disassemble_info object.

Right now this isn't a problem, but in a future commit this will
become an issue, how we style the output being written to STREAM will
depend on the state of the gdb_disassemble_info object, and this state
might need to be updated, depending on what is being printed.

In this commit I propose changing the 'stream' field of the
disassemble_info to carry a pointer to the gdb_disassemble_info
sub-class, rather than the stream itself.

We then have the two sub-classes of gdb_disassemble_info to consider,
the gdb_non_printing_disassembler class never cared about the stream,
previously, for this class, the stream was nullptr.  With the change
to make stream be a gdb_disassemble_info pointer, no further updates
are needed for gdb_non_printing_disassembler.

The other sub-class is gdb_printing_disassembler.  In this case the
sub-class now carries around a pointer to the stream object.  The
print callbacks are updated to cast the incoming stream object back to
a gdb_printing_disassembler, and then extract the stream.

This is purely a refactoring commit.  A later commit will add
additional state to the gdb_printing_disassembler, and update the
print callbacks to access this state.

There should be no user visible changes after this commit.

2 years ago[gdb/symtab] Fix data race in per_cu->length
Tom de Vries [Mon, 11 Jul 2022 09:36:54 +0000 (11:36 +0200)]
[gdb/symtab] Fix data race in per_cu->length

With gdb build with -fsanitize=thread and test-case
gdb.dwarf2/dw4-sig-types.exp and target board cc-with-dwz-m we run into a data
race between:
...
  Write of size 4 at 0x7b2800002268 by thread T4:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6236 \
    (gdb+0x82f525)^M
...
and this read:
...
  Previous read of size 4 at 0x7b2800002268 by thread T1:^M
    #0 dwarf2_find_containing_comp_unit gdb/dwarf2/read.c:23444 \
    (gdb+0x86e22e)^M
...

In other words, between this write:
...
    this_cu->length = cu->header.get_length ();
...
and this read:
...
      && mid_cu->sect_off + mid_cu->length > sect_off))
...
of per_cu->length.

Fix this similar to the per_cu->dwarf_version case, by only setting it if
needed, and otherwise verifying that the same value is used.  [ Note that the
same code is already present in the other cutu_reader constructor. ]

Move this logic into into a member function set_length to make sure it's used
consistenly, and make the field private in order to enforce access through the
member functions, and rename it to m_length.

This exposes (running test-case gdb.dwarf2/fission-reread.exp) that in
fill_in_sig_entry_from_dwo_entry, the m_length field is overwritten.
For now, allow for that exception.

While we're at it, make sure that the length is set before read.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29344

2 years ago[gdb/symtab] Use comp_unit_head::get_length
Tom de Vries [Mon, 11 Jul 2022 09:36:54 +0000 (11:36 +0200)]
[gdb/symtab] Use comp_unit_head::get_length

There's a spot in read_comp_units_from_section where we explictly use
initial_length_size to get the total length:
...
      this_cu->length = cu_header.length + cu_header.initial_length_size;
...

Instead, just use cu_header.get_length ().

Tested on x86_64-linux.

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 11 Jul 2022 00:00:24 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agoFix include guard naming for arch/aarch64-mte-linux.h
Luis Machado [Mon, 4 Jul 2022 09:43:25 +0000 (10:43 +0100)]
Fix include guard naming for arch/aarch64-mte-linux.h

It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H.

2 years agogdbserver: LoongArch: Add orig_a0 processing
Youling Tang [Sun, 10 Jul 2022 02:57:33 +0000 (10:57 +0800)]
gdbserver: LoongArch: Add orig_a0 processing

Commit 736918239b16 ("gdb: LoongArch: add orig_a0 into register set")
introduced orig_a0, similar processing needs to be done in gdbserver.

At the same time, add orig_a0 related comments.

Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2 years agogdbserver: LoongArch: Simplify code with register number macros
Youling Tang [Sun, 10 Jul 2022 02:22:33 +0000 (10:22 +0800)]
gdbserver: LoongArch: Simplify code with register number macros

Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the
macro definitions can be used in gdbserver/linux-loongarch-low.cc
to simplify the code.

Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 10 Jul 2022 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agogas: tc-tic54x.c hash tables
Alan Modra [Fri, 8 Jul 2022 08:07:07 +0000 (17:37 +0930)]
gas: tc-tic54x.c hash tables

Cleaning up the subsym_hash memory is a real pain.  Keys and values
entered into the table are quite diverse.  In some cases the key is
allocated and thus needs to be freed, in others the key is a const
string.  Values are similar, and in some cases not even a string.
Tidy this by inserting a new subsym_ent_t that describes key/value
type.  This meant the math_hash table was no longer needed.  The patch
also tidies how math functions are called, those that are supposed to
return int now no longer return their value in a float.

* config/tc-tic54x.c (math_hash): Delete.
(subsym_proc_entry): Move earlier, make proc a union, merge with..
(math_proc_entry): ..this.  Delete type.
(math_procs): Merge into subsym_procs.
(subsym_ent_t): New.  Use this type in subsym_hash..
(stag_add_field_symbols, tic54x_var, tic54x_macro_info): ..here..
(md_begin, subsym_create_or_replace, subsym_lookup): ..and here..
(subsym_substitute): ..and here.  Adjust subsym_proc_entry
function calls.  Free replacement when not returned.
(subsym_get_arg): Adjust subsym_lookup.
(free_subsym_ent, subsym_htab_create ): New functions, use when
creating subsym_hash.
(free_local_label_ent, local_label_htab_create): Similarly.
(tic54x_remove_local_label): Delete.
(tic54x_clear_local_labels): Simplify.
(tic54x_asg): Use notes obstack to dup strings.
(tic54x_eval): Likewise.
(subsym_ismember): Likewise.
(math_cvi, math_int, math_sgn): Return int.
(tic54x_macro_start): Decrement macro_level before calling as_fatal.
(tic54x_md_end): New function.
* config/tc-tic54h.c (tic54x_md_end): Declare.
(md_end): Define.

2 years agogas: use notes_calloc in string hash
Alan Modra [Wed, 6 Jul 2022 23:19:09 +0000 (08:49 +0930)]
gas: use notes_calloc in string hash

Using notes_calloc means all of the string hash table memory should
now be freed before gas exits, even though htab_delete isn't called.
This also means that the hash table free_f and del_f must be NULL,
because freeing notes obstack memory results in all more recently
allocated notes memory being freed too.  So hash table resizing won't
free any memory, and will be a little faster.  Also, htab_delete won't
do anything (and be quick about it).

Since htab_traverse can also resize hash tables (to make another
traversal faster if the table is largely empty), stop that happening
when only one traversal is done.

* as.h: Reorder hash.h after symbols.h for notes_calloc decl.
* hash.h (str_htab_create): Use notes_calloc.  Do not free.
* symbols.c (resolve_local_symbol_values): Don't resize
during hash table traversal.
* config/obj-elf.c (elf_frob_file_after_relocs): Likewise.
* config/tc-ia64.c (ia64_adjust_symtab, ia64_frob_file): Likewise.
* config/tc-nds32.c (nds32_elf_analysis_relax_hint): Likewise.

2 years agogas: target string hash tables
Alan Modra [Wed, 6 Jul 2022 00:24:21 +0000 (09:54 +0930)]
gas: target string hash tables

This allocates entries added to the string hash tables on the notes
obstack, so that at least those do not leak.  A followup patch will
switch over the str_hash allocation to notes_calloc, which is why I
haven't implemented deleting all the target string hash tables.

* config/obj-coff-seh.c (get_pxdata_name, alloc_pxdata_item): Use
notes obstack for string hash table entries.
* config/tc-alpha.c (get_alpha_reloc_tag, md_begin): Likewise.
* config/tc-h8300.c (md_begin): Likewise.
* config/tc-ia64.c (dot_rot, dot_pred_rel, dot_alias): Likewise.
* config/tc-nds32.c (nds32_relax_hint): Likewise.
* config/tc-riscv.c (riscv_init_csr_hash): Likewise.
* config/tc-score.c (s3_insert_reg): Likewise.
(s3_build_score_ops_hsh, s3_build_dependency_insn_hsh): Likewise.
* config/tc-score7.c (s7_build_score_ops_hsh): Likewise.
(s7_build_dependency_insn_hsh): Likewise.
* config/tc-tic4x.c (tic4x_asg): Likewise.

2 years agoarc gas: don't leak arc_opcode_hash memory
Alan Modra [Thu, 7 Jul 2022 12:39:28 +0000 (22:09 +0930)]
arc gas: don't leak arc_opcode_hash memory

The arc opcode hash table has entries that have a realloc'd field.
This doesn't lend itself to obstack allocation, so freeing must be
done with a purpose built hashtab del_f.

* config/tc-arc.c (arc_opcode_free): New function.
(md_begin): Pass the above as del_f to htab_create_alloc.
(arc_md_end): New function.
* config/tc-arc.h (arc_md_end): Declare.
(md_end): Define.

2 years agoi386 gas: don't leak op_hash or reg_hash memory
Alan Modra [Thu, 7 Jul 2022 12:36:55 +0000 (22:06 +0930)]
i386 gas: don't leak op_hash or reg_hash memory

This tidies memory used by the two x86 gas string hash tables before
exiting.  I'm using a two-pronged approach, firstly the obvious call
to htab_delete plus telling the libiberty/hashtab.c infrastructure to
free tuples generated by str_hash_insert, and secondly putting the x86
core_optab memory on the notes obstack.  It would be possible to free
core_optab memory by using a custom hash table del_f on x86, as I do
for arc, but a later patch will move all the string hash memory to the
notes obstack.

* config/tc-i386.c (md_begin): Use notes_alloc for core_optab.
(386_md_end): New function.
* config/tc-i386.h (386_md_end): Declare.
(md_end): Define.
* hash.h (str_htab_create): Pass free as del_f.

2 years agoppc gas: don't leak ppc_hash memory
Alan Modra [Thu, 7 Jul 2022 12:33:15 +0000 (22:03 +0930)]
ppc gas: don't leak ppc_hash memory

* config/tc-ppc.c (insn_obstack): New.
(insn_calloc): New function.
(ppc_setup_opcodes): Use insn_obstack for ppc_hash.
(ppc_md_end): New function.
* config/tc-ppc.h (ppc_md_end): Declare
(md_end): Define.

2 years agogas hash.h tidy
Alan Modra [Thu, 7 Jul 2022 04:20:29 +0000 (13:50 +0930)]
gas hash.h tidy

Only inline functions should be defined in hash.h, there's no benefit
in having multiple copies of hash_string_tuple and eq_string_tuple.
Also, use the table alloc_f when allocating tuples to be stored, so
that these functions are usable with different memory allocation
strategies.

* hash.h (struct string_tuple, string_tuple_t): Move earlier.
(string_tuple_alloc): Add table param, allocate using table alloc_f.
(str_hash_insert): Adjust to suit.  Call table->free_f when
entry is not used.
(hash_string_tuple, eq_string_tuple): Move to..
* hash.c: ..here.

2 years agogas: rename md_end to md_finish
Alan Modra [Tue, 5 Jul 2022 03:56:38 +0000 (13:26 +0930)]
gas: rename md_end to md_finish

Currently md_end is typically used for some final actions rather than
freeing memory like other *_end functions.  Rename it to md_finish,
and rename target implementation.  The renaming of target functions
makes it possible to find them all with "grep md_finish",
eg. md_mips_end is renamed to mips_md_finish, not md_mips_finish.
This patch leaves a number of md_end functions unchanged, those that
either do nothing or deallocate memory, and calls them late.

The idea here is that target maintainers implement md_end functions to
tidy memory, if anyone cares.  Freeing persistent memory in gas is
not at all important, except that it can hide more important memory
leaks, those that happen once per some frequent gas operation, amongst
these unimportant memory leaks.

* as.c (main): Rename md_end to md_finish.
* config/tc-alpha.c, * config/tc-alpha.h,
* config/tc-arc.c, * config/tc-arc.h,
* config/tc-arm.c, * config/tc-arm.h,
* config/tc-csky.c, * config/tc-csky.h,
* config/tc-ia64.c, * config/tc-ia64.h,
* config/tc-mcore.c, * config/tc-mcore.h,
* config/tc-mips.c, * config/tc-mips.h,
* config/tc-mmix.c, * config/tc-mmix.h,
* config/tc-msp430.c, * config/tc-msp430.h,
* config/tc-nds32.c, * config/tc-nds32.h,
* config/tc-ppc.c, * config/tc-ppc.h,
* config/tc-pru.c, * config/tc-pru.h,
* config/tc-riscv.c, * config/tc-riscv.h,
* config/tc-s390.c, * config/tc-s390.h,
* config/tc-sparc.c, * config/tc-sparc.h,
* config/tc-tic4x.c, * config/tc-tic4x.h,
* config/tc-tic6x.c, * config/tc-tic6x.h,
* config/tc-v850.c, * config/tc-v850.h,
* config/tc-xtensa.c, * config/tc-xtensa.h,
* config/tc-z80.c, * config/tc-z80.h: Similarly.
* output-file.c (output_file_close): Call md_end.

2 years agogas: set up notes obstack earlier
Alan Modra [Thu, 7 Jul 2022 04:02:30 +0000 (13:32 +0930)]
gas: set up notes obstack earlier

So that the notes obstack can be used for persistent storage in
parse_args.

* as.c (parse_args): Use notes_alloc and notes_strdup.
(free_notes): New function.
(main): Init notes obstack, and arrange to be freed on exit.
* read.c (read_begin): Don't init notes obstack.
(read_end): Free cond_obstack.
* subsegs.c (subsegs_end): Don't free cond_obstack or notes.

2 years agogas: itbl_files
Alan Modra [Thu, 7 Jul 2022 10:49:44 +0000 (20:19 +0930)]
gas: itbl_files

itbl_files seems to be debug code.  Get rid of it.

* as.c (struct itbl_file_list): Delete.
(itbl_files): Delete.
(parse_args): Don't keep itbl_files list.

2 years agogas: free sy_hash, macro_hash and po_hash
Alan Modra [Tue, 5 Jul 2022 03:30:41 +0000 (13:00 +0930)]
gas: free sy_hash, macro_hash and po_hash

* macro.c (macro_end): New function.
* macro.h (macro_end): Declare.
* read.c (read_end, poend): New functions.
* read.h (read_end): Declare.
* symbols.c (symbol_end): New function.
* symbols.h (symbol_end): Declare.
* output-file.c (output_file_close): Call new *_end functions.

2 years agodw2gencfi.c: use notes obstack
Alan Modra [Thu, 7 Jul 2022 23:18:16 +0000 (08:48 +0930)]
dw2gencfi.c: use notes obstack

Use notes obstack for dwcfi_hash entries, and free table.  Freeing the
table makes memory checkers complain more about "definitely lost"
memory as we've moved some from the "still reachable" category.
That will be fixed with a later patch.

* dw2gencfi.c (get_debugseg_name): Allocate on notes obstack.
(alloc_debugseg_item): Likewise.
(dwcfi_hash_find_or_make): Adjust failure path free.
(cfi_finish): Delete dwfci_hash.

2 years agoexpr.c make_expr_symbol: use notes obstack
Alan Modra [Tue, 5 Jul 2022 02:08:46 +0000 (11:38 +0930)]
expr.c make_expr_symbol: use notes obstack

* expr.c (make_expr_symbol): Use notes_alloc.

2 years agoread.c assign_symbol: use notes obstack for dummy listing frag
Alan Modra [Tue, 5 Jul 2022 01:22:17 +0000 (10:52 +0930)]
read.c assign_symbol: use notes obstack for dummy listing frag

* read.c (assign_symbol): Use notes_calloc for dummy_frag.

2 years agoread.c s_include: use notes obstack for path
Alan Modra [Tue, 5 Jul 2022 01:17:48 +0000 (10:47 +0930)]
read.c s_include: use notes obstack for path

* read.c (s_include): Use notes obstack for path mem.

2 years agomacro.c: use string hash from hash.h for macro_hash
Alan Modra [Wed, 6 Jul 2022 23:07:10 +0000 (08:37 +0930)]
macro.c: use string hash from hash.h for macro_hash

Another case of duplicated hash.h code, the only minor difference
being that macro->format_hash was created with 7 entries vs. str_hash
with 16 entries.

* macro.c (macro_init, define_macro): Use str_htab_create.
(do_formals, define_macro, macro_expand_body): Use str_hash_insert
(macro_expand_body): Use str_hash_find and str_hash_delete.
(delete_macro): Likewise.
(sub_actual, macro_expand, check_macro): Use str_hash_find.
(expand_irp): Use str_htab_create and str_hash_insert.
* macro.h (struct macro_struct): Tidy.
(struct macro_hash_entry, macro_hash_entry_t, hash_macro_entry),
(eq_macro_entry, macro_entry_alloc, macro_entry_find),
(struct formal_hash_entry, formal_hash_entry_t),
(hash_formal_entry, eq_formal_entry, formal_entry_alloc),
(formal_entry_find): Delete.
* config/tc-iq2000.c (iq2000_add_macro): Use str_htab_create
and str_hash_insert.

2 years agoread.c: use string hash from hash.h for po_hash
Alan Modra [Tue, 5 Jul 2022 00:21:18 +0000 (09:51 +0930)]
read.c: use string hash from hash.h for po_hash

po_hash code duplicates the str_hash code in hash.h for no good reason.

* read.c (struct po_entry, po_entry_t): Delete.
(hash_po_entry, eq_po_entry, po_entry_alloc, po_entry_find): Delete.
(pop_insert): Use str_hash_insert.
(pobegin): Use str_htab_create.
(read_a_source_file, s_macro): Use str_hash_find.

2 years agofree read_symbol_name string
Alan Modra [Tue, 5 Jul 2022 00:21:57 +0000 (09:51 +0930)]
free read_symbol_name string

read_symbol_name mallocs the string it returns.  Free it when done.

* read.c (read_symbol_name): Free name on error path.
* config/tc-ppc.c (ppc_GNU_visibility): Free name returned from
read_symbol_name.
(ppc_extern, ppc_globl, ppc_weak): Likewise.

2 years agogas: output_file_close
Alan Modra [Thu, 7 Jul 2022 10:26:10 +0000 (19:56 +0930)]
gas: output_file_close

This is mostly a tidy with the aim of being able to free
out_file_name, but it does fix a possible attempt to unlink the output
file twice (not that that matters).

* as.h (keep_it): New global.
* as.c (keep_it): Delete.
(close_output_file): Delete, merged into..
* output-file.c (output_file_close): ..here.  Delete parameter.
* output-file.h (output_file_close): Update prototype.

2 years agogas: utility notes memory alloc functions
Alan Modra [Wed, 6 Jul 2022 23:10:26 +0000 (08:40 +0930)]
gas: utility notes memory alloc functions

Makes it a little easier to use the notes obstack for persistent
storage.

* as.h (gas_mul_overflow): Define.
* symbols.h (notes_alloc, notes_calloc, notes_memdup),
(notes_strdup, notes_concat, notes_free): Declare.
* symbols.c (notes_alloc, notes_calloc, notes_memdup),
(notes_strdup, notes_concat, notes_free): New functions.
(save_symbol_name): Use notes_strdup.
(symbol_create, local_symbol_make, local_symbol_convert),
(symbol_clone, decode_local_label_name): Use notes_alloc.

2 years agogas: arm -mwarn-syms duplicates
Alan Modra [Thu, 7 Jul 2022 12:11:17 +0000 (21:41 +0930)]
gas: arm -mwarn-syms duplicates

arm gas is only supposed to warn once per symbol for -mwarn-syms, but
doesn't because the str_hash_find added with commit 629310abec88
always returns NULL.  That's so because the str_hash_insert inserts a
NULL value for the key,value pair.  Let str_hash_insert do the job
instead.

* config/tc-arm.c (arm_tc_equal_in_insn): Correct already_warned
logic.
* testsuite/gas/arm/pr18347.s: Modify to generate duplicate
warning without this patch.

2 years agoRegenerate with automake-1.15.1
Alan Modra [Sat, 9 Jul 2022 08:09:38 +0000 (17:39 +0930)]
Regenerate with automake-1.15.1

Until we update the recommended versions of autoconf/automake, files
should be regenerated with automake-1.15.1 and autoconf-2.69.  That's
not because we think those versions are golden, and newer versions are
bad.  It's simply because maintainers want to be able to update
configury files without trouble, and if someone regenerates files with
automake-1.16.5 then --enable-maintainer-mode builds will hit errors:

checking that generated files are newer than configure... configure.ac:26: error: version mismatch.  This is Automake 1.15.1,
configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:26: comes from Automake 1.16.5.  You should recreate
configure.ac:26: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.15' is probably too old.

Correcting this requires regenerating the files by hand.

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 9 Jul 2022 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agoAccept gdb.Value in more Python APIs
Tom Tromey [Sun, 5 Jun 2022 13:42:12 +0000 (07:42 -0600)]
Accept gdb.Value in more Python APIs

PR python/27000 points out that gdb.block_for_pc will accept a Python
integer, but not a gdb.Value.  This patch corrects this oversight.

I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
get_addr_from_python instead.  I also looked at uses of GDB_PY_LL_ARG,
but those seemed relatively unlikely to be useful with a gdb.Value, so
I didn't change them.  My thinking here is that a Value will typically
come from inferior memory, and something like a line number is not too
likely to be found this way.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27000

2 years agoHandle bool specially in gdb.set_parameter
Tom Tromey [Sun, 12 Jun 2022 17:36:08 +0000 (11:36 -0600)]
Handle bool specially in gdb.set_parameter

PR python/29217 points out that gdb.parameter will return bool values,
but gdb.set_parameter will not properly accept them.  This patch fixes
the problem by adding a special case to set_parameter.

I looked at a fix involving rewriting set_parameter in C++.  However,
this one is simpler.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29217

2 years ago[gdb/build] Handle deprecation of scm_install_gmp_memory_functions
Ludovic Courtès [Fri, 8 Jul 2022 14:01:16 +0000 (16:01 +0200)]
[gdb/build] Handle deprecation of scm_install_gmp_memory_functions

When building gdb with guile 3.0.8, we run into:
...
gdb/guile/guile.c: In function \
  'void gdbscm_initialize(const extension_language_defn*)':
gdb/guile/guile.c:680:5: error: 'scm_install_gmp_memory_functions' is \
  deprecated [-Werror=deprecated-declarations]
  680 |     scm_install_gmp_memory_functions = 0;
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/guile/3.0/libguile.h:128,
                 from gdb/guile/guile-internal.h:30,
                 from gdb/guile/guile.c:36:
/usr/include/guile/3.0/libguile/deprecated.h:164:20: note: declared here
  164 | SCM_DEPRECATED int scm_install_gmp_memory_functions;
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1896: guile/guile.o] Error 1
...

The variable has been deprecated because it no longer has any effect.

Fix this by disabling the specific deprecation warning.

Also handle upcoming guile versions > 3.0, in which the variable will be
removed, by limiting the usage of the variable to guile versions <= 3.0.

This does not break anything.  The variable was merely used to address a
problem present in guile versions <= v3.0.5.

Note that we don't limit the usage of the variable to guile versions <= 3.0.5,
because we want to support f.i. building against 3.0.6 and then using a shared
lib with 3.0.5.

Tested on x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28994

2 years ago[gdb/symtab] Fix assert in process_imported_unit_die
Tom de Vries [Fri, 8 Jul 2022 13:56:06 +0000 (15:56 +0200)]
[gdb/symtab] Fix assert in process_imported_unit_die

When running test-case gdb.dwarf2/dw2-symtab-includes.exp with target board
cc-with-debug-names, I run into:
...
(gdb) maint expand-symtab dw2-symtab-includes.h^M
src/gdb/dwarf2/read.h:311: internal-error: unit_type: \
  Assertion `m_unit_type != 0' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.dwarf2/dw2-symtab-includes.exp: maint expand-symtab \
  dw2-symtab-includes.h (GDB internal error)
...

The assert was recently added in commit 2c474c46943 ("[gdb/symtab] Add get/set
functions for per_cu->lang/unit_type").

The assert is triggered here:
...
    /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
       into another compilation unit, at root level.  Regard this as a hint,
       and ignore it.  */
    if (die->parent && die->parent->parent == NULL
        && per_cu->unit_type () == DW_UT_compile
        && per_cu->lang () == language_cplus)
      return;
...

We're trying to access unit_type / lang which hasn't been set yet.

Normally, these are set during cooked index creation, but that's not the case
when using an index (or using -readnow).

In other words, this lto binary reading speed optimization only works in the
normal use case.

IWBN to have this working in all use cases, but for now, allow lang () and
unit_type () to return language_unknown and 0 here.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29321

2 years ago[gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p
Tom de Vries [Fri, 8 Jul 2022 13:56:06 +0000 (15:56 +0200)]
[gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p

When running test-case gdb.cp/cpexprs-debug-types.exp with target board
cc-with-debug-names, I run into:
...
(gdb) print base::operator new^M
^M
^M
Fatal signal: Segmentation fault^M
----- Backtrace -----^M
0x57ea46 gdb_internal_backtrace_1^M
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122^M
0x57eae9 _Z22gdb_internal_backtracev^M
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168^M
0x75b8ad handle_fatal_signal^M
        /home/vries/gdb_versions/devel/src/gdb/event-top.c:946^M
0x75ba19 handle_sigsegv^M
        /home/vries/gdb_versions/devel/src/gdb/event-top.c:1019^M
0x7f795f46a8bf ???^M
0x6d3cb1 _ZNK18dwarf2_per_objfile12symtab_set_pEPK18dwarf2_per_cu_data^M
        /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1515^M
...

The problem is in this piece of code in dw2_debug_names_iterator::next:
...
        case DW_IDX_type_unit:
          /* Don't crash on bad data.  */
          if (ull >= per_bfd->tu_stats.nr_tus)
            {
              complaint (_(".debug_names entry has bad TU index %s"
                           " [in module %s]"),
                         pulongest (ull),
                         objfile_name (objfile));
              continue;
            }
          per_cu = per_bfd->get_cu (ull + per_bfd->tu_stats.nr_tus);
          break;
...

The all_comp_units vector (which get_cu accesses) contains both CUs and TUs,
with CUs first.

So to get the nth TU we need the element at "nr_cus + n", but
the code uses "nr_tus + n" instead.

Fix this by using "nr_cus + n".

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29334

2 years agogdb: initialize the data_head variable to eliminate compilation warnings
Enze Li [Sat, 11 Jun 2022 10:36:48 +0000 (18:36 +0800)]
gdb: initialize the data_head variable to eliminate compilation warnings

On a machine with gcc 12, I get this warning:

  CXX    nat/linux-btrace.o
In function â€˜btrace_error linux_read_bts(btrace_data_bts*, btrace_target_info*, btrace_read_type)’,
    inlined from â€˜btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ at ../gdb/nat/linux-btrace.c:935:29:
../gdb/nat/linux-btrace.c:865:21: warning: â€˜data_head’ may be used uninitialized [-Wmaybe-uninitialized]
  865 |   pevent->last_head = data_head;
      |   ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
../gdb/nat/linux-btrace.c: In function â€˜btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’:
../gdb/nat/linux-btrace.c:792:9: note: â€˜data_head’ was declared here
  792 |   __u64 data_head, data_tail;
      |         ^~~~~~~~~

Fix this by initializing the 'data_head' variable.

Tested by rebuilding on x86_64 openSUSE Tumbleweed with gcc 12.

2 years agolibopcodes/s390: add support for disassembler styling
Andrew Burgess [Tue, 5 Jul 2022 13:17:14 +0000 (14:17 +0100)]
libopcodes/s390: add support for disassembler styling

This commit adds disassembler style to the libopcodes s390
disassembler.  This conversion was pretty straight forward, I just
converted the fprintf_func calls to fprintf_styled_func calls and
added an appropriate style.

For testing the new styling I just assembled then disassembled the
source files in gas/testsuite/gas/s390 and manually checked that the
styling looked reasonable.

If the user does not request styled output from objdump, then there
should be no change in the disassembler output after this commit.

2 years agoFix regeneration of ld configure and makefiles
Nick Clifton [Fri, 8 Jul 2022 11:41:48 +0000 (12:41 +0100)]
Fix regeneration of ld configure and makefiles

2 years agoUpdate release README with new version numbers
Nick Clifton [Fri, 8 Jul 2022 10:55:59 +0000 (11:55 +0100)]
Update release README with new version numbers

2 years agoUpdate version to 2.39.50 and regenerate files
Nick Clifton [Fri, 8 Jul 2022 10:19:44 +0000 (11:19 +0100)]
Update version to 2.39.50 and regenerate files

2 years agoAdd markers for 2.39 branch
Nick Clifton [Fri, 8 Jul 2022 09:41:07 +0000 (10:41 +0100)]
Add markers for 2.39 branch

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 8 Jul 2022 00:00:16 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agogprofng: fix regression in testing for not yet installed version
Vladimir Mezentsev [Thu, 7 Jul 2022 20:20:39 +0000 (13:20 -0700)]
gprofng: fix regression in testing for not yet installed version

gprofng/ChangeLog
2022-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/Settings.cc (Settings::read_rc): Read environment variable
GPROFNG_SYSCONFDIR.
* testsuite/lib/Makefile.skel: Export GPROFNG_SYSCONFDIR.
* testsuite/gprofng.display/display.exp: Shorten the list of tests.

2 years agogdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid
Simon Marchi [Wed, 6 Jul 2022 17:39:22 +0000 (13:39 -0400)]
gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid

Trying to run a simple program (empty main) on AIX, I get:

    (gdb) run
    Starting program: /scratch/simark/build/gdb/a.out
    Child process unexpectedly missing: There are no child processes..
    ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ----- Backtrace -----
    0x10ef12a8 gdb_internal_backtrace_1()
            ../../src/binutils-gdb/gdb/bt-utils.c:122
    0x10ef1470 gdb_internal_backtrace()
            ../../src/binutils-gdb/gdb/bt-utils.c:168
    0x1004d368 internal_vproblem(internal_problem*, char const*, int, char const*, char*)
            ../../src/binutils-gdb/gdb/utils.c:396
    0x1004d8a8 internal_verror(char const*, int, char const*, char*)
            ../../src/binutils-gdb/gdb/utils.c:476
    0x1004c424 internal_error(char const*, int, char const*, ...)
            ../../src/binutils-gdb/gdbsupport/errors.cc:55
    0x102ab344 find_inferior_pid(process_stratum_target*, int)
            ../../src/binutils-gdb/gdb/inferior.c:304
    0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t)
            ../../src/binutils-gdb/gdb/inferior.c:318
    0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t)
            ../../src/binutils-gdb/gdb/thread.c:519
    0x10319e98 handle_inferior_event(execution_control_state*)
            ../../src/binutils-gdb/gdb/infrun.c:5532
    0x10315544 fetch_inferior_event()
            ../../src/binutils-gdb/gdb/infrun.c:4221
    0x10952e34 inferior_event_handler(inferior_event_type)
            ../../src/binutils-gdb/gdb/inf-loop.c:41
    0x1032640c infrun_async_inferior_event_handler(void*)
            ../../src/binutils-gdb/gdb/infrun.c:9548
    0x10673188 check_async_event_handlers()
            ../../src/binutils-gdb/gdb/async-event.c:335
    0x1066fce4 gdb_do_one_event()
            ../../src/binutils-gdb/gdbsupport/event-loop.cc:214
    0x10001a94 start_event_loop()
            ../../src/binutils-gdb/gdb/main.c:411
    0x10001ca0 captured_command_loop()
            ../../src/binutils-gdb/gdb/main.c:471
    0x10003d74 captured_main(void*)
            ../../src/binutils-gdb/gdb/main.c:1329
    0x10003e48 gdb_main(captured_main_args*)
            ../../src/binutils-gdb/gdb/main.c:1344
    0x10000744 main
            ../../src/binutils-gdb/gdb/gdb.c:32
    ---------------------
    ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

This is due to some bit-rot in the AIX port, still relying on the entry
value of inferior_ptid in the wait methods.

Problem #1 is in rs6000_nat_target::wait, here:

      /* Ignore terminated detached child processes.  */
      if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ())
pid = -1;

At this point, waitpid has returned an "exited" status for some pid, so
pid is non-zero.  Since inferior_ptid is set to null_ptid on entry, the
pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset
pid to -1 and go to waiting again.  Since there are not more children to
wait for, waitpid then returns -1 so we get here:

      if (pid == -1)
{
  gdb_printf (gdb_stderr,
      _("Child process unexpectedly missing: %s.\n"),
      safe_strerror (save_errno));

  /* Claim it exited with unknown signal.  */
  ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN);
  return inferior_ptid;
}

We therefore return a "signalled" status with a null_ptid (again,
inferior_ptid is null_ptid).  This confuses infrun, because if the
target returns a "signalled" status, it should be coupled with a ptid
for an inferior that exists.

So, the first step is to fix the snippets above to not use
inferior_ptid.  In the first snippet, use find_inferior_pid to see if
we know the event process.  If there is no inferior with that pid, we
assume it's a detached child process to we ignore the event.  That
should be enough to fix the problem, because it should make it so we
won't go into the second snippet.  But still, fix the second snippet to
return an "ignore" status.  This is copied from inf_ptrace_target::wait,
which is where rs6000_nat_target::wait appears to be copied from in the
first place.

These changes, are not sufficient, as the aix_thread_target, which sits
on top of rs6000_nat_target, also relies on inferior_ptid.
aix_thread_target::wait, by calling pd_update, assumes that
rs6000_nat_target has set inferior_ptid to the appropriate value (the
ptid of the event thread), but that's not the case.  pd_update
returns inferior_ptid - null_ptid - and therefore
aix_thread_target::wait returns null_ptid too, and we still hit the
assert shown above.

Fix this by changing pd_activate, pd_update, sync_threadlists and
get_signaled_thread to all avoid using inferior_ptid.  Instead, they
accept as a parameter the pid of the process we are working on.

With this patch, I am able to run the program to completion:

    (gdb) r
    Starting program: /scratch/simark/build/gdb/a.out
    [Inferior 1 (process 11010794) exited normally]

As well as break on main:

    (gdb) b main
    Breakpoint 1 at 0x1000036c
    (gdb) r
    Starting program: /scratch/simark/build/gdb/a.out

    Breakpoint 1, 0x1000036c in main ()
    (gdb) c
    Continuing.
    [Inferior 1 (process 26083688) exited normally]

Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9

2 years agoFix pedantically invalid DWARF in gdb.trace/unavailable-dwarf-piece.exp
Pedro Alves [Thu, 7 Jul 2022 12:05:50 +0000 (13:05 +0100)]
Fix pedantically invalid DWARF in gdb.trace/unavailable-dwarf-piece.exp

The DWARF spec says:

  Any debugging information entry representing the declaration of an object,
  module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
  DW_AT_decl_column attributes, each of whose value is an unsigned integer
  ^^^^^^^^
  constant.

Grepping around the DWARF-assembler-based testcases, I noticed that
gdb.trace/unavailable-dwarf-piece.exp emits decl_line with
DW_FORM_sdata, a signed integer form.  This commit tweaks it to use
DW_FORM_udata instead.

Unsurprisingly, this:

  $ make check \
      TESTS="gdb.trace/unavailable-dwarf-piece.exp" \
      RUNTESTFLAGS="--target_board=native-gdbserver"

... still passes cleanly for me after this change.

I've noticed this because current llvm-dwarfdump crashed on an
ROCm-internal DWARF-assembler-based testcase that incorrectly used
signed forms for DW_AT_decl_file/DW_AT_decl_line.

The older llvm-dwarfdump found on Ubuntu 20.04 (LLVM 10) reads the
line numbers with signed forms as "0" instead of crashing.  Here's the
before/after fix for gdb.trace/unavailable-dwarf-piece.exp with that
llvm-dwarfdump version:

  $ diff -up before.txt after.txt
  --- before.txt    2022-07-07 13:21:28.387690334 +0100
  +++ after.txt     2022-07-07 13:21:39.379801092 +0100
  @@ -18,7 +18,7 @@
   DW_AT_name     ("s")
   DW_AT_byte_size        (3)
   DW_AT_decl_file        (0)
  -                DW_AT_decl_line        (0)
  +                DW_AT_decl_line        (1)

   0x0000002f:     DW_TAG_member
     DW_AT_name   ("a")
  @@ -41,7 +41,7 @@
   DW_AT_name     ("t")
   DW_AT_byte_size        (3)
   DW_AT_decl_file        (0)
  -                DW_AT_decl_line        (0)
  +                DW_AT_decl_line        (1)

   0x00000054:     DW_TAG_member
     DW_AT_name   ("a")

Change-Id: I5c866946356da421ff944019d0eca2607b2b738f

2 years agogdb: LoongArch: Fix typos in code comments
Tiezhu Yang [Thu, 7 Jul 2022 09:53:40 +0000 (17:53 +0800)]
gdb: LoongArch: Fix typos in code comments

"it’s" should be "it's".

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2 years agoGDB/testsuite: Add coverage for `print -elements' command
Maciej W. Rozycki [Thu, 7 Jul 2022 11:00:18 +0000 (12:00 +0100)]
GDB/testsuite: Add coverage for `print -elements' command

We currently have no coverage for the `print -elements ...' command (or
`p -elements ...' in the shortened form), so add a couple of test cases
mimicking ones using corresponding `set print elements ...' values.

2 years agogdb: LoongArch: Implement the push_dummy_call gdbarch method
Tiezhu Yang [Thu, 7 Jul 2022 06:33:19 +0000 (14:33 +0800)]
gdb: LoongArch: Implement the push_dummy_call gdbarch method

According to "Procedure Calling Convention" in "LoongArch ELF ABI
specification" [1], implement the push_dummy_call gdbarch method
as clear as possible.

[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_procedure_calling_convention

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2 years agoRISC-V: Added Zfhmin and Zhinxmin.
Tsukasa OI [Mon, 27 Jun 2022 02:03:43 +0000 (11:03 +0900)]
RISC-V: Added Zfhmin and Zhinxmin.

This commit adds Zfhmin and Zhinxmin extensions (subsets of Zfh and
Zhinx extensions, respectively).  In the process supporting Zfhmin and
Zhinxmin extension, this commit also changes how instructions are
categorized considering Zfhmin, Zhinx and Zhinxmin extensions.

Detailed changes,

* From INSN_CLASS_ZFH to INSN_CLASS_ZFHMIN:

flh, fsh, fmv.x.h and fmv.h.x.

* From INSN_CLASS_ZFH to INSN_CLASS_ZFH_OR_ZHINX:

fmv.h.

* From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFH_OR_ZHINX:

fneg.h, fabs.h, fsgnj.h, fsgnjn.h, fsgnjx.h,
fadd.h, fsub.h, fmul.h, fdiv.h, fsqrt.h, fmin.h, fmax.h,
fmadd.h, fnmadd.h, fmsub.h, fnmsub.h,
fcvt.w.h, fcvt.wu.h, fcvt.h.w, fcvt.h.wu,
fcvt.l.h, fcvt.lu.h, fcvt.h.l, fcvt.h.lu,
feq.h, flt.h, fle.h, fgt.h, fge.h,
fclass.h.

* From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFHMIN_OR_ZHINXMIN:

fcvt.s.h and fcvt.h.s.

* From INSN_CLASS_D_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_D:

fcvt.d.h and fcvt.h.d.

* From INSN_CLASS_Q_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_Q:

fcvt.q.h and fcvt.h.q.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Change implicit
subsets.  Zfh->Zicsr is not needed and Zfh->F is replaced with
Zfh->Zfhmin and Zfhmin->F.  Zhinx->Zicsr is not needed and
Zhinx->Zfinx is replaced with Zhinx->Zhinxmin and
Zhinxmin->Zfinx.
(riscv_supported_std_z_ext): Added zfhmin and zhinxmin.
(riscv_multi_subset_supports):  Rewrite handling for new
instruction classes.
(riscv_multi_subset_supports_ext): Updated.
(riscv_parse_check_conflicts): Change error message to include
zfh and zfhmin extensions.

gas/ChangeLog:

* testsuite/gas/riscv/zfhmin-d-insn-class-fail.s: New complex
error handling test.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.l: Likewise.
* testsuite/gas/riscv/zhinx.d: Renamed from fp-zhinx-insns.d
and refactored.
* testsuite/gas/riscv/zhinx.s: Likewise.

include/ChangeLog:

* opcode/riscv.h (enum riscv_insn_class): Removed INSN_CLASS_ZFH,
INSN_CLASS_D_AND_ZFH_INX and INSN_CLASS_Q_AND_ZFH_INX.  Added
INSN_CLASS_ZFHMIN, INSN_CLASS_ZFHMIN_OR_ZHINXMIN,
INSN_CLASS_ZFHMIN_AND_D and INSN_CLASS_ZFHMIN_AND_Q.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Change instruction classes for
Zfh and Zfhmin instructions.  Fix `fcvt.h.lu' instruction
(two operand variant) mask.

2 years agogprofng: adjust GPROFNG_VARIANT
Vladimir Mezentsev [Wed, 6 Jul 2022 20:52:57 +0000 (13:52 -0700)]
gprofng: adjust GPROFNG_VARIANT

GPROFNG_VARIANT depends on compiler options, not on $(host).

gprofng/ChangeLog
2022-07-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29116
* libcollector/configure.ac: Adjust GPROFNG_VARIANT.
* libcollector/configure: Rebuild.

2 years agoRISC-V: Fix disassembling Zfinx with -M numeric
Tsukasa OI [Mon, 27 Jun 2022 02:03:44 +0000 (11:03 +0900)]
RISC-V: Fix disassembling Zfinx with -M numeric

This commit fixes floating point operand register names from ABI ones
to dynamically set ones.

gas/ChangeLog:

* testsuite/gas/riscv/zfinx-dis-numeric.s: Test new behavior of
Zfinx extension and -M numeric disassembler option.
* testsuite/gas/riscv/zfinx-dis-numeric.d: Likewise.

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_insn): Use dynamically set GPR
names to disassemble Zfinx instructions.

2 years agoRISC-V: Fix requirement handling on Zhinx+{D,Q}
Tsukasa OI [Fri, 24 Jun 2022 02:59:04 +0000 (11:59 +0900)]
RISC-V: Fix requirement handling on Zhinx+{D,Q}

This commit fixes how instructions are masked on Zhinx+Z{d,q}inx.
fcvt.h.d and fcvt.d.h require ((D&&Zfh)||(Zdinx&&Zhinx)) and
fcvt.h.q and fcvt.q.h require ((Q&&Zfh)||(Zqinx&&Zhinx)).

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Fix feature gate
on INSN_CLASS_{D,Q}_AND_ZFH_INX.
(riscv_multi_subset_supports_ext): Fix feature gate diagnostics
on INSN_CLASS_{D,Q}_AND_ZFH_INX.

gas/ChangeLog:

* testsuite/gas/riscv/fp-zhinx-insns.d: Add Zqinx to -march
for proper testing.

2 years agoPR29320, 'struct obstack' declared inside parameter list
Alan Modra [Tue, 5 Jul 2022 23:50:09 +0000 (09:20 +0930)]
PR29320, 'struct obstack' declared inside parameter list

PR 29320
* frags.h: Move declaration of struct obstack..
* as.h: ..to here.

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 7 Jul 2022 00:00:21 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agogprofng: implement a functional gp-display-html
Ruud van der Pas [Tue, 28 Jun 2022 17:37:19 +0000 (10:37 -0700)]
gprofng: implement a functional gp-display-html

This patch enables the first support for the "gprofng display html" command.
This command works for C/C++ applications on x86_64. Using one or more gprofng
experiment directories as input, a new directory with html files is created.
Through the index.html file in this directory, the performance results may be
viewed in a browser.

gprofng/Changelog:
2022-06-28  Ruud van der Pas  <ruud.vanderpas@oracle.com>

* gp-display-html/gp-display-html.in: implement first support for x86_64 and C/C++

2 years agoelf: Copy p_align of PT_GNU_STACK for stack alignment
H.J. Lu [Tue, 5 Jul 2022 19:45:23 +0000 (12:45 -0700)]
elf: Copy p_align of PT_GNU_STACK for stack alignment

commit 74e315dbfe5200c473b226e937935fb8ce391489
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Dec 13 19:46:04 2021 -0800

    elf: Set p_align to the minimum page size if possible

may ignore p_align of PT_GNU_STACK when copying ELF program header if
the maximum page size is larger than p_align of PT_LOAD segments.  Copy
p_align of PT_GNU_STACK since p_align of PT_GNU_STACK describes stack
alignment, not page size,

PR binutils/29319
* elf.c (copy_elf_program_header): Copy p_align of PT_GNU_STACK
for stack alignment.

2 years agox86: make D attribute usable for XOP and FMA4 insns
Jan Beulich [Wed, 6 Jul 2022 13:40:04 +0000 (15:40 +0200)]
x86: make D attribute usable for XOP and FMA4 insns

This once again allows to reduce redundancy in (and size of) the opcode
table.

Don't go as far as also making D work on the two 5-operand XOP insns:
This would significantly complicate the code, as there the first
(immediate) operand would need special treatment in several places.

Note that the .s suffix isn't being enabled to have any effect, for
being deprecated. Whereas neither {load} nor {store} pseudo prefixes
make sense here, as the respective operands are inputs (loads) only
anyway, regardless of order. Hence there is (as before) no way for the
programmer to request the alternative encoding to be used for register-
only insns.

Note further that it is always the first original template which is
retained (and altered), to make sure the same encoding as before is
used for register-only insns. This has the slightly odd (but pre-
existing) effect of XOP register-only insns having XOP.W clear, but FMA4
ones having VEX.W set.

2 years agox86: fold two switch() statements in match_template()
Jan Beulich [Wed, 6 Jul 2022 13:39:37 +0000 (15:39 +0200)]
x86: fold two switch() statements in match_template()

I don't see why two of them were introduced (very long ago) using
similar fall-through logic.

2 years agox86: fix 3-operand insn reverse-matching
Jan Beulich [Wed, 6 Jul 2022 13:39:03 +0000 (15:39 +0200)]
x86: fix 3-operand insn reverse-matching

The middle operand would have gone entirely unchecked, allowing e.g.

vmovss %xmm0, %esp, %xmm2

to assemble successfully, or e.g.

vmovss %xmm0, $4, %xmm2

causing an internal error. Alongside dealing with this also drop a
related comment, which hasn't been applicable anymore since the
introduction of 3-operand patterns with D set (and which perhaps never
had been logical to be there, as reverse-matched insns don't make it
there in the first place).

2 years agoDescriptive DWARF operations dump support for DW_AT_rank
Bhuvanendra Kumar N [Wed, 6 Jul 2022 10:56:25 +0000 (16:26 +0530)]
Descriptive DWARF operations dump support for DW_AT_rank

DW_AT_rank is a dwarf-5 feature.

2 years agox86: introduce a state stack for .arch
Jan Beulich [Wed, 6 Jul 2022 07:22:47 +0000 (09:22 +0200)]
x86: introduce a state stack for .arch

When using just slightly non-trivial combinations of .arch, it can be
quite useful to be able to go back to prior state without needing to
re-invoke perhaps many earlier directives and without needing to invoke
perhaps many "negative" ones. Like some other architectures allow
saving (pushing) and restoring (popping) present/prior state.

For now require the same .code<N> to be in effect for ".arch pop" that
was in effect for the corresponding ".arch push".

Also change the global "no_cond_jump_promotion" to be bool, to match the
new struct field.

2 years agox86: generalize disabling of sub-architectures
Jan Beulich [Wed, 6 Jul 2022 07:22:11 +0000 (09:22 +0200)]
x86: generalize disabling of sub-architectures

I never really understood upon what basis ".arch .no*" options were made
available. Let's not have any "criteria" at all, and simply allow
disabling of all of them. Then we also have all data for a sub-arch in
a single place, as we now only need a single table.

2 years agox86: permit "default" with .arch
Jan Beulich [Wed, 6 Jul 2022 07:21:40 +0000 (09:21 +0200)]
x86: permit "default" with .arch

So far there was no way to reset the architecture to that assembly would
start with in the absence of any overrides (command line or directives).
Note that for Intel MCU "default" is merely an alias of "iamcu".

While there also zap a stray @item from the doc section, as noticed
when inspecting the generated output (which still has some quirks, but
those aren't easy to address without re-flowing almost the entire
section).

2 years agox86: don't leak sub-architecture accumulated strings
Jan Beulich [Wed, 6 Jul 2022 07:20:29 +0000 (09:20 +0200)]
x86: don't leak sub-architecture accumulated strings

While it may not be necessary in i386_target_format() (but then setting
the variable to NULL also wouldn't be necessary), at least in the other
cases strings may already have accumulated.

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 6 Jul 2022 00:00:17 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years ago[gdb/exp] Fix internal error when printing C++ pointer-to-member
Tom de Vries [Tue, 5 Jul 2022 20:41:25 +0000 (22:41 +0200)]
[gdb/exp] Fix internal error when printing C++ pointer-to-member

When running the test-case included with this patch, we run into:
...
(gdb) print ptm^M
$1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \
  Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M
...
while printing a c++ pointer-to-member.

Fix this by skipping static fields in cp_find_class_member, such that we have:
...
(gdb) print ptm^M
$1 = &A::i^M
...

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29294

2 years agoAdd gdb.Objfile.is_file attribute
Tom Tromey [Mon, 20 Jun 2022 18:32:52 +0000 (12:32 -0600)]
Add gdb.Objfile.is_file attribute

Sometimes an objfile comes from memory and not from a file.  It can be
useful to be able to check this from Python, so this patch adds a new
"is_file" attribute.

2 years agoMake 'import gdb.events' work
Tom Tromey [Fri, 3 Jun 2022 13:59:49 +0000 (07:59 -0600)]
Make 'import gdb.events' work

Pierre-Marie noticed that, while gdb.events is a Python module, it
can't be imported.  This patch changes how this module is created, so
that it can be imported, while also ensuring that the module is always
visible, just as it was in the past.

This new approach required one non-obvious change -- when running
gdb.base/warning.exp, where --data-directory is intentionally not
found, the event registries can now be nullptr.  Consequently, this
patch probably also requires

    https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html

Note that this patch obsoletes

    https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html

2 years agogdb: LoongArch: add orig_a0 into register set
Xi Ruoyao [Tue, 5 Jul 2022 11:30:12 +0000 (19:30 +0800)]
gdb: LoongArch: add orig_a0 into register set

The basic support for LoongArch has been merged into the upstream Linux
kernel since 5.19-rc1 on June 5, 2022.  This commit adds orig_a0 which
is added into struct user_pt_regs [1] to match the upstream kernel, and
then the upstream GDB will work with the upstream kernel.

Note that orig_a0 was added into struct user_pt_regs in the development
cycle for merging LoongArch port into the upstream Linux kernel, so
earlier kernels (notably, the product kernel with version 4.19 used in
distros like UOS and Loongnix) don't have it.  Inspect
arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure.
To build upstream GDB for a kernel lacking orig_a0, it's necessary to
revert this commit locally.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24

Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2 years agoSupport for location and range lists for split-dwarf and dwarf-5.
Bhuvanendra Kumar N [Tue, 5 Jul 2022 11:23:45 +0000 (16:53 +0530)]
Support for location and range lists for split-dwarf and dwarf-5.

Adding support for location and range lists for split-dwarf and dwarf-5.
Following issues are taken care.
1. Display of the index values for DW_FORM_loclistx and DW_FORM_rnglistx.
2. Display of .debug_loclists.dwo and .debug_rnglists.dwo sections.

        * dwarf.c(read_and_display_attr_value): Handle DW_FORM_loclistx
        and DW_FORM_rnglistx for .dwo files.
        (process_debug_info): Load .debug_loclists.dwo and
        .debug_rnglists.dwo if exists.
        (load_separate_debug_files): Load .debug_loclists and
        .debug_rnglists if exists.
        Include 2 entries in debug_displays table.
        * dwarf.h (enum dwarf_section_display_enum): Include 2 entries.

2 years agox86: introduce fake processor type to mark sub-arch entries in cpu_arch[]
Jan Beulich [Tue, 5 Jul 2022 06:40:39 +0000 (08:40 +0200)]
x86: introduce fake processor type to mark sub-arch entries in cpu_arch[]

This is in preparation of dropping the leading . from the strings.

While there also move PROCESSOR_GENERIC{32,64} from the middle of AMD
entries to near the top.

2 years agox86: macro-ize cpu_arch[] entries
Jan Beulich [Tue, 5 Jul 2022 06:40:09 +0000 (08:40 +0200)]
x86: macro-ize cpu_arch[] entries

Putting individual elements behind macros, besides (imo) improving
readability, will make subsequent (and likely also future) changes less
intrusive.

Utilize this right away to pack the table a little more tightly, by
converting "skip" to bool and putting it earlier in a group of bitfields
together with "len".

2 years agox86: de-duplicate sub-architecture strings accumulation
Jan Beulich [Tue, 5 Jul 2022 06:39:43 +0000 (08:39 +0200)]
x86: de-duplicate sub-architecture strings accumulation

Introduce a helper function to replace 4 instances of similar code. Use
reconcat() to cover the previously explicit free().

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 5 Jul 2022 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agoFix snafu in rust demangler recursion limit code
Nick Clifton [Mon, 4 Jul 2022 15:28:02 +0000 (16:28 +0100)]
Fix snafu in rust demangler recursion limit code

2 years agoalloc gas seginfo on notes obstack
Alan Modra [Mon, 4 Jul 2022 03:15:47 +0000 (12:45 +0930)]
alloc gas seginfo on notes obstack

Lots of memory used in gas should go on this obstack.  The patch also
frees all the gas obstacks on exit, which isn't a completely trivial
task.

* subsegs.c (alloc_seginfo): New function.
(subseg_change, subseg_get): Use it.
(subsegs_end): New function.
* as.h (subsegs_end): Declare.
* output-file.c: Include subsegs.h
(stash_frchain_obs): New function.
(output_file_close): Save obstacks attached to output bfd before
closing.  Call subsegs_end with the array of obstacks.

2 years agoobjcopy: bfd_alloc orelocation
Alan Modra [Mon, 4 Jul 2022 01:54:22 +0000 (11:24 +0930)]
objcopy: bfd_alloc orelocation

This fixes an inconsequential objcopy memory leak.  I'd normally
ignore reports of leaks like this one, that are merely one block or
fewer per section processed, since objcopy soon exits and frees all
memory.  However I thought it worth providing support for allocating
memory on a bfd objalloc in objcopy and other utils.

PR 29233
* bucomm.c (bfd_xalloc): New function.
* bucomm.h (bfd_xalloc): Declare.
* objcopy.c (copy_relocations_in_section): Use it to allocate
array of reloc pointers.  Rewrite code stripping relocs to do
without extra memory allocation.

2 years agoSynchronize libbierty sources with gcc.
Nick Clifton [Mon, 4 Jul 2022 12:57:12 +0000 (13:57 +0100)]
Synchronize libbierty sources with gcc.

2 years agoModified changes for split-dwarf and dwarf-5.
Bhuvanendra Kumar N [Mon, 4 Jul 2022 10:50:29 +0000 (16:20 +0530)]
Modified changes for split-dwarf and dwarf-5.

        * dwarf.c(process_debug_info): Include DW_TAG_skeleton_unit.
        (display_debug_str_offsets): While dumping .debug_str_offsets.dwo,
        pass proper str_offsets_base to fetch_indexed_string().
        (load_separate_debug_files): Skip DWO ID dump for dwarf-5.

2 years agoopcodes/avr: Implement style support in the disassembler
Marcus Nilsson [Mon, 4 Jul 2022 10:25:42 +0000 (11:25 +0100)]
opcodes/avr: Implement style support in the disassembler

* disassemble.c: (disassemble_init_for_target): Set
created_styled_output for AVR based targets.
* avr-dis.c: (print_insn_avr): Use fprintf_styled_ftype
instead of fprintf_ftype throughout.
(avr_operand): Pass in and fill disassembler_style when
parsing operands.

2 years ago[gdb/symtab] Add get/set functions for per_cu->lang/unit_type
Tom de Vries [Mon, 4 Jul 2022 08:28:42 +0000 (10:28 +0200)]
[gdb/symtab] Add get/set functions for per_cu->lang/unit_type

The dwarf2_per_cu_data fields lang and unit_type both have a dont-know
initial value (respectively language_unknown and (dwarf_unit_type)0), which
allows us to add certain checks, f.i. checking that that a field is not read
before written.

Add get/set member functions for the two fields as a convenient location to
add such checks, make the fields private to enforce using the member
functions, and add the m_ prefix.

Tested on x86_64-linux.

2 years agogas/testsuite: properly exclude aout in all/weakref1u
Jan Beulich [Mon, 4 Jul 2022 06:42:10 +0000 (08:42 +0200)]
gas/testsuite: properly exclude aout in all/weakref1u

Use the (wider) predicate rather than a triplet. This eliminates the sole
i386-msdos failure in the testsuite.

2 years agox86: fold Disp32S and Disp32
Jan Beulich [Mon, 4 Jul 2022 06:32:50 +0000 (08:32 +0200)]
x86: fold Disp32S and Disp32

The only case where 64-bit code uses non-sign-extended (can also be
considered zero-extended) displacements is when an address size override
is in place for a memory operand (i.e. particularly excluding
displacements of direct branches, which - if at all - are controlled by
operand size, and then are still sign-extended, just from 16 bits).
Hence the distinction in templates is unnecessary, allowing code to be
simplified in a number of places. The only place where logic becomes
more complicated is when signed-ness of relocations is determined in
output_disp().

The other caveat is that Disp64 cannot be specified anymore in an insn
template at the same time as Disp32. Unlike for non-64-bit mode,
templates don't specify displacements for both possible addressing
modes; the necessary adjustment to the expected ones has already been
done in match_template() anyway (but of course the logic there needs
tweaking now). Hence the single template so far doing so is split.

2 years agox86: restore masking of displacement kinds
Jan Beulich [Mon, 4 Jul 2022 06:32:20 +0000 (08:32 +0200)]
x86: restore masking of displacement kinds

Commit 7d5e4556a375 rendered the check near the end of what is now
i386_finalize_displacement() entirely dead for AT&T mode, since for
operands involving a displacement .unspecified will always be set. But
the logic there is bogus anyway - Intel syntax operand size specifiers
are of no interest there either. The only thing which matters in the
"displacement only" determination is .baseindex.

Of course when masking displacement kinds we should not at the same time
also mask off other attributes.

Furthermore the type mask returned by lex_got() also needs to be
adjusted: The only case where we want Disp32 (rather than Disp32S) is
when dealing with 32-bit addressing mode in 64-bit code.

2 years agox86-64: improve handling of branches to absolute addresses
Jan Beulich [Mon, 4 Jul 2022 06:31:21 +0000 (08:31 +0200)]
x86-64: improve handling of branches to absolute addresses

There are two related problems here: The use of "addr32" on a direct
branch would, besides causing a warning, result in operands to be
permitted which mistakenly are refused without "addr32". Plus at some
point not too long ago I'm afraid it may have been me who regressed the
relocation addends emitted for such branches. Correct both problems,
adding a testcase to guard against regressing this again.

2 years agoRISC-V: Update Zihintpause extension version
Tsukasa OI [Sun, 3 Jul 2022 10:31:23 +0000 (19:31 +0900)]
RISC-V: Update Zihintpause extension version

Because ratified Zihintpause extension has a version number of 2.0
(not 1.0), we should update the number.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_z_ext): Update version
number of Zihintpause extension.

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 4 Jul 2022 00:00:18 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 3 Jul 2022 00:00:16 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years ago[gdb/symtab] Fix data race on per_cu->dwarf_version
Tom de Vries [Sat, 2 Jul 2022 11:03:34 +0000 (13:03 +0200)]
[gdb/symtab] Fix data race on per_cu->dwarf_version

When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
thread in the same write:
...
Write of size 1 at 0x7b200000300c:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
    (gdb+0x82f3b3)^M
...
which is here:
...
         this_cu->dwarf_version = cu->header.version;
...

Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
this one directly:
...
    #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
    #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
...
and this via the PU import:
...
    #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
    sect_offset, bool,  bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
    #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
    abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
    #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
    cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
    #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
    (gdb+0x85e68a)^M
    #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
    #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
...

Fix this by setting the field earlier, in read_comp_units_from_section.

The write in cutu_reader::cutu_reader() is still needed, in case
read_comp_units_from_section is not used (run the test-case with say, target
board cc-with-gdb-index).

Make the write conditional, such that it doesn't trigger if the field is
already set by read_comp_units_from_section.  Instead, verify that the
field already has the value that we're trying to set it to.

Move this logic into into a member function set_version (in analogy to the
already present member function version) to make sure it's used consistenly,
and make the field private in order to enforce access through the member
functions, and rename it to m_dwarf_version.

While we're at it, make sure that the version is set before read, to avoid
say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".

Tested on x86_64-linux.

2 years ago[gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread
Tom de Vries [Sat, 2 Jul 2022 09:50:03 +0000 (11:50 +0200)]
[gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread

When building gdb with -fsanitize=thread, I run into:
...
FAIL: gdb.base/early-init-file.exp: check startup version string has style \
  version
...
due to this:
...
warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
warning: Found custom handler for signal 8 (Floating point exception) \
  preinstalled.^M
warning: Found custom handler for signal 11 (Segmentation fault) \
  preinstalled.^M
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
won't be propagated to spawned programs.^M
...
appearing before the "GNU gdb (GDB) $version" line.

This is similar to the problem fixed by commit f0bbba7886f
("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
AddressSanitizer").

In that commit, the problem was fixed by starting gdb with -quiet, but using
that would mean the "GNU gdb (GDB) $version" line that we're trying to check
would disappear.

Fix this instead by updating the regexp to allow the message.

Tested on x86_64-linux.

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 2 Jul 2022 00:00:15 +0000 (00:00 +0000)]
Automatic date update in version.in

2 years agoGDB/doc: Remove indentation from `print -elements' completion example
Maciej W. Rozycki [Fri, 1 Jul 2022 16:11:09 +0000 (17:11 +0100)]
GDB/doc: Remove indentation from `print -elements' completion example

Remove indentation from the text of the manual after the example here:

"  Completion will in some cases guide you with a suggestion of what
kind of argument an option expects.  For example:

     (gdb) print -elements <TAB><TAB>
     NUMBER     unlimited

   Here, the option expects a number (e.g., '100'), not literal
'NUMBER'.  Such metasyntactical arguments are always presented in
uppercase."

as this is a continuation of the same paragraph.

2 years agoGDB/doc: Remove extraneous spaces from completion examples
Maciej W. Rozycki [Fri, 1 Jul 2022 16:11:09 +0000 (17:11 +0100)]
GDB/doc: Remove extraneous spaces from completion examples

Completion results are usually different when the operation is applied
to a word that is or is not followed by a space.  In some cases they are
equivalent, however a space would not be produced if completion was used
earlier on in the word processed.

However in the manual we have completion examples given using a space
that actually prevents the example from working.  E.g.:

(gdb) info bre <TAB>

(nothing) and:

(gdb) info bre <TAB><TAB>
Display all 200 possibilities? (y or n)

as it now goes on to propose the entire symbol table, while:

(gdb) info bre<TAB>
(gdb) info breakpoints

does the right thing, but is not what is shown in the manual.

In other cases an extraneous space is used that does not correspond to
the actual completion pattern shown, which gives an impression of
sloppiness.

Remove extraneous spaces then from completion examples as appropriate.