Commit Graph

110837 Commits

Author SHA1 Message Date
Andrew Burgess
ab25d9bbe4 gdb: rename gdbarch_tdep struct to fix g++ 4.8 build
After the commit:

  commit 08106042d9
  Date:   Thu May 19 13:20:17 2022 +0100

      gdb: move the type cast into gdbarch_tdep

GDB would no longer build using g++ 4.8.  The issue appears to be some
confusion caused by GDB having 'struct gdbarch_tdep', but also a
templated function called 'gdbarch_tdep'.  Prior to the above commit
the gdbarch_tdep function was not templated, and this compiled just
fine.  Note that the above commit compiles just fine with later
versions of g++, so this issue was clearly fixed at some point, though
I've not tried to track down exactly when.

In this commit I propose to fix the g++ 4.8 build problem by renaming
'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'.  This rename
better represents that the struct is only ever used as a base class,
and removes the overloading of the name, which allows GDB to build
with g++ 4.8.

I've also updated the comment on 'struct gdbarch_tdep_base' to fix a
typo, and the comment on the 'gdbarch_tdep' function, to mention that
in maintainer mode a run-time type check is performed.
2022-07-26 12:04:07 +01:00
Nick Clifton
27121f6740 Fix indentation in loongarch code, preventing a compile time warning. 2022-07-26 11:33:51 +01:00
Lancelot SIX
6c96b937df gdb/varobj: Fix varobj_invalidate_iter
The varobj_invalidate function is meant to be called when restarting a
process, and check at this point if some of the previously existing
varobj can be recreated in the context of the new process.

Two kind of varobj are subject to re-creation:  global varobj (i.e.
varobj which reference a global variable), and floating varobj (i.e.
varobj which are always re-evaluated in the context of whatever is
the currently selected frame at the time of evaluation).

However, in the re-creation process, the varobj_invalidate_iter
recreates floating varobj as non-floating, due to an invalid parameter.
This patches fixes this and adds an assertion to check that if a varobj
is indeed recreated, it matches the original varobj "floating" property.

Another issue is that if at this recreation time the expression watched
by the floating varobj is not in scope, then the varobj is marked as
invalid.  If later the user selects a frame where the expression becomes
valid, the varobj remains invalid and this is wrong.  This patch also
make sure that floating varobj are not invalidated if they cannot be
evaluated.

The last important thing to note is that due to the previous patch, when
varobj_invalidate is executed (in the context of a new process), any
global var have already been invalidated (this has been done when the
objfile it referred to got invalidated).  As a consequence,
varobj_invalidate tries to recreate vars which are already marked as
invalid.  This does not entirely feels right, but I keep this behavior
for backward compatibility.

Tested on x86_64-linux
2022-07-26 08:27:27 +01:00
Lancelot SIX
bc20e562ec gdb/varobj: Fix use after free in varobj
Varobj object contains references to types, variables (i.e. struct
variable) and expression.  All of those can reference data on an
objfile's obstack.  It is possible for this objfile to be deleted (and
the obstack to be feed), while the varobj remains valid.  Later, if the
user uses the varobj, this will result in a use-after-free error.  With
address sanitizer build, this leads to a plain error.  For non address
sanitizer build we might see undefined behaviour, which manifest
themself as assertion failures when accessing data backed by feed
memory.

This can be observed if we create a varobj that refers to ta symbol in a
shared library, after either the objfile gets reloaded (using the `file`
command) or after the shared library is unloaded (with a call to dlclose
for example).

This patch fixes those issues by:

- Adding cleanup procedure to the free_objfile observable.  When
  activated this observer clears expressions referencing the objfile
  being freed, and removes references to blocks belonging to this
  objfile.
- Adding varobj support in the `preserve_values` (gdb.value.c).  This
  ensures that before the objfile is unloaded, any type owned by the
  objfile referenced by the varobj is replaced by an equivalent type
  not owned by the objfile.  This process is done here instead of in the
  free_objfile observer in order to reuse the type hash table already
  used for similar purpose when replacing types of values kept in the
  value history.

This patch also makes sure to keep a reference to the expression's
gdbarch and language_defn members when the varobj->root->exp is
initialized.  Those structures outlive the objfile, so this is safe.
This is done because those references might be used initialize a python
context even after exp is invalidated.  Another approach could have been
to initialize the python context with default gdbarch and language_defn
(i.e. nullptr) if expr is NULL, but since we might still try to display
the value which was obtained by evaluating exp when it was still valid,
keeping track of the context which was used at this time seems
reasonable.

Tested on x86_64-Linux.

Co-Authored-By: Pedro Alves <pedro@palves.net>
2022-07-26 08:27:27 +01:00
Pedro Alves
60cd08d403 MI: mi_runto -pending
With the CLI testsuite's runto proc, we can pass "allow-pending" as an
option, like:

  runto func allow-pending

That is currently not possible with MI's mi_runto, however.  This
patch makes it possible, by adding a new "-pending" option to
mi_runto.

A pending breakpoint shows different MI attributes compared to a
breakpoint with a location, so the regexp returned by
mi_make_breakpoint isn't suitable.  Thus, add a new
mi_make_breakpoint_pending proc for pending breakpoints.

Tweak mi_runto to let it take and pass down arguments.

Change-Id: I185fef00ab545a1df2ce12b4dbc3da908783a37c
2022-07-26 08:22:10 +01:00
GDB Administrator
8e883b5e11 Automatic date update in version.in 2022-07-26 00:00:07 +00:00
Ruud van der Pas
91a5dd8e4a gprofng: fix bug 29356 - Execution fails if gprofng is not included in PATH
gprofng/Changelog:
2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	PR gprofng/29356
	* gp-display-html/gp-display-html.in: fixed a problem to execute
	gp-display-text in case gprofng is not included in the search
	path.
2022-07-25 15:05:50 -07:00
Ruud van der Pas
c69c2b6033 gprofng: fix bug 29392 - Unexpected line format in summary file
gprofng/Changelog:
2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	PR gprofng/29392
	* gp-display-html/gp-display-html.in: modified a regex, plus the
	code to handle the results; renamed a variable to improve the
	consistency in naming.
2022-07-25 15:05:50 -07:00
Ruud van der Pas
408520bcaa gprofng: fix bug 29353 - Fix a lay-out issue in the html disassembly files
gprofng/Changelog:
2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	PR gprofng/29353
	* gp-display-html/gp-display-html.in: fixed a problem in the
	generation of html for the disassembly where instructions
	without arguments were not handled correctly.
2022-07-25 15:05:50 -07:00
Ruud van der Pas
2e2a82421a gprofng: fix bug 29352 - Fix the message Hexadecimal number > 0xffffffff non-portable
gprofng/Changelog:
2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	PR gprofng/29352
	* gp-display-html/gp-display-html.in: the hex subroutine from
	the bigint module is now used.
2022-07-25 15:05:49 -07:00
Ruud van der Pas
872ae1027e gprofng: fix bug 29351 - Move dynamic loading of modules to a later stage
gprofng/Changelog:
2022-07-22  Ruud van der Pas  <ruud.vanderpas@oracle.com>

	PR gprofng/29351
	* gp-display-html/gp-display-html.in: the dynamic loading of
	modules occurred too early, resulting in the generation of the
	man page to fail in case a module is missing; the loading part is
	now done somewhat later in the execution to avoid this problem.
2022-07-25 15:05:49 -07:00
Kevin Buettner
24d2cbc42c set/show python dont-write-bytecode fixes
GDB uses the environment variable PYTHONDONTWRITEBYTECODE to
determine whether or not to write the result of byte-compiling
python modules when the "python dont-write-bytecode" setting
is "auto".  Simon noticed that GDB's implementation doesn't
follow the Python documentation.

At present, GDB only checks for the existence of this environment
variable.  That is not sufficient though.  Regarding
PYTHONDONTWRITEBYTECODE, this document...

    https://docs.python.org/3/using/cmdline.html

...says:

    If this is set to a non-empty string, Python won't try to write
    .pyc files on the import of source modules.

This commit fixes GDB's handling of PYTHONDONTWRITEBYTECODE by adding
an empty string check.

This commit also corrects the set/show command documentation for
"python dont-write-bytecode".  The current doc was just a copy
of that for set/show python ignore-environment.

During his review of an earlier version of this patch, Eli Zaretskii
asked that the help text that I proposed for "set/show python
dont-write-bytecode" be expanded.  I've done that in addition to
clarifying the documentation of this option in the GDB manual.
2022-07-25 12:05:14 -07:00
Andrew Burgess
23aa2befce gdb/python: fix invalid use disassemble_info::stream
After this commit:

  commit 81384924cd
  Date:   Tue Apr 5 11:06:16 2022 +0100

      gdb: have gdb_disassemble_info carry 'this' in its stream pointer

The disassemble_info::stream field will no longer be a ui_file*.  That
commit failed to update one location in py-disasm.c though.

While running some tests using the Python disassembler API, I
triggered a call to gdbpy_disassembler::print_address_func, and, as I
had compiled GDB with the undefined behaviour sanitizer, GDB crashed
as the code currently (incorrectly) casts the stream field to be a
ui_file*.

In this commit I fix this error.

In order to test this case I had to tweak the existing test case a
little.  I also spotted some debug printf statements in py-disasm.py,
which I have removed.
2022-07-25 19:26:24 +01:00
Andrew Burgess
554128418b gdb: fix use of uninitialised gdb_printing_disassembler::m_in_comment
Simon pointed out that gdb_printing_disassembler::m_in_comment can be
used uninitialised by the Python disassembler API code.  This issue
was spotted when GDB was built with the undefined behaviour sanitizer,
and causes the gdb.python/py-disasm.exp test to fail like this:

  (gdb) PASS: gdb.python/py-disasm.exp: global_disassembler=GlobalPreInfoDisassembler: python add_global_disassembler(GlobalPreInfoDisassembler)
  disassemble main
  Dump of assembler code for function main:
     0x0000555555555119 <+0>:     push   %rbp
     0x000055555555511a <+1>:     mov    %rsp,%rbp
     0x000055555555511d <+4>:     nop
  /home/user/src/binutils-gdb/gdb/disasm.h:144:12: runtime error: load of value 118, which is not a valid value for type 'bool'

The problem is that in disasmpy_builtin_disassemble we create a new
instance of gdbpy_disassembler, which is a sub-class of
gdb_printing_disassembler, however, the m_in_comment field is never
initialised.

This commit fixes the issue by providing a default initialisation
value for m_in_comment in disasm.h.  As we only ever disassemble a
single instruction in disasmpy_builtin_disassemble then we don't need
to worry about reseting m_in_comment back to false after the single
instruction has been disassembled.

With this commit the above issue is resolved and
gdb.python/py-disasm.exp now passes.
2022-07-25 19:26:24 +01:00
H.J. Lu
e4146092c3 ld: Compile 2 CTF tests with -O2
When GCC 12 is used to build binutils with -O0, the following 2 tests
failed:

FAIL: Conflicted data syms, partially indexed, stripped, with variables
FAIL: Conflicted data syms, partially indexed, stripped

Compile 2 tests with -O2 to avoid test failures.

	PR ld/29378
	* testsuite/ld-ctf/data-func-conflicted-vars.d: Compile with -O2.
	* testsuite/ld-ctf/data-func-conflicted.d: Likewise.
2022-07-25 09:59:47 -07:00
Pedro Alves
b669667d07 struct packed: Add fallback byte array implementation
Attribute gcc_struct is not implemented in Clang targeting Windows, so
add a fallback standard-conforming implementation based on arrays.

I ran the testsuite on x86_64 GNU/Linux with this implementation
forced, and saw no regressions.

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

Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
2022-07-25 16:04:05 +01:00
Pedro Alves
e249e6b801 struct packed: Unit tests and more operators
For PR gdb/29373, I wrote an alternative implementation of struct
packed that uses a gdb_byte array for internal representation, needed
for mingw+clang.  While adding that, I wrote some unit tests to make
sure both implementations behave the same.  While at it, I implemented
all relational operators.  This commit adds said unit tests and
relational operators.  The alternative gdb_byte array implementation
will come next.

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

Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
2022-07-25 16:04:05 +01:00
Pedro Alves
4ca26ad7de struct packed: Use gcc_struct on Windows
Building GDB on mingw/gcc hosts is currently broken, due to a static
assertion failure in gdbsupport/packed.h:

  In file included from ../../../../../binutils-gdb/gdb/../gdbsupport/common-defs.h:201,
		   from ../../../../../binutils-gdb/gdb/defs.h:28,
		   from ../../../../../binutils-gdb/gdb/dwarf2/read.c:31:
  ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h: In instantiation of 'packed<T, Bytes>::packed(T) [with T = dwarf_unit_type; long long unsigned int Bytes = 1]':
  ../../../../../binutils-gdb/gdb/dwarf2/read.h:181:74:   required from here
  ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: error: static assertion failed
     41 |     gdb_static_assert (sizeof (packed) == Bytes);
	|                        ~~~~~~~~~~~~~~~~^~~~~~~~
  ../../../../../binutils-gdb/gdb/../gdbsupport/gdb_assert.h:27:48: note: in definition of macro 'gdb_static_assert'
     27 | #define gdb_static_assert(expr) static_assert (expr, "")
	|                                                ^~~~
  ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: note: the comparison reduces to '(4 == 1)'
     41 |     gdb_static_assert (sizeof (packed) == Bytes);
	|                        ~~~~~~~~~~~~~~~~^~~~~~~~


The issue is that mingw gcc defaults to "-mms-bitfields", which
affects how bitfields are laid out.  We can however tell GCC that we
want the regular GCC layout instead using attribute gcc_struct.

Attribute gcc_struct is not implemented in "clang -target
x86_64-pc-windows-gnu", so that will need a different fix.

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

Change-Id: I023315ee03622c59c397bf4affc0b68179c32374
2022-07-25 16:04:05 +01:00
Andrew Burgess
f7f904e4fd binutils-gdb/git: highlight whitespace errors in source files
For a long time I've had this in my ~/.gitconfig:

  [core]
          whitespace = space-before-tab,indent-with-non-tab,trailing-space

which causes git to show me if I muck up and use spaces instead of
tabs, or leave in trailing whitespace.  I find this really useful.

I recently proposed adding something like this to the .gitattributes
files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1],
however, the question was asked - couldn't this be done at the top
level?

So, in this commit, I propose to update the top-level .gitattributes
file, after this commit, any git diff on a C, C++, Expect, or TCL
source file, will highlight the following whitespace errors:

  (a) Use a space before a tab at the start of a line,

  (b) Use of spaces where a tab could be used at the start of a line,
  and

  (c) Any trailing whitespace.

Errors are only highlighted in the diff on new or modified lines, so
you don't get spammed for errors on context lines that you haven't
modified.

The only downside I see to adding this at the top level is if there
are any sub-directories that don't follow the tabs/spaces indentation
rules very well already, in those directories you'll end up hitting
issues any time you edit a line.  For GDB we're usually pretty good,
so having this highlighting isn't an issue.

[1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html
2022-07-25 14:35:41 +01:00
Yvan Roux
a6e4a48c02 gdb/arm: Sync sp with other *sp registers
For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns), without security
extensions and for other Cortex-M targets, there are 2 different
stack pointers (msp and psp).

With this patch, sp will always be in sync with one of the real stack
pointers on Arm targets that contain more than one stack pointer.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
2022-07-25 15:31:16 +02:00
Torbjörn SVENSSON
42e11f363c gdb/arm: Use if-else if instead of switch
As the register numbers for the alternative Arm SP registers are not
constant, it's not possible to use switch statement to define the
rules.  In order to not have a mix, replace the few existing
switch statements with regular if-else if statements
2022-07-25 15:31:16 +02:00
Tom Tromey
eea2d83593 Remove dead code from windows_nat_target::detach
windows_nat_target::detach has a variable 'detached' that is only set
after a call to 'error'.  However, this can't happen because 'error'
throws an exception.

This patch removes the dead code.
2022-07-25 07:29:58 -06:00
Andrew Burgess
90ed159321 gdb: handle dis_style_sub_mnemonic disassembler style
In commit:

  commit 4f46c0bc36
  Date:   Mon Jul 4 17:45:25 2022 +0100

      opcodes: add new sub-mnemonic disassembler style

I added a new disassembler style dis_style_sub_mnemonic, but forgot to
add GDB support for this style.  Fix this oversight in this commit.
2022-07-25 14:26:24 +01:00
Andrew Burgess
36d94bd42b libopcodes/ppc: add support for disassembler styling
This commit adds disassembler styling to the libopcodes ppc
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/ppc and manually checked that the
styling looked reasonable.

I think the only slightly weird case was how things like '4*cr1+eq'
are styled.  As best I can tell, this construct, used for example in
this instruction:

  crand   4*cr1+lt,4*cr1+gt,4*cr1+eq

is used to access a field of a control register.  I initially tried
styling this whole construct as a register[1], but during review it
was suggested that instead different parts of the text should have
different styles.  In this commit I propose styling '4*cr1+lt' like
this:

  4    - immediate,
  *    - text,
  cr1  - register
  +    - text
  lt   - sub-mnemonic

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

[1] https://sourceware.org/pipermail/binutils/2022-July/121771.html
2022-07-25 14:13:34 +01:00
Andrew Burgess
4f46c0bc36 opcodes: add new sub-mnemonic disassembler style
When adding libopcodes disassembler styling support for AArch64, it
feels like the results would be improved by having a new sub-mnemonic
style.  This will be used in cases like:

  add    w16, w7, w1, uxtb #2
                      ^^^^----- Here

And:

  cinc   w0, w1, ne
                 ^^----- Here

This commit just adds the new style, and prepares objdump to handle
the style.  A later commit will add AArch64 styling, and will actually
make use of the style.

As this style is currently unused, there should be no user visible
changes after this commit.
2022-07-25 14:02:30 +01:00
liuzhensong
2cb10f02b0 LoongArch: Add testcases for new relocate types.
gas/testsuite/gas/all/
    gas.exp
  gas/testsuite/gas/loongarch/
    jmp_op.d
    jmp_op.s
    macro_op.d
    macro_op.s
    macro_op_32.d
    macro_op_32.s
    macro_op_large_abs.d
    macro_op_large_abs.s
    macro_op_large_pc.d
    macro_op_large_pc.s
    reloc.d
    reloc.s

  ld/testsuite/ld-elf/
    pr26936.d
    shared.exp
  ld/testsuite/ld-loongarch-elf/
    attr-ifunc-4.c
    attr-ifunc-4.out
    disas-jirl.d
    ifunc.exp
    jmp_op.d
    jmp_op.s
    libnopic-global.s
    macro_op.d
    macro_op.s
    macro_op_32.d
    macro_op_32.s
    nopic-global-so.rd
    nopic-global-so.sd
    nopic-global.out
    nopic-global.s
    nopic-global.sd
    nopic-global.xd
    nopic-local.out
    nopic-local.rd
    nopic-local.s
    nopic-local.sd
    nopic-local.xd
    nopic-weak-global-so.rd
    nopic-weak-global-so.sd
    nopic-weak-global.out
    nopic-weak-global.s
    nopic-weak-global.sd
    nopic-weak-global.xd
    nopic-weak-local.out
    nopic-weak-local.rd
    nopic-weak-local.s
    nopic-weak-local.sd
    nopic-weak-local.xd
    pic.exp
    pic.ld
2022-07-25 09:59:08 +08:00
liuzhensong
9801120721 bfd: Delete R_LARCH_NONE from dyn info of LoongArch.
Some R_LARCH_64 in section .eh_frame will to generate
  R_LARCH_NONE, we change relocation to R_LARCH_32_PCREL
  from R_LARCH_64 in setction .eh_frame and not generate
  dynamic relocation for R_LARCH_32_PCREL.

  Add New relocate type R_LARCH_32_PCREL for .eh_frame.

  include/elf/
    loongarch.h

  bfd/
    bfd/bfd-in2.h
    libbfd.h
    reloc.c
    elfxx-loongarch.c
    elfnn-loongarch.c

  gas/config/
    tc-loongarch.c

  binutils/
    readelf.c

  ld/testsuite/ld-elf/
    eh5.d
2022-07-25 09:59:08 +08:00
liuzhensong
bc2a35c0b4 LoongArch: Move ifunc info to rela.dyn from rela.plt.
Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when
  loading lazy function (rela.plt section).

  In dynamic programes, move ifunc dynamic relocate info to section
  srelgot from srelplt.

  bfd/
    elfnn-loongarch.c
2022-07-25 09:59:08 +08:00
liuzhensong
f09482a874 LoongArch: gas: Add new reloc types.
Generate new relocate types while use new macro insns.

  gas/config/
    loongarch-lex.h
    loongarch-parse.y
    tc-loongarch.c
    tc-loongarch.h
2022-07-25 09:59:08 +08:00
liuzhensong
cbdbf44535 LoongArch:opcodes: Add new reloc types.
opcodes: Replace old insns with news and generate new relocate types
  while macro insns expanding.

  opcodes/
    loongarch-opc.c
2022-07-25 09:59:08 +08:00
liuzhensong
6d13722a97 bfd: Add supported for LoongArch new relocations.
Define new reloc types according to linker needs.

  include/elf/
    loongarch.h

  bfd/
    bfd-in2.h
    libbfd.h
    reloc.c
    elfnn-loongarch.c
    elfxx-loongarch.c
    elfxx-loongarch.h
2022-07-25 09:59:08 +08:00
Alan Modra
5d471bd907 Re: PowerPC64 .branch_lt address
On seeing PR29369 my suspicion was naturally on a recent powerpc64
change, commit 0ab80031430e.  Without a reproducer, I spent time
wondering what could have gone wrong, and while I doubt this patch
would have fixed the PR, there are some improvements that can be made
to cater for user silliness.

I also noticed that when -z relro -z now sections are created out of
order, with .got before .plt in the section headers but .got is laid
out at a higher address.  That's due to the address expression for
.branch_lt referencing SIZEOF(.got) and so calling init_os (which
creates a bfd section) for .got before the .plt section is created.
Fix that by ignoring SIZEOF in exp_init_os.  Unlike ADDR and LOADADDR
which need to reference section vma and lma respectively, SIZEOF can
and does cope with a missing bfd section by returning zero for its
size, which of course is correct.

	PR 29369
	* ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF.
	* emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise
	.branch_lt address to take into account possible user sections
	with alignment larger than 8 bytes.
2022-07-25 09:49:41 +09:30
GDB Administrator
5d8af25542 Automatic date update in version.in 2022-07-25 00:00:06 +00:00
Enze Li
ea892bdc4b gdb/testsuite: add a clear test to py-breakpoint.exp
This patch adds a test case to try to clear an internal python
breakpoint using the clear command.

This was suggested by Pedro during a code review of the following
commit.

  commit a5c69b1e49
  Date:   Sun Apr 17 15:09:46 2022 +0800

    gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)

Tested on x86_64 openSUSE Tumbleweed.
2022-07-24 12:01:45 +08:00
Enze Li
c444385fad gdb/testsuite: rename get_maint_bp_addr and move it to gdb-utils.exp
The get_maint_bp_addr procedure will be shared by other test suite, so
move it to gdb-utils.exp.

Following Andrew's suggestion, I renamed get_maint_bp_addr to
gdb_get_bp_addr, since it would have handled normal breakpoints in
addition to the internal ones.  Note that there is still room for
improvement in this procedure, which I indicated in comments nearby.
2022-07-24 12:01:45 +08:00
GDB Administrator
561e83f7c5 Automatic date update in version.in 2022-07-24 00:00:20 +00:00
GDB Administrator
4c70437ddc Automatic date update in version.in 2022-07-23 00:00:28 +00:00
Tom de Vries
263ad5cc81 [gdb/symtab] Fix duplicate CUs in all_comp_units
When running test-case gdb.cp/cpexprs-debug-types.exp with target board
cc-with-debug-names on a system with gcc 12.1.1 (defaulting to dwarf 5), I
run into:
...
(gdb) file cpexprs-debug-types^M
Reading symbols from cpexprs-debug-types...^M
warning: Section .debug_aranges in cpexprs-debug-types has duplicate \
  debug_info_offset 0x0, ignoring .debug_aranges.^M
gdb/dwarf2/read.h:309: internal-error: set_length: \
  Assertion `m_length == length' failed.^M
...

The exec contains a .debug_names section, which gdb rejects due to
.debug_names containing a list of TUs, while the exec doesn't contain a
.debug_types section (which is what you'd expect for dwarf 4).

Gdb then falls back onto the cooked index, which calls create_all_comp_units
to create all_comp_units.  However, the failed index reading left some
elements in all_comp_units, so we end up with duplicates in all_comp_units,
which causes the misleading complaint and the assert.

Fix this by:
- asserting at the start of create_all_comp_units that all_comp_units is empty,
  as we do in create_cus_from_index and create_cus_from_debug_names, and
- cleaning up all_comp_units when failing in dwarf2_read_debug_names.

Add a similar cleanup in dwarf2_read_gdb_index.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381
2022-07-22 23:50:48 +02:00
Simon Marchi
5ae3df226b gdb/testsuite: give binaries distinct names in Ada tests
Some Ada tests repeat their test sequence with different gnat-encodings,
typically "all" and "minimal".  However, they give the same name to both
binaries, meaning the second run overwrites the binary of the first run.
This makes it difficult and confusing when trying to reproduce problems
manually with the test artifacts.  Change those tests to use unique
names for each pass.

Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88
2022-07-22 15:42:20 -04:00
Tom Tromey
4a570176b4 Change target_ops::async to accept bool
This changes the parameter of target_ops::async from int to bool.
Regression tested on x86-64 Fedora 34.
2022-07-22 11:06:51 -06:00
Tom Tromey
36da255e7c Fix typo in windows-nat.c
I noticed a typo in a printf in windows-nat.c.  This fixes it.
2022-07-22 10:58:11 -06:00
Tom de Vries
9083a323bc [gdb] Add empty range unit test for gdb::parallel_for_each
Add a unit test that verifies that we can call gdb::parallel_for_each with an
empty range.

Tested on x86_64-linux.
2022-07-22 17:18:51 +02:00
Alan Modra
6577f365eb PR17122, OSX 10.9 build failure
sbrk hasn't been used in binutils/ or ld/ for quite some time (so the
PR was fixed a while ago).  Tidy up configury.

	PR 17122
binutils/
	* configure.ac: Don't check for sbrk.
	* sysdep.h (sbrk): Don't supply fallback declaration.
	* config.in: Regenerate.
	* configure: Regenerate.
ld/
	* configure.ac: Don't check for sbrk.
	* config.in: Regenerate.
	* configure: Regenerate.
2022-07-22 12:38:53 +09:30
Jiangshuai Li
4686f81068 gdb/csky modify registers list for general_reggroup
There are two modification points here:
1. For the debugging of csky architecture, after executing "info register",
   we hope to print out GPRs, PC and the registers related to exceptions.
2. With tdesc-xml, users can view the register groups described in XML.
2022-07-22 10:33:14 +08:00
Alan Modra
b5375c5da9 PR15951, binutils testsuite builds status wrapper unconditionally
PR 15951
	* testsuite/binutils-all/objcopy.exp: Build testglue.o when
	needs_status_wrapper.
2022-07-22 10:43:29 +09:30
GDB Administrator
13391ff8bc Automatic date update in version.in 2022-07-22 00:00:19 +00:00
Peter Bergner
c07ec968f7 Add ChangeLog entry from previous commit 2022-07-21 14:56:18 -05:00
Peter Bergner
0a24685343 PowerPC: Create new MMA instruction masks and use them
The MMA instructions use XX3_MASK|3<<21 as an instruction mask, but that
misses the RC bit/bit 31, so if we disassemble a .long that represents an
MMA instruction except that it also has bit 31 set, we will erroneously
disassemble it to that MMA instruction.  We create new masks defines that
contain bit 31 so that doesn't happen anymore.

opcodes/
	* ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines.
	(P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4,
	xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8,
	xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp,
	xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp,
	xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn,
	xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them.
2022-07-21 14:53:52 -05:00
H.J. Lu
8f29211c3f i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC
We can't use the PLT entry as the function address for PIC since the PIC
register may not be set up properly for indirect call.

bfd/

	PR ld/27998
	* elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF
	relocation against IFUNC symbol for PIC.

ld/

	PR ld/27998
	* testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar.
	* testsuite/ld-i386/pr27998b.d: Expect a linker error.
	* testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated.
	* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
	* testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT.
	* testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise.
2022-07-21 11:40:27 -07:00
Andrew Burgess
c44885db3b gdb: ensure the cast in gdbarch_tdep is valid
This commit makes use of gdb::checked_static_cast when casting the
generic gdbarch_tdep pointer to a specific sub-class type.  This means
that, when compiled in developer mode, GDB will validate that the cast
is correct.

In order to use gdb::checked_static_cast the types involved must have
RTTI, which is why the gdbarch_tdep base class now has a virtual
destructor.

Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer
to the wrong type, then there should be no changes after this commit.

If any bugs do exist, then GDB will now assert (in a developer build).
2022-07-21 15:19:43 +01:00