~ubuntu-support-team/binutils/+git/binutils-gdb:users/ahajkova/try-frob

Last commit made on 2023-01-23
Get this branch:
git clone -b users/ahajkova/try-frob https://git.launchpad.net/~ubuntu-support-team/binutils/+git/binutils-gdb

Branch merges

Branch information

Name:
users/ahajkova/try-frob
Repository:
lp:~ubuntu-support-team/binutils/+git/binutils-gdb

Recent commits

1a39c1a... by Mark J. Wielaard

gdb: Ignore some stringop-overflow and restrict warnings on sparc

For some reason g++ 11.2.1 on s390x produces a spurious warning for
stringop-overread and restruct in fsb-tdep.c for some memcpy calls.
Add new DIAGNOSTIC_IGNORE_STRINGOP_OVERFLOW and
DIAGNOSTIC_IGNORE_RESTRICT macro to suppress these warning.

include/ChangeLog:

 * diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERFLOW): New
 macro.
 (DIAGNOSTIC_IGNORE_RESTRICT): Likewise.

gdb/ChangeLog:

 * fsb-tdep.c (fbsd_make_note_desc): Use
 DIAGNOSTIC_IGNORE_STRINGOP_OVERFLOW and
 DIAGNOSTIC_IGNORE_RESTRICT on sparc.

eb015bf... by Tom de Vries <email address hidden>

[gdb/testsuite] Avoid using .eh_frame in gdb.base/unwind-on-each-insn.exp

One purpose of the gdb.base/unwind-on-each-insn.exp test-case is to test the
architecture-specific unwinders on foo, so unwind-on-each-insn-foo.c is
compiled with nodebug, to prevent the dwarf unwinders from taking effect.

For for instance gcc x86_64 though, -fasynchronous-unwind-tables is enabled by
default, generating an .eh_frame section contribution which might enable the
dwarf unwinders and bypass the architecture-specific unwinders.

Currently, that happens to be not the case due to the current implementation
of epilogue_unwind_valid, which assumes that in absence of debug info proving
that the compiler is gcc >= 4.5.0, the .eh_frame contribution is invalid.

That may change though, see PR30028, in which case
gdb.base/unwind-on-each-insn.exp stops being a regression test for commit
49d7cd733a7 ("Change calculation of frame_id by amd64 epilogue unwinder").

Fix this by making sure that we don't use .eh_frame info regardless of
epilogue_unwind_valid, simply by not generating it using
-fno-asynchronous-unwind-tables.

Tested on x86_64-linux, target boards unix/{-m64,-m32}, using compilers
gcc 7.5.0 and clang 13.0.1.

b960c86... by Nick Clifton <email address hidden>

Updated Swedish translation for the binutils sub-directory

36025e8... by Tom de Vries <email address hidden>

[gdb/testsuite] Simplify gdb.base/unwind-on-each-insn.exp

In test-case gdb.base/unwind-on-each-insn.exp, we try to determine the last
disassembled insn in function foo.

This in it self is fragile, as demonstrated by commit 91836f41e20 ("Powerpc
fix for gdb.base/unwind-on-each-insn.exp").

The use of the last disassembled insn in the test-case is to stop stepping in
foo once reaching it.

However, the intent is to stop stepping just before returning to main.

There is no guarantee that the last disassembled insn:
- is actually executed
- is executed just before returning to main
- is executed only once.

Fix this by simplying the test-case to continue stepping till stepping out of
foo.

Tested on x86_64-linux.

bc0c679... by Tom de Vries <email address hidden>

[gdb/testsuite] Fix untested in gdb.base/frame-view.exp

When running test-case gdb.base/frame-view.exp, I see:
...
gdb compile failed, ld: frame-view0.o: in function `main':
frame-view.c:73: undefined reference to `pthread_create'
ld: frame-view.c:76: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
UNTESTED: gdb.base/frame-view.exp: failed to prepare
...

Fix this by adding pthreads to the compilation flags.

Tested on x86_64-linux.

7e53876... by Vladislav Khmelevsky <email address hidden>

Fix objdump --reloc for specific symbol

If objdump is used with both --disassemble=symbol and --reloc options
skip relocations that have addresses before the symbol, so that they
are not displayed.

eb8f8bb... by GDB Administrator <email address hidden>

Automatic date update in version.in

2292e33... by Tom Tromey <email address hidden>

Remove path name from test

The test suite reports several path names in tests. I couldn't find
most of these, and I suspect they are false reports, but I did manage
to locate one. This one is probably harmless, as I think the path
does not vary; but it's also easy to fix and suppress one warning.

39ac2b0... by Tom Tromey <email address hidden>

Minor cleanup in gdb.btrace/enable.exp

I noticed a weird-looking bit of code in gdb.btrace/enable.exp that is
left over from an earlier change. This patch moves the "!" inside the
braces, where it belongs.

c6fcbf6... by Tom Tromey <email address hidden>

Minor fixup in allow_aarch64_sve_tests

An earlier patch failed to update a string in allow_aarch64_sve_tests.