Tom de Vries [Wed, 11 Jan 2023 10:44:00 +0000 (11:44 +0100)]
[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc, again
On an x86_64 laptop running ubuntu 22.04.1 with unity desktop:
...
$ echo $XDG_CURRENT_DESKTOP
Unity:Unity7:ubuntu
...
I have:
...
$ echo $LD_PRELOAD
libgtk3-nocsd.so.0
...
due to package gtk3-nocsd, a package recommended by unity-session.
Consequently, for each exec these dependencies are pulled in, including
libpthread.so.0:
...
$ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
...
So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok:
...
# of expected passes 12
# of unsupported tests 1
...
with LD_PRELOAD="" we have instead:
...
(gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify
info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex Yes dlopen-libpthread.so^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found
...
The problem is that libpthread is expected as dependency of
dlopen-libpthread.so, but it's missing:
...
$ lddtree dlopen-libpthread.so
dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none)
libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
...
due to having glibc 2.35, which has libpthread integrated into libc.
Fix this by:
- adding a proc has_dependency
- using [has_dependency $exec libpthread.so] as hint that libpthread
may be preloaded
- using ![has_dependency $shlib libpthread.so] to detect that
the libpthread.so dependency is missing.
Also add a missing return after untested "no matching probes".
Tested on x86_64-linux, with and without LD_PRELOAD="".
Jan Beulich [Wed, 11 Jan 2023 09:31:43 +0000 (10:31 +0100)]
gas/RISC-V: adjust assembler for opcode table re-ordering
PR gas/29940
With the single-operand JAL entry now sitting ahead of the two-operand
one, the parsing of a two-operand insn would first try to parse an 'a'-
style operand, resulting in the insertion of bogus (and otherwise
unused) undefined symbols in the symbol table, having register names.
Since 'a' is used as 1st operand only with J and JAL, and since JAL is
the only insn _also_ allowing for a register as 1st operand (and then
there being a 2nd one), special case this parsing aspect right there.
Alan Modra [Wed, 11 Jan 2023 05:01:06 +0000 (15:31 +1030)]
now_seg after closing output file
now_seg, a pointer into the output file sections, isn't valid after
the output file is closed. gas doesn't and shouldn't use now_seg
after this point of course, but let's be safe.
* output-file.c (output_file_close): Clear now_seg and now_subseg.
Mark Harmstone [Tue, 27 Dec 2022 22:16:04 +0000 (22:16 +0000)]
gas: Restore tc_pe_dwarf2_emit_offset for pe-aarch64
Restores tc_pe_dwarf2_emit_offset in tc-aarch64.c, which is needed to
make sure that DWARF offsets are encoded correctly (they're secrels in
COFF). There were remnants of this there before, but they were removed
by Jedidiah's original patch - presumably because we didn't yet have
.secrel32.
Mark Harmstone [Wed, 14 Dec 2022 00:54:34 +0000 (00:54 +0000)]
Add pe-aarch64 relocations
This adds the remaining pe-aarch64 relocations, and gets them working.
It also brings in the constant directives from ELF, as otherwise .word
would be 2 rather than 4 bytes, and .xword and .dword wouldn't be
defined.
Mark Harmstone [Wed, 14 Dec 2022 00:51:57 +0000 (00:51 +0000)]
Fix size of external_reloc for pe-aarch64
This patch series finishes off the work by Jedidiah Thompson, and adds
support for creating aarch64 PE images.
This should be essentially complete: I've used this to create a "hello
world" Windows program in asm, and (with GCC patches) a UEFI program in
C. I think the only things missing are the .secidx relocation, which is
needed for PDBs, and the SEH pseudos used for C++ exceptions.
This first patch fixes the size of RELSZ; I'm not sure why it was 14 in
the first place. This is the size of the "Base Relocation Block" in
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, and
AFAIK should be 10 for everything.
Rohr, Stephan [Wed, 21 Dec 2022 13:12:44 +0000 (14:12 +0100)]
gdb/dwarf2: Fix 'rw_pieced_value' for values casted to different type.
The 'rw_pieced_value' function is executed when fetching a (lazy)
variable described by 'DW_OP_piece' or 'DW_OP_bit_piece'. The
function checks the 'type' and 'enclosing_type' fields of the value
for identity.
* The 'type' field describes the type of a value.
* In most cases, the 'enclosing_type' field is identical to the
'type' field.
* Scenarios where the 'type' and 'enclosing_type' of an object
differ are described in 'gdb/value.c'. Possible cases are:
* If a value represents a C++ object, then the 'type' field
gives the object's compile-time type. If the object actually
belongs to some class derived from `type', perhaps with other
base classes and additional members, then `type' is just a
subobject of the real thing, and the full object is probably
larger than `type' would suggest.
* If 'type' is a dynamic class (i.e. one with a vtable), then GDB
can actually determine the object's run-time type by looking at
the run-time type information in the vtable. GDB may then elect
to read the entire object.
* If the user casts a variable to a different type
(e.g. 'print (<type> []) <variable>'), the value's type is
updated before reading the value.
If a lazy value is fetched, GDB allocates space based on the enclosing
type's length and typically reads the 'full' object. This is not
implemented for pieced values and causes an internal error if 'type'
and 'enclosing_type' of a value are not identical.
However, GDB can read the value based on its type. Thus, this patch
fixes the previously mentioned cases by removing the check for identity.
Mike Frysinger [Mon, 2 Jan 2023 00:03:28 +0000 (19:03 -0500)]
sim: common: move test-hw-events to top-level build
This is an internal developer target that isn't normally compiled,
but it can still be occasionally useful. Move it to the top-level
build so we can kill off common/Make-common.in.
Mike Frysinger [Tue, 27 Dec 2022 04:20:46 +0000 (23:20 -0500)]
sim: build: add basic framework for compiling arch objects in top-level
The code so far has been assuming that we only compile common/ objects.
Now that we're ready to compile arch-specific objects, refactor some of
the flags & checks a bit to support both.
Mike Frysinger [Sun, 6 Nov 2022 09:56:39 +0000 (16:56 +0700)]
sim: modules.c: move generation to top-level
Now that all arches create libsim.a from the top-level, we have full
access to their inputs, and can move the actual generation from the
subdir up to the top-level. This avoids recursive makes and will
help simplify state passing between the two.
Mike Frysinger [Tue, 27 Dec 2022 03:31:29 +0000 (22:31 -0500)]
sim: v850: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:29:53 +0000 (22:29 -0500)]
sim: sh: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:28:46 +0000 (22:28 -0500)]
sim: rx: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:27:31 +0000 (22:27 -0500)]
sim: rl78: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:25:23 +0000 (22:25 -0500)]
sim: riscv: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:21:51 +0000 (22:21 -0500)]
sim: pru: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:20:09 +0000 (22:20 -0500)]
sim: or1k: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:16:09 +0000 (22:16 -0500)]
sim: msp430: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:15:08 +0000 (22:15 -0500)]
sim: moxie: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:10:41 +0000 (22:10 -0500)]
sim: mn10300: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:08:08 +0000 (22:08 -0500)]
sim: mips: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
The mips code is a little more tricky than others because, for multi-run
targets, it generates the list of sources & objects on the fly in the
configure script.
Mike Frysinger [Tue, 27 Dec 2022 03:02:55 +0000 (22:02 -0500)]
sim: microblaze: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:01:29 +0000 (22:01 -0500)]
sim: mcore: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 03:00:16 +0000 (22:00 -0500)]
sim: m68hc11: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:58:02 +0000 (21:58 -0500)]
sim: m32r: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:54:30 +0000 (21:54 -0500)]
sim: m32c: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:51:58 +0000 (21:51 -0500)]
sim: lm32: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:48:51 +0000 (21:48 -0500)]
sim: iq2000: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:31:07 +0000 (21:31 -0500)]
sim: h8300: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:29:32 +0000 (21:29 -0500)]
sim: ft32: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:28:10 +0000 (21:28 -0500)]
sim: frv: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:22:03 +0000 (21:22 -0500)]
sim: example-synacor: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:19:35 +0000 (21:19 -0500)]
sim: erc32: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:13:08 +0000 (21:13 -0500)]
sim: d10v: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 02:10:34 +0000 (21:10 -0500)]
sim: cris: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 00:53:32 +0000 (19:53 -0500)]
sim: cr16: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Tue, 27 Dec 2022 00:45:47 +0000 (19:45 -0500)]
sim: bpf: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Mon, 26 Dec 2022 16:04:26 +0000 (11:04 -0500)]
sim: bfin: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Mon, 26 Dec 2022 03:59:01 +0000 (22:59 -0500)]
sim: avr: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Mon, 26 Dec 2022 03:55:46 +0000 (22:55 -0500)]
sim: arm: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Sun, 6 Nov 2022 15:25:18 +0000 (22:25 +0700)]
sim: aarch64: move libsim.a creation to top-level
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal. This will go
away of course once the top-level compiles objects.
Mike Frysinger [Sun, 25 Dec 2022 19:38:48 +0000 (14:38 -0500)]
sim: build: drop support for subdir extra deps
Nothing uses this hook anymore, so punt it. It was largely used to
track generated files (which we do in the top-level now) and extra
header files (which we use automake depgen for now).
Mike Frysinger [Sun, 25 Dec 2022 19:40:47 +0000 (14:40 -0500)]
sim: modules: trigger generation from top-level
Add rules for tracking generated subdir modules.c files. This doesn't
actually generate the file from the top-level, but allows us to add
rules that need to be ordered wrt it. Once those changes land, we can
rework this to actually generate from the top-level.
This currently builds off of the objects that go into the libsim.a as
we don't build those from the top-level either. Once we migrate that
up, we can switch this to the source files directly. It's a bit hacky
overall, but makes it easier to migrate things in smaller chunks, and
we aren't going to keep this logic long term.
Aaron Merey [Fri, 6 Jan 2023 23:45:27 +0000 (18:45 -0500)]
gdb/linespec.c: Fix missing source file during breakpoint re-set
During breakpoint re-setting, the source_filename of an
explicit_location_spec is used to lookup the symtabs associated with
the breakpoint being re-set. This source_filename is compared with each
known symtab filename in order to retrieve the breakpoint's symtabs.
However the source_filename may have been originally copied from a
symtab's fullname (the path where GDB found the source file) when the
breakpoint was first created. If a breakpoint symtab's filename and
fullname differ and there is no substitute-path rule that converts the
fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown
during re-setting.
Fix this by using a symtab's filename to set the explicit_location_spec
source_filename instead of the symtab's fullname.
Aaron Merey [Sat, 7 Jan 2023 00:06:15 +0000 (19:06 -0500)]
gdb/linespec.c: Fix -Wmaybe-uninitialized warning
Although the bool want_start_sal isn't actually used without being assigned
a value, initialize it to be false in order to prevent the following
-Wmaybe-uninitialized warning:
linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’:
linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized]
4150 | if (is_function && want_start_sal)
Alan Modra [Sun, 8 Jan 2023 02:26:21 +0000 (12:56 +1030)]
Set dwarf2 stash pointer earlier
This fixes a memory leak in the vanishingly rare cases (found by
fuzzers of course) when something goes wrong in the save_section_vma,
htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
to free that memory.
* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
on setting up stash.
Alan Modra [Sat, 7 Jan 2023 01:20:10 +0000 (11:50 +1030)]
peXXigen.c sanity checks
Also fix a memory leak, and make some style changes. I tend to read
(sizeof * x) as a multiplication of two variables, which I would not
do if binutils followed the gcc coding conventions consistently (see
https://gcc.gnu.org/codingconventions.html#Expressions). (sizeof *x)
looks a lot better to me, or even (sizeof (*x)) which I've used here.
* peXXigen.c (get_contents_sanity_check): New function.
(pe_print_idata): Use it here..
(pe_print_edata): ..and here. Free data on error return.
(rsrc_parse_entry): Check entry size read from file.
(rsrc_parse_entries): Style fixes.
(rsrc_process_section): Use bfd_malloc_and_get_section.
(_bfd_XXi_final_link_postscript): Likewise.
Alan Modra [Fri, 6 Jan 2023 12:08:33 +0000 (22:38 +1030)]
Move mips_refhi_list to bfd tdata
Similar to commit c799eddb3512, but for mips-ecoff. mips-ecoff is
marked obsolete, but we still allow reading of these object files in
a number of mips targets.
* coff-mips.c (struct mips_hi, mips_refhi_list): Delete.
(mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list
in ecoff_data.
* ecoff.c (_bfd_ecoff_close_and_cleanup): New function.
* libecoff.h (struct mips_hi): Moved from coff-mips.c.
(struct ecoff_tdata): Add mips_refhi_list.
(_bfd_ecoff_close_and_cleanup): Declare.
Alan Modra [Fri, 6 Jan 2023 10:45:31 +0000 (21:15 +1030)]
Move bfd_init to bfd.c
init.c contains just one function that doesn't do much. Move it to
bfd.c and give it something to do, initialising static state. So far
the only initialisation is for bfd.c static variables.
The idea behind reinitialising state is to see whether some set of
flaky oss-fuzz crashes go away. oss-fuzz stresses binutils in ways
that can't occur in reality, feeding multiple testcases into the
internals of binutils. So one testcase may affect the result of the
next testcase.
Tom Tromey [Fri, 23 Dec 2022 19:55:10 +0000 (12:55 -0700)]
Fix crash with C++ qualified names
PR c++/29503 points out that something like "b->Base::member" will
crash when 'b' does not have pointer type. This seems to be a simple
oversight in eval_op_member.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503 Reviewed-By: Bruno Larsen <blarsen@redhat.com>
projects / thirdparty / binutils-gdb.git / log
