get_stab_string_offset currently creates the stabstr section if not
already present, in the process keeping a reference to the malloc'd
section name string. Really, the name belongs in bfd_alloc'd memory
or some obstack so that it doesn't show as a memory leak on exit.
s_stab_generic at least does allocate the name for the stab section on
an obstack, but doesn't tidy that as well as it could. Return paths
after issuing a warning don't release the memory, nor the memory for
the "string" copy.
This patch fixes these problems. s_stab_generic is rearranged so that
creation of the sections occurs earlier, before any potential uses of
the note obstack during expression parsing. That makes it possible to
always free the section name strings unless used to create new
sections. I've also avoided get_absolute_expression_and_terminator
as I see that function might skip over end-of-line, and lack of a
--input_line_pointer might have caused the following source line to be
ignored. (Other uses of this function in gas are OK.)
* config/obj-coff.c (obj_coff_init_stab_section): Add stabstr
param. Pass to get_stab_string_offset rather than name of
section.
* config/obj-som.c (obj_som_init_stab_section): Likewise.
* config/obj-elf.c (obj_elf_init_stab_section): Likewise.
(elf_init_stab_section): Adjust.
* config/obj-coff.h (INIT_STAB_SECTION): Update.
(obj_coff_init_stab_section): Update prototype.
* config/obj-som.h: Similarly.
* config/obj-elf.h: Similarly.
* config/obj-multi.h (INIT_STAB_SECTION): Update.
* obj.h (struct format_ops <init_stab_section>): Update.
* read.h (get_stab_string_offset): Update prototype.
* stabs.c (cached_sec): Delete.
(stabs_begin): Adjust to suit.
(get_stab_string_offset): Add stabstr param, delete stabstr_name
and free_stabstr_secname params. Don't make stabstr section
here.
(eat_comma): New function.
(s_stab_generic): Replace stab_secname_obstack_end param with
bool freenames. Move creation of stab and stabstr sections
earlier, so the names can be freed earlier before possible use
of notes obstack during expression parsing. Tidy error paths
ensuring "string" is freed. Use get_absolute_expression in
place of get_absolute_expression_and_terminator.
(s_stab): Adjust.
(s_xstab): Use notes_concat to make stabstr section name.
Handle the remaining uses of TYPE_ALLOC, either by:
- replacing with TYPE_ZALLOC, or
- adding a comment explaining why zero-initialization is not necessary.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed some cases of TYPE_ALLOC followed by B_CLRALL.
Replace these with TYPE_ZALLOC.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Now that we've introduced type::{alloc_fields,copy_fields}, the places where
no zero-initialization of allocated fields is done are easy to spot:
...
$ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
gdb/coffread.c: type->alloc_fields (nfields, false);
gdb/coffread.c: type->alloc_fields (nsyms, false);
gdb/stabsread.c: ftype->alloc_fields (nsemi, false);
gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false);
gdb/gdbtypes.c: alloc_fields (nfields, false);
gdb/gdbtypes.c: alloc_fields (nfields, false);
gdb/mdebugread.c: t->alloc_fields (nfields, false);
gdb/mdebugread.c: ftype->alloc_fields (nparams, false);
...
All hits in gdbtypes.c are ok. There are two hits in the two variants of
copy_fields, and there's already a comment for the third.
AFAICT, the other ones are not ok, so fix those by dropping the "false"
argument.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
After finding this code in buildsym_compunit::finish_block_internal:
...
ftype->set_fields
((struct field *)
TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...
and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
locations that needed fixing.
I decided to make things easier to spot by factoring out a new function
alloc_fields:
...
/* Allocate the fields array of this type, with NFIELDS elements. If INIT,
zero-initialize the allocated memory. */
void
type::alloc_fields (unsigned int nfields, bool init = true);
...
where:
- a regular use would be "alloc_fields (nfields)", and
- an exceptional use that needed no initialization would be
"alloc_fields (nfields, false)".
Pretty soon I discovered that most of the latter cases are due to
initialization by memcpy, so I added two variants of copy_fields as well.
After this rewrite there are 8 uses of set_fields left:
...
gdb/coffread.c: type->set_fields (nullptr);
gdb/coffread.c: type->set_fields (nullptr);
gdb/coffread.c: type->set_fields (nullptr);
gdb/eval.c: type->set_fields
gdb/gdbtypes.c: type->set_fields (args);
gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (),
gdb/dwarf2/read.c: type->set_fields (new_fields);
gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1);
...
These fall into the following categories:
- set to nullptr (coffread.c),
- type not owned by objfile or gdbarch (eval.c), and
- modifying an existing fields array, like adding an element at the end or
dropping an element at the start (the rest).
Tested on x86_64-linux.
When running test-case gdb.dwarf2/per-bfd-sharing.exp with target board stabs,
gdb either segfaults or asserts due to reading uninitialized memory, allocated
here in buildsym_compunit::finish_block_internal:
...
ftype->set_fields
((struct field *)
TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...
Fix this by using TYPE_ZALLOC instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30810
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30810
Update ARC's elfarcv2 script template with:
- The .ivt section (Interrupt Vector Table) is mapped at the begining
of STARTUP_MEMORY when ivtbase_addr is not defined. Previously, it
was pointing to 0x00.
- MEMORY_FILE is a new emulation paramter and sets the name for the
linker script file which holds the MEMORY commands required by
arcv2elfx emulation.
- Four new linker variables are introduced available when arcv2elf emulation is used:
* __TEXT_REGION_ORIGIN__ Once defined it is setting the text region origin. By default it points to zero.
* __TEXT_REGION_LENGTH__ Once defined it is setting the text region length. By default it is set to 2M.
* __DATA_REGION_ORIGIN__ Once defined it is setting the data region origin. By default it is set to 0x80000000.
* __DATA_REGION_LENGTH__ Once defined it is setting the data region length. By default it is set to 2M.
ld/ChangeLog:
* scripttempl/elfarcv2.sc: Update script template.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
Check DT_SYMTAB only on non-IR object of archive member to avoid crash
on LLVM IR object with NULL elf_tdata.
PR ld/30811
* elflink.c (elf_link_is_defined_archive_symbol): Check
DT_SYMTAB only on non-IR object.
Pattern rules in doc/local.mk exist that specify how to make
libbfd.texi from libfd.h or libbfd.c. Since both files exist and the
libbfd.h rule is first, libbfd.h is used. libbfd.h doesn't contain
the documentation..
* doc/local.mk (doc/%stamp): Put rule making this from %.c
before %.h rule.
* Makefile.in: Regenerate.
* libbfd.c (Byte swapping routines): Don't omit description.
There isn't any reason to think that a particular buffer size is
ideal in bfd, so let's just not define it.
* libbfd-in.h (DEFAULT_BUFFERSIZE): Don't define.
* libbfd.h: Regenerate.
* archive.c (AR_WRITE_BUFFERSIZE): Substitute value.
* vms-lib.c (_bfd_vms_lib_write_archive_contents): Likewise.
* coff-rs6000.c (do_copy): Likewise, and use sizeof.
When running test-case gdb.dwarf2/nullptr_t.exp with target board
cc-with-dwz-m, I run into:
...
FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
...
The problem is that were looking for "typedef void decltype\\(nullptr\\)"
using "maint print symbols -source $srcfile", but dwz has moved the typedef to
a PU, so it's shown by "maint print symbols -source <unknown>" instead.
Fix this by dropping the "-source $srcfile" bit.
Tested on x86_64-linux, with make-check-all.sh.
Replace the manual fill of the vector with the appropriate std::vector
constructor that makes N copies of the provided value.
Change-Id: I579570748c48f53d35024105269d83c716294746
Approved-By: Tom Tromey <tom@tromey.com>
This safeguards a couple of places that may theoretically return NULL but
must not in this specific context. These were found by a static analysis tool.
Approved-By: Tom Tromey <tom@tromey.com>
Although XVentanaCondOps instructions are XLEN-agonistic, Ventana's manual
only defines them only for RV64 (because all Ventana's processors implement
RV64).
This commit limits XVentanaCondOps instructions RV64-only to match the
behavior of the manual and LLVM.
Note that this commit alone will not make XVentanaCondOps extension with
RV32 invalid (it just makes XVentanaCondOps on RV32 empty).
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Restrict "vt.maskc" and "vt.maskcn"
to XLEN=64.
gas/ChangeLog:
* testsuite/gas/riscv/x-ventana-condops-32.d: New failure test.
* testsuite/gas/riscv/x-ventana-condops-32.l: Likewise.
When running test-case gdb.arch/i386-avx512.exp, I run into:
...
gdb compile failed, In file included from gdb.arch/i386-avx512.c:20:0:
src/gdb/nat/x86-cpuid.h: In function 'x86_cpuid_count':
src/gdb/nat/x86-cpuid.h:63:16: error: \
'nullptr' undeclared (first use in this function)
if (__eax == nullptr)
^~~~~~~
src/gdb/nat/x86-cpuid.h:63:16: note: each \
undeclared identifier is reported only once for each function it appears in
=== gdb Summary ===
# of untested testcases 1
...
This is due to commit e85aad4ae7 ("nat/x86-cpuid.h: Add x86_cpuid_count
wrapper around __get_cpuid_count"), which introduced the nullptr check.
The header file gdb/nat/x86-cpuid.h is a file that is included in the build
and compiled as a C++ file, but also in the testsuite and compiled as a C
file.
Fix this by replacing nullptr with (void *)0.
Tested on x86_64-linux.
Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>
array_operation::evaluate has variables named "tem2" and "tem3". This
patch replaces one with a better name, and entirely removes the other.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
value_array requires the passed-in bounds to match the length of the
array_view it is given. This patch removes the redundant "highbound"
parameter.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This removes yet another redundant variable from
array_operation::evaluate -- only one index is needed.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In array_operation::evaluate, 'idx' and 'tem' are redundant in one
branch. This patch merges them, using the clearer name.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This hoists the array bounds check in array_operation::evaluate to
before the loop.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes array_operation::evaluate to declare the 'tem' variable
in the loop header, rather than at the top of the function. This is
cleaner and easier to reason about. I also changed 'nargs' to be
'const'.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes value_array to accept an array view. I also replaced an
alloca with a std::vector in array_operation::evaluate. This function
can work on any size of array, so it seems bad to use alloca.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When running this test on a processor that supports AVX512 (AMD EPYC
9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see:
continue^M
Continuing.^M
Process record does not support instruction bound.^M
Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
The instruction at this address is:
0x00007ffff7f49b40: 62 e2 7d 48 7a c6 vpbroadcastb %esi,%zmm16
This seems like an AVX512 instruction (given the use of zmm16). Match
this byte value in order to produce a KFAIL.
Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into:
...
Running gdb.arch/i386-avx512.exp ...
gdb compile failed, gcc: error: unrecognized command line option '-mavx512f'
...
Fix this by requiring have_compile_flag -mavx512f.
Tested on x86_64-linux.
When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run
into:
...
cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’
ABI3 test_abi_tag_struct s;
^
...
The test-case is supported starting gcc 5.
Fix this by requiring gcc >= 5, if a gcc compiler is used.
Tested on x86_64-linux.
When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
into a compilation failure due to the test-case requiring c++11 and the
compiler defaulting to less than that.
Fix this by compiling with -std=c++11.
Likewise in a few other test-cases.
Tested on x86_64-linux.
In test-case gdb.tui/pr30056.exp we check for:
...
require {have_host_locale C.UTF-8}
...
The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to
find it in the list returned by host_locales.
On my development platform, "locale -a" lists C.utf8, which is normalized to
"c.utf8" by host_locales, so there's a match and have_host_locale returns true.
On another platform however, "locale -a" lists C.UTF-8, which is normalized to
"c.utf-8" by host_locales, so there's no match and have_host_locale returns false.
Fix this by also dropping the dash in host_locales.
Tested on x86_64-linux.
This patch changes remote.c so that the getpkt 'forever' parameter now
defaults to 'false' and fixes up all the callers.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
getpkt and getpkt_or_notif_sane are just wrappers for
getpkt_or_notif_sane_1. This patch adds the is_notif parameter to
getpkt, with a suitable default, and removes the wrappers.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
For getpkt_or_notif_sane_1, expecting_notif is redundant, because it
always reflects whether the is_notif parameter is non-NULL. This
patch removes the redundant parameter.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19,
we run into:
...
gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \
sys/random.h: No such file or directory
#include <sys/random.h>
^
compilation terminated.
=== gdb Summary ===
# of untested testcases 1
...
and:
...
UNTESTED: gdb.reverse/getrandom.exp: failed to prepare
...
Fix this by testing for the presence of the header, such that we have instead:
...
UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \
have_system_header sys/random.h
...
Tested on x86_64-linux and i686-linux.
In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
mentioned:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement
XFAIL: gdb.cp/nsusing.exp: print x, only using M
...
Add the missing PRMS, such that we have:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
...
and limit the xfail to unfixed versions.
The PR is fixed starting gcc 13, but it has been backported to release
branches stretching back to gcc 10. For simplicity we just stick to testing
for the major version and ignore the backported fixes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
