aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-09-05Use ada_value_subscript in valpy_getitemTom Tromey2-0/+4
Ada has a few complexities when it comes to array handling. Currently these are all handled in Ada-specific code -- but unfortunately that means they aren't really accessible to Python. This patch changes the Python code to defer to Ada when given an Ada array. In order to make this work, one spot in ada-lang.c had to be updated to set the "GNAT-specific" flag on an array type. The test case for this will come in a later patch.
2023-09-05Introduce TYPE_SPECIFIC_RUST_STUFFTom Tromey3-2/+25
This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes the DWARF reader to set this on Rust types. This will be used as a flag in a later patch. Note that the size of the type_specific_field bitfield had to be increased. I checked that this did not impact the size of main_type.
2023-09-05Refactor Rust code for slice-to-array operationTom Tromey2-9/+35
This patch exposes rust_slice_type_p and introduces rust_slice_to_array, in preparation for subsequent patches that will need these.
2023-09-05Move rust_language::lookup_symbol_nonlocalTom Tromey2-31/+38
This moves rust_language::lookup_symbol_nonlocal to rust-lang.c. There's no need to have it in rust-lang.h and moving it lets us avoid adding new includes in a later patch.
2023-09-05gdb/riscv: Fix oob memory access when printing info registersCiaran Woodward1-1/+1
If the length of a register name was greater than 15, print_spaces was called with a negative number, which prints random data from the heap instead of the requested number of spaces. This could happen if a target-description file was used to specify additional long-named registers. Fix is simple - don't ask for fewer than 1 space (since we still want column separation). Approved-by: Kevin Buettner <kevinb@redhat.com>
2023-09-05Read Ada main name from executable, not inferiorTom Tromey6-3/+132
An upstream bug report points out this bug: if the user switches from one Ada executable to another without "kill"ing the inferior, then the "start" command will fail. What happens here is that the Ada "main" name is found in a constant string in the executable. But, if the inferior is running, then the process_stratum target reads from the inferior memory. This patch fixes the problem by changing the main name code to set trust-readonly-sections, causing the target stack to read from the executable instead. I looked briefly at changing GNAT to emit DW_AT_main_subprogram instead, but this looks to be pretty involved. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811
2023-09-05Avoid crash with Ada and -fdata-sectionsTom Tromey3-1/+55
A user noticed that gdb would crash when showing a backtrace. Investigation showed this to be a crash in the DWARF reader when handling a "pragma export" symbol. The bug here is that earlier code decides to eliminate the symbol, but the export code tries to add it anyway -- but to a NULL list.
2023-09-05readelf: Add option to display the names of sections referenced by symbols.Nick Clifton4-195/+366
PR 30684 * readelf.c (extra_sym_info): New variable. (section_name_valid): Also check for filedata being NULL. (section_name_print): Delete. (section_index_real): New function. Returns true if the given section index references a real section. (print_symbol): Rename to print_sumbol_name. (printable_section_name): Use a rotating array of static buffers for the return string. (printable_section_name_from_index): Merge code from dump_relocations and get_symbol_index_type into here. (long_option_values): Add OPTION_NO_EXTRA_SYM_INFO. (options): Add "extra-sym-info" and "no-extra-sym-info". (usage): Mention new options. (parse_args): Parse new options. (get_symbol_index_type): Delete. (print_dynamic_symbol_size): Rename to print_symbol_size. (print_dynamic_symbol): Rename to print_symbol. (print_symbol_table_heading): New function. (process_symbol_table): Use new function. * doc/binutils.texi: Document the new option. * NEWS: Mention the new feature.
2023-09-05RISC-V: fold duplicate code in vector_macro()Jan Beulich3-43/+7
There's no need to have almost identical code twice. Do away with M_VMSGEU and instead simply use an unused (for these macros) field to tell apart both variants.
2023-09-05RISC-V: Add stub support for the 'Svadu' extensionTsukasa OI1-0/+2
This commit implements support for 'Svadu' extension. Because it does not add any instructions or CSRs (but adds bits to existing CSRs), this commit only adds extension name support and implication to the 'Zicsr' extension. This is based on the "Hardware Updating of PTE A/D Bits (Svadu)" specification, version 1.0-rc1 (Frozen): <https://github.com/riscv/riscv-svadu/releases/tag/v1.0-rc1> bfd/ChangeLog: * elfxx-riscv.c (riscv_implicit_subsets): Add implication from 'Svadu' to 'Zicsr'. (riscv_supported_std_s_ext) Add 'Svadu'.
2023-09-05RISC-V: Fix typo in the testsuiteTsukasa OI1-1/+1
gas/ChangeLog: * testsuite/gas/riscv/csr.s: Fix typo. mhcounteren is superseded by minstretcfg, not mcyclecfg.
2023-09-05RISC-V: Add 'Smcntrpmf' extension and its CSRsTsukasa OI14-50/+228
This commit adds now stable and approved 'Smcntrpmf' extension defined by the RISC-V Cycle and Instret Privilege Mode Filtering specification. Note that, because mcyclecfg and minstretcfg CSRs conflict with the privileged specification version 1.9.1, CSRs for this extension are only enabled on the privileged specification version 1.10 or later. By checking the base privileged specification, we no longer need to change the design of base CSR handling. This is based on the specification version v1.0_rc1 (Frozen): <https://github.com/riscv/riscv-smcntrpmf/commit/32b752c40d59c1b5e95de83399c1f54be6669163> bfd/ChangeLog: * elfxx-riscv.c (riscv_implicit_subsets): Add implication rule from the new 'Smcntrpmf' extension. (riscv_supported_std_s_ext): Add 'Smcntrpmf' to the supported S extension list. gas/ChangeLog: * config/tc-riscv.c (enum riscv_csr_class): Add new CSR classes CSR_CLASS_SMCNTRPMF and CSR_CLASS_SMCNTRPMF_32. (riscv_csr_address): Add handling for new CSR classes. * testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs. Move "mscounteren" and "mhcounteren" CSRs and note that they are now aliases. * testsuite/gas/riscv/csr-dw-regnums.d: Reflect the change. * testsuite/gas/riscv/csr.s: Add new CSRs. Move "mscounteren" and "mhcounteren" CSRs and note that they are now reused for the 'Smcntrpmf' extension. * testsuite/gas/riscv/csr-version-1p9p1.d: Reflect the changes of csr.s. * testsuite/gas/riscv/csr-version-1p9p1.l: Likewise. * testsuite/gas/riscv/csr-version-1p10.d: Likewise. * testsuite/gas/riscv/csr-version-1p10.l: Likewise. * testsuite/gas/riscv/csr-version-1p11.d: Likewise. * testsuite/gas/riscv/csr-version-1p11.l: Likewise. * testsuite/gas/riscv/csr-version-1p12.d: Likewise. * testsuite/gas/riscv/csr-version-1p12.l: Likewise. include/ChangeLog: * opcode/riscv-opc.h: Add new CSRs noting that this extension is incompatible with the privileged specification version 1.9.1. Move "mscounteren" and "mhcounteren" CSRs, make them aliases and reuse the CSR numbers from the 'Smcntrpmf' extension. (CSR_MSCOUNTEREN, CSR_MHCOUNTEREN) Remove as "mscounteren" and "mhcounteren" are now aliases and new CSR macros are used instead. (CSR_MCYCLECFG, CSR_MINSTRETCFG, CSR_MCYCLECFGH, CSR_MINSTRETCFGH): New CSR macros.
2023-09-05RISC-V: Prohibit combination of 'E' and 'H'Tsukasa OI3-0/+12
According to the ratified privileged specification (version 20211203), it says: > The hypervisor extension depends on an "I" base integer ISA with 32 x > registers (RV32I or RV64I), not RV32E, which has only 16 x registers. Also in the latest draft, it also prohibits RV64E with the 'H' extension. This commit prohibits the combination of 'E' and 'H' extensions. bfd/ChangeLog: * elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 'E' and 'H' combinations. gas/ChangeLog: * testsuite/gas/riscv/march-fail-rv32eh.d: New failure test to make sure that RV32E + 'H' is prohibited. * testsuite/gas/riscv/march-fail-rv32eh.l: Likewise.
2023-09-05Automatic date update in version.inGDB Administrator1-1/+1
2023-09-04arm: Make 'conflicting CPU architectures' error message more user-friendlyChristophe Lyon3-6/+7
Error messages such as "conflicting CPU architectures 10/16" are not very to understand, so this patch replaces the numbers with the description they actually mean: "conflicting CPU architectures ARM v7E-M vs Pre v4" 2023-09-01 Christophe Lyon <christophe.lyon@linaro.org> bfd/ * elf32-arm.c (tag_cpu_arch_combine): Add name_table parameter and use it. (elf32_arm_merge_eabi_attributes): Update call to tag_cpu_arch_combine. ld/ * testsuite/ld-arm/attr-merge-9.out: Update expected error message. * testsuite/ld-arm/attr-merge-arch-2.d: Likewise.
2023-09-04[gdb/testsuite] Fix race in gdb.base/add-symbol-file-attach.expTom de Vries1-2/+2
When running test-case gdb.base/add-symbol-file-attach.exp with target board unix/-m32, we run into: ... (gdb) attach 3955^M Attaching to process 3955^M Load new symbol table from "add-symbol-file-attach"? (y or n) y^M Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M Reading symbols from /lib/libm.so.6...^M Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M Reading symbols from /lib/libc.so.6...^M Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M Reading symbols from /lib/ld-linux.so.2...^M Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M 0xf7f53549 in __kernel_vsyscall ()^M (gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach ... The test fails because this regexp is used: ... -re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" { ... The regexp attempts to detect that the exec is somewhere in pause (): ... int main (int argc, char **argv) { pause (); return 0; } ... but when the exec is blocked in pause, the backtrace is: ... (gdb) bt #0 0xf7fd2549 in __kernel_vsyscall () #1 0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29 #2 0x0804844c in main (argc=1, argv=0xffffce84) at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26 ... We could simply extend the regexp to also match __kernel_vsyscall, but the more fundamental problem is that the test is racy. The attach can happen before the exec is blocked in pause (), somewhere in the dynamic linker resolving the call to pause, in main or even earlier. Note that for the test-case to be effective, the exec is not required to be in pause (). I added a "while (1);" loop at the start of main, reverted the patch fixing the corresponding PR and reproduced the problem it's supposed to detect. Fix this by simply matching the "Reading symbols from" line, similar to what an earlier test is doing. While we're at it, rewrite the earlier test to also use the -wrap idiom. Tested on x86_64-linux.
2023-09-04Automatic date update in version.inGDB Administrator1-1/+1
2023-09-03Automatic date update in version.inGDB Administrator1-1/+1
2023-09-01gdbserver: i387_cache_to_xsave: fix copy dest of zmm registersSimon Marchi1-2/+2
On a machine with AVX512 support (AMD EPYC 9634), I see these failures: $ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver" ... FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs ... The problem can be reduced to: (gdb) print $zmm16.v8_int64 $1 = {0, 0, 0, 0, 0, 0, 0, 0} (gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88} $2 = {11, 22, 33, 44, 55, 66, 77, 88} (gdb) print $zmm16.v8_int64 $3 = {11, 22, 33, 44, 55, 66, 77, 88} (gdb) step 5 ++x; (gdb) print $zmm16.v8_int64 $4 = {11, 22, 77, 88, 0, 0, 0, 0} Writing to the local regcache in GDB works fine, but the writeback to gdbserver (which happens when resuming / stepping) doesn't work (the code being stepped doesn't touch AVX registers, so we don't expect the value of zmm16 to change when stepping). The problem is on the gdbserver side, the zmmh and ymmh portions of the zmm register are not memcpied at the right place in the xsave buffer. Fix that. Note now how the two modified memcpy calls match the memcmp calls just above them. With this patch, gdb.arch/i386-avx512.exp passes completely for me. Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433 Reviewed-by: John Baldwin <jhb@FreeBSD.org> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818
2023-09-02Automatic date update in version.inGDB Administrator1-1/+1
2023-09-01config: Fix host -rdynamic detection for build != host != targetJoseph Myers1-1/+1
[Merge from GCC commit 4d9bc81a5d8d884dee7a7781fa4c1577a6c9681a.] The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic is necessary and supported uses an appropriate objdump for $host binaries (running on $build) in cases where $host is $build or $target. However, it is missing such logic in the case where $host is neither $build nor $target, resulting in the compilers not being linked with -rdynamic and plugins not being usable with such a compiler. In fact $ac_cv_prog_OBJDUMP, as used when $build = $host, is always an objdump for $host binaries that runs on $build; that is, it's appropriate to use in this case as well. Tested in such a configuration that it does result in cc1 being linked with -rdynamic as expected. Also bootstrapped with no regressions for x86_64-pc-linux-gnu. config/ * gcc-plugin.m4 (GCC_ENABLE_PLUGINS): Use export_sym_check="$ac_cv_prog_OBJDUMP -T" also when host is not build or target.
2023-09-01Fix "usage" errors for some MI varobj commandsTom Tromey1-3/+3
I noticed that the "usage" error for -var-set-frozen mentioned the wrong command name. Then I looked through the whole file and found a couple other spots that didn't mention the command name at all. This patch fixes all of these. Reviewed-by: Kevin Buettner <kevinb@redhat.com>
2023-09-01x86: unindent most of set_cpu_arch()Jan Beulich1-151/+154
Inverting the initial if()'s condition allows to move out the bulk of the function by a level, improving readability at least a bit. While doing that also pull the push/pop handling up first, such that "else if" after "return" isn't needed anymore; the order in which special cases are checked doesn't really matter.
2023-09-01x86: rename CpuPCLMULJan Beulich5-25/+25
The name we use internally isn't in line with the SDM, and also isn't in line with CpuVPCLMULQDQ. Add the missing suffix, but of course leave alone user facing names.
2023-09-01x86: correct source used for two non-AVX512 VEXWIG testsJan Beulich2-130/+32
These shouldn't wrongly include the AVX512VL sources. Obviously the expectations therefore also need to change.
2023-09-01x86: drop Size64 from VMOVQJan Beulich2-2/+2
Commit 916fae91358d ("Add Size64 to movq/vmovq with Reg64 operand" was right in adding the attribute to MOVQ, but there was no need to add it to VMOVQ. (See also the AVX512F form, which doesn't have the attribute either.)
2023-09-01RISC-V: move various alias entriesJan Beulich32-365/+218
For disassembly to only use spec-mandated aliases, respective non-alias entries need to come ahead of their alias ones. Since identical mnemonics need to stay together, whole groups are moved up where necessary. This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for consistent alias handling"), but then also goes beyond a plain revert. Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-09-01Fix ld Makefile variable naming: ELF_CLFAGS -> ELF_CFLAGSJerry Zhang Jian2-4/+4
Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
2023-09-01RISC-V: Fixed the wrong expansion for pseudo vmsge[u].vx instructions.Nelson Chu2-8/+8
The original report was from Kiva Oyama <libkernelpanic@gmail.com>, https://sourceware.org/pipermail/binutils/2023-August/129255.html The vmsge[u].vx pseudo should be expanded to masked vmslt[u].vx only when vd != v0. Otherwise, it should be expanded to unmasked one. gas/ * config/tc-riscv.c (vector_macro): Fixed the wrong expansion for pseudo vmsge[u].vx instructions. * testsuite/gas/riscv/vector-insns-vmsgtvx.d: Updated.
2023-08-31gdb: remove uses of alloca in gdbtypes.cSimon Marchi1-13/+12
Replace two uses of alloca with std::string. Change-Id: I970ae3f450da407494d95668a57bba8796d6292b Approved-by: Kevin Buettner <kevinb@redhat.com>
2023-09-01Automatic date update in version.inGDB Administrator1-1/+1
2023-09-01PR30806, CPPFLAGS are missing for bfd/chew, syslex_wrap and sysinfoNicolas Boulenguez4-8/+8
PR 30806 bfd/ * doc/local.mk (doc/chew.stamp): Add CPPFLAGS_FOR_BUILD. * Makefile.in: Regenerate. binutils/ * Makefile.am (syslex_wrap.@OBJEXT@): Add CPPFLAGS_FOR_BUILD. (sysinfo.@OBJEXT@): Likewise. * Makefile.in: Regenerate.
2023-08-31elf: Adjust PR ld/30791 testsH.J. Lu2-0/+7
Adjust PR ld/30791 tests: 1. Generic linker targets don't comply with all orhpan section merging rules. 2. z80 fails since a, b, c, d are registers for z80. 3. hppa fails since .text sections aren't merged for relocatable link. PR ld/30791 * testsuite/ld-elf/pr30791a.d: Xfail for generic and z80 targets. * testsuite/ld-elf/pr30791b.d: Xfail for hppa and z80 targets.
2023-08-31Add symbol::matches methodTom Tromey5-19/+21
This adds symbol::matches, a wrapper for symbol_matches_domain. Most places calling symbol_matches_domain can call this method instead, which is a bit less wordy and also (IMO) clearer. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-31gdb: remove TYPE_FIELD_PACKEDSimon Marchi11-13/+16
Replace with a new equivalent "is_packed" method on struct field. Change-Id: I78647be3d408b40b63becb6b6f0fca211bede51c Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: remove TYPE_FIELD_BITSIZESimon Marchi21-69/+65
Replace with type::field + field::bitsize. Change-Id: I2a24755a33683e4a2775a6d2a7b7a9ae7362e43a Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: remove FIELD_BITSIZESimon Marchi4-10/+8
Replace with field::bitsize. Change-Id: I400be235d6a1f446d0a4aafac01df5e850185d3a Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: introduce field::bitsize / field::set_bitsizeSimon Marchi11-51/+60
Add these two methods, rename the field to m_bitsize to make it pseudo private. Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: remove TYPE_FIELD_ARTIFICIALSimon Marchi11-20/+19
Replace with type::field + field::is_artificial. Change-Id: Ie3bacae49d9bd02e83e504c1ce01470aba56a081 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: remove FIELD_ARTIFICIALSimon Marchi4-5/+4
Replace uses with field::is_artificial. Change-Id: I599616fdd9f4b6d044de492e8151aa6130725cd1 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31gdb: introduce field::is_artificial / field::set_is_artificialSimon Marchi7-15/+26
Add these two methods, rename the field to m_artificial to make it pseudo private. Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31Remove eval_op_ternopTom Tromey2-27/+18
eval_op_ternop is only used by the implementation of ternop_slice_operation. While working on another series, it was convenient for me to merge this function into its only caller. Reviewed-by: Kevin Buettner <kevinb@redhat.com>
2023-08-31[symtab/27831] New test case: gdb.base/add-symbol-file-attach.expKevin Buettner2-0/+110
This commit adds a new test case for bug 27831. See the contents of the .exp file for a description of what it's about. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831 Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31[symtab/27831] Fix OBJF_MAINLINE assertKevin Buettner4-17/+37
This commit fixes a bug mentioned by Florian Weimer during the libpthread/ld.so load order discussion from 2021. Florian provided instructions for reproducing the bug here: https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html That particular test does some interesting things involving forks, threads, and thread local storage. Fortunately, none of that is needed to reproduce the problem. I've made a new test case (which is now found in a separate commit) contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The .c file is fairly simple as is the recipe for reproducing the problem. After separately starting the test case and noting the process id, start gdb (w/ no arguments), and do the following to reproduce the assertion failure - for this run, the process id of the separately started add-symbol-file-attach process is 4103218: (gdb) add-symbol-file add-symbol-file-attach add symbol table from file "add-symbol-file-attach" (y or n) y Reading symbols from add-symbol-file-attach... (gdb) attach 4103218 Attaching to process 4103218 Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y Reading symbols from /tmp/add-symbol-file-attach... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007f502130bf27 in pause () from /lib64/libc.so.6 (gdb) p foo symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*, const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. The add-symbol-file command causes the symbols to be loaded without the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being set. This, in turn, causes the "maybe_copied" flag to be set for the global symbol (named "foo" in the provided test case). The attach command will cause another objfile to be created, but it will reuse the symtabs from the objfile created by add-symbol-file, leading to a situation in which the OBJFILE_MAINLINE flag will be set for the new (attach-created) objfile, however the "maybe_copied" flag will still be set for the global symbol. Had it been loaded anew, this flag would not be set due to OBJFILE_MAINLINE being set for the objfile. At present, minimal_symbol::value_address looks like this: CORE_ADDR minimal_symbol::value_address (objfile *objfile) const { if (this->maybe_copied (objfile)) return get_msymbol_address (objfile, this); else return (CORE_ADDR (this->unrelocated_address ()) + objfile->section_offsets[this->section_index ()]); } So, we can now see the problem: When the "maybe_copied" flag is set, get_msymbol_address() will be called. However, get_msymbol_address() assumes that it won't be called with the OBF_MAINLINE flag set for the objfile in question. It, in fact, contains an assert() which makes sure that this is the case: gdb_assert ((objf->flags & OBJF_MAINLINE) == 0); (If this assert is removed, then get_msymbol_address() recurses infinitely for the case under consideration.) So, the problem here is that the maybe_copied flag is set for the symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted earlier, this happens due to add-symbol-file being used; this causes the maybe_copied flag to be set. Later, when the attach is performed, OBJF_MAINLINE will be set for that objfile, leading to this unfortunate situation. My first cut at a solution involved adjusting the MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the method noted above) to include a test of the OBJFILE_MAINLINE flag. However, Simon Marchi, in his review of my patch, suggested a better solution. Simon observed that the 'maybe_copied' flag is (was, after this commit) being set/initialized in record_minimal_symbol() using using the objfile in the context in which the symbol was created. Simon further observed: Today, a single copy is created, as symtabs are shared between objfiles. This means that everything that we store into a symbol must be independent of any objfile. However, the value of the maybe_copied field is dependent on the objfile in the context of which the symbol was created. Meaning that when the symbol is re-used in the context of another objfile, the maybe_copied value is not right in the context of that objfile. So I think it means there isn't a single "is this symbol maybe copied" value, but instead "is this symbol maybe copied, in the context of this given objfile". And the answer is yes or no, depending on whether the objfile is mainline. So maybe_copied should become a method that takes an objfile and returns an answer based on that. Simon's full review can be found here: https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html Simon also provided a patch which implements this suggestion. The current patch is mostly his work, though I did make some adjustments during a rebase in addition to making some changes to account for a concern from Tom Tromey. During his review of the v3 series, Tom noted, "The old approach was specific to ELF, while the new approach will be used by any object format." Tom further observed, "...it seems like it could result in an incorrect evaluation in some scenario." This seemed plausible to me, so I introduced the flag 'object_format_has_copy_relocs' to struct objfile. It is set at the end of elf_symfile_read() in elfread.c. The minimal_symbol::maybe_copied method tests this new flag, forcing this method to return false when the flag is not set. If we find that other object file formats use the same copy reloc mechanism as ELF, then 'object_format_has_copy_relocs' should be set for objfiles using those formats. Lastly, I'll note that this is a strange use case. It's far more common to either let gdb figure out which file to load by itself when attaching, i.e. (gdb) attach 4104360 Attaching to process 4104360 Reading symbols from /tmp/add-symbol-file-attach... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 (gdb) p foo $1 = 42 ...or to use the "file" command prior to the attach, like this: (gdb) file add-symbol-file-attach Reading symbols from add-symbol-file-attach... (gdb) attach 4104360 Attaching to program: /tmp/add-symbol-file-attach, process 4104360 Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 Both of these more common scenarios work perfectly fine; using "add-symbol-file" to load the program to which you will attach isn't recommended as a normal use case. That said, it's bad for gdb to assert, hence this fix. Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca> Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca> Approved-by: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
2023-08-31Unify DW_TAG_typedef case in new_symbolTom Tromey1-5/+1
This patch merges the DW_TAG_typedef case in new_symbol with some other type-related cases. These all have identical code. Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
2023-08-31Revert "Simplify @node use in BFD documentation"Tom Tromey3-29/+35
This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8. My earlier patch to simplifify the @node uses in the BFD manual didn't take into account (1) that BFD doesn't use the ordinary texinfo sectioning commands, and (2) that some users are stuck on very ancient versions of makeinfo. This patch reverts the change. I went through the entire manual using the spacebar, trying to find the original problem I reported in the change, but couldn't. I don't know why. Anyway, all this means is that, with this reversion, editing the node structure will be slightly less convenient. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30703 2023-08-30 Tom Tromey <tom@tromey.com> PR binutils/30703 * doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding parameters back to @node.
2023-08-31[gdb/contrib] Require minimal dwz version in cc-with-tweaks.shTom de Vries1-0/+18
I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build from current trunk, but the pathname to the build dir changed and I forgot to update my test scripts, so the test scripts reverted to using system dwz, version 0.12. Consequently, I ran into: ... (gdb) p ZERO^M No symbol "ZERO" in current context.^M (gdb) FAIL: gdb.base/enumval.exp: p ZERO ... which is due to PR dwz/24468, which was fixed in version 0.13. Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such that this situation is detected and we get instead: ... gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \ 0.13 or higher required ... Tested on x86_64-linux, verified with shellcheck. Approved-By: Tom Tromey <tom@tromey.com>
2023-08-31vms-alpha: Free memory on failure pathAlan Modra1-1/+1
* vms-alpha.c (evax_bfd_print_eobj): Free rec on failure.
2023-08-31gas init_stab_section and get_stab_string_offsetAlan Modra10-150/+118
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.
2023-08-31gas OBJ_PROCESS_STABAlan Modra10-19/+16
This macro and the supporting functions have an unused "seg" first argument. Tidy that. * config/obj-aout.c (obj_aout_process_stab): Delete first param. * config/obj-ecoff.h (OBJ_PROCESS_STAB): Likewise. * config/obj-elf.c (elf_process_stab): Likewise. * config/obj-elf.h (OBJ_PROCESS_STAB): Likewise. * config/obj-macho.h (OBJ_PROCESS_STAB): Likewise. * config/obj-multi.h (OBJ_PROCESS_STAB): Likewise. * ecoff.c (ecoff_stab): Likewise. * ecoff.h (ecoff_stab): Likewise. * obj.h (struct format_ops <process_stab>): Likewise. * stabs.c (OBJ_PROCESS_STAB): Likewise.
generated by cgit v1.1 at 2025-09-23 11:41:40 +0000