aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2022-11-26[gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.expTom de Vries2-1/+15
When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I noticed: ... FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout) ... The timeout is 10 seconds, but generating the core file takes more than a minute, probably due to slow NFS. I managed to reproduce this behaviour independently of gdb, by compiling "int main (void) { __builtin_abort (); }" and running it, which took 1.5 seconds for a core file 50 times smaller than the one for gdb. Fix this by preventing the core file from being generated, using a wrapper around gdb that does "ulimit -c 0". Tested on x86_64-linux.
2022-11-26[gdb/symtab] Handle failure to open .gnu_debugaltlink fileTom de Vries2-1/+58
If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after dwz has created it, with test-case gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m we run into: ... (gdb) file access-mem-running-thread-exit^M Reading symbols from access-mem-running-thread-exit...^M could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M ... followed a bit later by: ... (gdb) file access-mem-running-thread-exit^M Reading symbols from access-mem-running-thread-exit...^M gdb/dwarf2/read.c:7284: internal-error: create_all_units: \ Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M ... The problem is that create_units does not catch the error thrown by dwarf2_get_dwz_file. Fix this by catching the error and performing the necessary cleanup, getting the same result for the first and second file command. PR symtab/29805 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
2022-11-26Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct.Philippe Waroquiers1-0/+1
Valgrind reports a "jump on unitialised bit error" when running e.g. gdb.base/macro-source-path.exp (see details below). Fix this by initializing producer_is_clang member variable of dwarf2_cu. Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp under valgrind. ==2140965== Conditional jump or move depends on uninitialised value(s) ==2140965== at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676) ==2140965== by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967) ==2140965== by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379) ==2140965== by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687) ==2140965== by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660) ==2140965== by 0x5569C7: process_full_comp_unit (read.c:8429) ==2140965== by 0x5569C7: process_queue (read.c:7675) ==2140965== by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063) ==2140965== by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) .... ==2140965== Uninitialised value was created by a heap allocation ==2140965== at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434) ==2140965== by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264) ==2140965== by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729) ==2140965== by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021) ==2140965== by 0x55634C: dw2_do_instantiate_symtab (read.c:2048) ==2140965== by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085) ==2140965== by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984) ==2140965== by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781) ==2140965== by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276) ....
2022-11-26remove the declared but undefined/unused method find_partial_diePhilippe Waroquiers1-2/+0
The method struct partial_die_info *find_partial_die (sect_offset sect_off); in cu.h is defined, but is used nowhere and not implemented.
2022-11-24gdb: fix typo in debug output messageAndrew Burgess1-1/+1
Spotted a minor type, a missing ')', in a debug message.
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_breakSimon Marchi1-307/+293
Move all the remaining tests to a single test_break proc. It's a bit big, but all of these are kind of tied together. The procs starts by setting breakpoints, checks that we can see them in "info breakpoints", and tries stopping on them. Move all the "set bp_locationX" calls together at the top. Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_tbreakSimon Marchi1-46/+36
Leave setting bp_location11 in the global scope, so that it's accessible to other procs. Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_no_break_on_catchpointSimon Marchi1-11/+17
Change-Id: Ifa7070943f1de22c2839fedf5f346d6591bb5a76 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_nonexistent_lineSimon Marchi1-5/+15
Change-Id: I4390dd5da23bae83ccc513ad0de0169ddff7df12 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_defaultSimon Marchi1-25/+37
One special thing here is that the part just above this one, that sets catchpoints and verifies they are not hit, requires that we resume execution to verify that the catchpoints are indeed not hit. I guess it was previously achieved by the until command, but it doesn't happen now that the until is moved into test_break_default. Add a gdb_continue_to_end after setting the catchpoints. If any catchpoint were to be hit, it would catch the problem. Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_silent_and_moreSimon Marchi1-56/+62
This one is a bit tricky. The clear tests seem to depend on the various breakpoints that have been set before, starting with the "silent" breakpoints. So, move all this in a single chunk, it can always be split later if needed. Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_line_convenience_varSimon Marchi1-5/+11
Change-Id: I593002373da971a0a4d6b5355d3fe321873479ab Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_user_callSimon Marchi1-22/+32
Change-Id: I9151ce9db9435722b758f41c6606b461bf15f320 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_finish_argumentsSimon Marchi1-22/+28
Change-Id: Id84babed1eeb3ce7d14b94ff332795964e8ead51 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: use proc_with_prefix for ↵Simon Marchi1-1/+1
test_next_with_recursion This one is already in a proc, just make the proc use proc_with_prefix, for consistency. Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_optimized_prologueSimon Marchi1-51/+48
Change-Id: Ibf17033c8ce72aa5cfe1b739be2902e84a5e945d Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_rbreak_shlibSimon Marchi1-18/+18
Change-Id: I130e8914c2713095aab03e84aba1481b4c7af978 Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_file_line_convenience_varSimon Marchi1-6/+8
Change-Id: I0c31b037669b2917e062bf431372fb6531f8f53c Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-24gdb/testsuite/gdb.base/break.exp: split test_break_commands_clearSimon Marchi1-8/+16
Change-Id: Ia58f90117d52fc419fc494836d9b4ed5d902fe9b Approved-By: Kevin Buettner <kevinb@redhat.com>
2022-11-23gdb/arm: Include FType bit in EXC_RETURN pattern on v8mTorbjörn SVENSSON1-6/+13
For v8m, the EXC_RETURN pattern, without security extension, consists of FType, Mode and SPSEL. These are the same bits that are used in v7m. This patch extends the list of patterns to include also the FType bit and not just Mode and SPSEL bits for v8m targets without security extension. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-11-23Document the memory_tagged argument for memory region callbacksLuis Machado3-5/+20
There were no comments in some instances (gdb/defs.h, gdb/core.c and gdb/linux-tdep.c), so address that by adding comments where those are missing.
2022-11-23Fix gdb.cp/gdb2495.exp on powerpc64leTom de Vries1-9/+33
On powerpc64le-linux I ran into this FAIL: ... (gdb) p exceptions.throw_function()^M terminate called after throwing an instance of 'int'^M ^M Program received signal SIGABRT, Aborted.^M 0x00007ffff7979838 in raise () from /lib64/libc.so.6^M The program being debugged was signaled while in a function called from GDB.^M GDB remains in the frame where the signal was received.^M To change this behavior use "set unwindonsignal on".^M Evaluation of the expression containing the function^M (SimpleException::throw_function()) will be abandoned.^M When the function is done executing, GDB will silently stop.^M (gdb) FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception \ without a handler. ... The following happens: - we start an inferior call - an internal breakpoint is set on the global entry point of std::terminate - the inferior call uses the local entry point - the breakpoint is not triggered - we run into std::terminate We can fix this by simply adding the missing gdbarch_skip_entrypoint call in create_std_terminate_master_breakpoint, but we try to do this a bit more generic, by: - adding a variant of function create_internal_breakpoint which takes a minimal symbol instead of an address as argument - in the new function: - using both gdbarch_convert_from_func_ptr_addr and gdbarch_skip_entrypoint - documenting why we don't need to use gdbarch_addr_bits_remove - adding a note about possibly needing gdbarch_deprecated_function_start_offset. - using the new function in: - create_std_terminate_master_breakpoint - create_exception_master_breakpoint_hook, which currently uses only gdbarch_convert_from_func_ptr_addr. Note: we could use the new function in more locations in breakpoint.c, but as we're not aware of any related failures, we declare this out of scope for this patch. Tested on x86_64-linux, powerpc64le-linux. Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com> Tested-by: Carl Love <cel@us.ibm.com> PR tdep/29793 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29793
2022-11-22aarch64-fbsd: Use a static regset for the TLS register set.John Baldwin3-49/+44
This uses custom collect/supply regset handlers which pass the TLS register number from the gdbarch_tdep as the base register number. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-22arm-fbsd: Use a static regset for the TLS register set.John Baldwin3-46/+43
This uses custom collect/supply regset handlers which pass the TLS register number from the gdbarch_tdep as the base register number. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-22fbsd-nat: Pass an optional register base to the register set helpers.John Baldwin2-30/+41
This is needed to permit using the helpers for register sets with a variable base. In particular regnum needs to be converted into a relative register number before passed to regcache_map_supplies. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-22fbsd-nat: Use regset supply/collect methods.John Baldwin1-4/+4
fbsd-nat includes various helper routines for fetching and storing register sets via ptrace where the register set is described by a regset. These helper routines directly invoke the supply/collect_regset regcache methods which doesn't permit a regset to provide custom logic when fetching or storing a register set. Instead, just use the function pointers from the struct regset directly. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-22regcache: Add collect/supply_regset variants that accept a register base.John Baldwin2-10/+37
Some register sets described by an array of regcache_map_entry structures do not have fixed register numbers in their associated architecture but do describe a block of registers whose numbers are at fixed offsets relative to some base register value. An example of this are the TLS register sets for the ARM and AArch64 architectures. Currently OS-specific architectures create register maps and register sets dynamically using the register base number. However, this requires duplicating the code to create the register map and register set. To reduce duplication, add variants of the collect_regset and supply_regset regcache methods which accept a base register number. For valid register map entries (i.e. not REGCACHE_MAP_SKIP), add this base register number to the value from the map entry to determine the final register number. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-22gdb/arm: Fix obvious typo in b0b23e06c3aTorbjörn SVENSSON1-2/+2
As part of the rebase of the patch, I managed to loose the local changes I had for the comments from Tomas in https://sourceware.org/pipermail/gdb-patches/2022-November/193413.html This patch corrects the obvious two typos. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-11-22gdb/testsuite: remove gcc restriction from gdb.dwarf2/clang-cli-macro.expBruno Larsen1-3/+0
With the recent changes to the dwarf assembler, there is no longer a need to test for gcc in gdb.dwarf2/clang-cli-macro.exp and mark it as untested. This commit removes that logic.
2022-11-21When getting the locno of a bpstat, handle the case of bp with null locations.Philippe Waroquiers1-1/+1
The test py-objfile.exp unloads the current file while debugging the process. This results in bpstat bs->b->loc to become nullptr. Handle this case in breakpoint.c:bpstat_locno. Note: GDB crashes on this problem with an internal error, but the end of gdb summary shows: ... === gdb Summary === # of expected passes 36 The output also does not contain a 'FAIL:'. After the fix, the nr of expected passes increased. In the gdb.log output, one can see: ... Fatal signal: Segmentation fault ----- Backtrace ----- 0x55698905c5b9 gdb_internal_backtrace_1 ../../binutils-gdb/gdb/bt-utils.c:122 0x55698905c5b9 _Z22gdb_internal_backtracev ... ERROR: Couldn't send python print(objfile.filename) to GDB. ERROR: : spawn id exp9 not open while executing "expect { -i exp9 -timeout 10 -re ".*A problem internal to GDB has been detected" { fail "$message (GDB internal error)" gdb_internal_error..." ("uplevel" body line 1) invoked from within .... Wondering if it might be possible to improve gdb_test to have gdb_test "python print(objfile.filename)" "None" \ "objfile.filename after objfile is unloaded" reporting a failed result instead of just producing the internal error.
2022-11-21Fix use after free introduced by $_hit_bpnum/$_hit_locno variables.Philippe Waroquiers1-26/+36
If the commands of the bpstat bs contain commands such as step or next or continue, the BS and its commands are freed by execute_control_command. So, we cannot remember the BS that was printed. Instead, remember the bpnum and locno. Regtested on debian/amd64 and re-run a few tests under valgrind.
2022-11-21Fix step-over-syscall.exp matching regexp for $bpnum.$locno matchingPhilippe Waroquiers1-2/+2
step-over-syscall.exp has some specific tests for gdbserver. The regexp matching breakpoint hit must take the added locno into account. Test re-run in 3 modes (normal, native-gdbserver and native-extended-gdbserver).
2022-11-21gdb/arm: Ensure that stack pointers are in syncTorbjörn SVENSSON1-28/+62
For targets with secext, msp and psp can be seen as an alias for one of msp_s, msp_ns, psp_s or psp_ns. Without this patch, sp might be secure, but msp or psp is non-secure (this state can not happen in the hardware). Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-11-21gdb/arm: Update active msp/psp when switching stackTorbjörn SVENSSON1-2/+17
For targets with secext, msp and psp can be seen as an alias for one of msp_s, msp_ns, psp_s or psp_ns. When switching active sp, the corresponding msp/psp needs to be switched too. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-11-21gdb/csky just return type from csky_vector_type() for vector resgistersJiangshuai Li1-4/+7
Some gdb stubs may not describe the type for vector registers in the tdesc-xml and only send bitsize="128", gdb can't deal with a reg with default type int with bitsize==128. So Just return csky_vector_type() for vector resgisters.
2022-11-21gdb/csky return type int32 for float and vector pseudo regsJiangshuai Li1-0/+11
When reg_nr is one of the float and vector pseudo registers, return builtin_type (gdbarch)->builtin_int32 for it.
2022-11-20Fix sol-thread.c compilation on 32-bit SolarisRainer Orth1-10/+10
sol-thread.c fails to compile on 32-bit Solaris: there are several instances of In file included from /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/common-defs.h:203, from /vol/src/gnu/gdb/hg/master/local/gdb/defs.h:28, from /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:51: /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c: In member function ‘virtual void sol_thread_target::resume(ptid_t, int, gdb_signal)’: /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:20: error: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘ULONGEST’ {aka ‘long long unsigned int’} [-Werror=format=] 416 | warning (_("Specified thread %ld seems to have terminated"), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /vol/src/gnu/gdb/hg/master/local/gdb/../gdbsupport/gdb_locale.h:28:29: note: in definition of macro ‘_’ 28 | # define _(String) gettext (String) | ^~~~~~ /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:416:40: note: format string is defined here 416 | warning (_("Specified thread %ld seems to have terminated"), | ~~^ | | | long int | %lld Fixed by using pulongest () instead. Tested on i386-pc-solaris2.11, amd64-pc-solaris2.11, sparc-sun-solaris2.11, and sparcv9-sun-solaris2.11 (together with Simon's patch for PR build/29798).
2022-11-19Add missing gdb_prompt in ctxobj.exp to avoid random failure, fix typo.Philippe Waroquiers2-3/+3
ctxobj.exp fails randomly when computer is loaded. With the addition of $gdb_prompt in the regexp testing for breakpoint hit, I could not make it fail anymore. Also fixed a typo in a comment.
2022-11-19Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum ↵Philippe Waroquiers28-96/+381
$_hit_locno PR breakpoints/12464 This implements the request given in PR breakpoints/12464. Before this patch, when a breakpoint that has multiple locations is reached, GDB printed: Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5 This patch changes the message so that bkpt_print_id prints the precise encountered breakpoint: Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5 In mi mode, bkpt_print_id also (optionally) prints a new table field "locno": locno is printed when the breakpoint hit has more than one location. Note that according to the GDB user manual node 'GDB/MI Development and Front Ends', it is ok to add new fields without changing the MI version. Also, when a breakpoint is reached, the convenience variables $_hit_bpnum and $_hit_locno are set to the encountered breakpoint number and location number. $_hit_bpnum and $_hit_locno can a.o. be used in the command list of a breakpoint, to disable the specific encountered breakpoint, e.g. disable $_hit_bpnum.$_hit_locno In case the breakpoint has only one location, $_hit_locno is set to the value 1, so as to allow a command such as: disable $_hit_bpnum.$_hit_locno to disable the breakpoint even when the breakpoint has only one location. This also fixes a strange behaviour: when a breakpoint X has only one location, enable|disable X.1 is accepted but transforms the breakpoint in a multiple locations breakpoint having only one location. The changes in RFA v4 handle the comments of Tom Tromey: - Changed convenience var names from $bkptno/$locno to $_hit_bpnum/$_hit_locno. - updated the tests and user manual accordingly. User manual also explictly describes that $_hit_locno is set to 1 for a breakpoint with a single location. - The variable values are now set in bpstat_do_actions_1 so that they are set for silent breakpoints, and when several breakpoints are hit at the same time, that the variables are set to the printed breakpoint. The changes in RFA v3 handle the additional comments of Eli: GDB/NEW: - Use max 80-column - Use 'code location' instead of 'location'. - Fix typo $bkpno - Ensure that disable $bkptno and disable $bkptno.$locno have each their explanation inthe example - Reworded the 'breakpoint-hit' paragraph. gdb.texinfo: - Use 'code location' instead of 'location'. - Add a note to clarify the distinction between $bkptno and $bpnum. - Use @kbd instead of examples with only one command. Compared to RFA v1, the changes in v2 handle the comments given by Keith Seitz and Eli Zaretskii: - Use %s for the result of paddress - Use bkptno_numopt_re instead of 2 different -re cases - use C@t{++} - Add index entries for $bkptno and $locno - Added an example for "locno" in the mi interface - Added examples in the Break command manual.
2022-11-18Fix deletion of FinishBreakpointsJohnson Sun4-1/+105
Currently, FinishBreakpoints are set at the return address of a frame based on the `finish' command, and are meant to be temporary breakpoints. However, they are not being cleaned up after use, as reported in PR python/18655. This was happening because the disposition of the breakpoint was not being set correctly. This commit fixes this issue by correctly setting the disposition in the post-stop hook of the breakpoint. It also adds a test to ensure this feature isn't regressed in the future. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18655
2022-11-18gdb: fix symtab.c build on 32 bit targetsSimon Marchi1-4/+4
When building on Ubuntu 22.04, gcc 12, x86-64 with -m32 and -O2, I get: CXX symtab.o /home/smarchi/src/binutils-gdb/gdb/symtab.c: In member function ‘std::vector<symbol_search> global_symbol_searcher::search() const’: /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:44: error: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Werror=format-overflow=] 4961 | sprintf (tmp, "operator%.*s%s", fix, " ", opname); | ^ In file included from /usr/include/stdio.h:894, from ../gnulib/import/stdio.h:43, from /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/common-defs.h:86, from /home/smarchi/src/binutils-gdb/gdb/defs.h:28, from /home/smarchi/src/binutils-gdb/gdb/symtab.c:20: In function ‘int sprintf(char*, const char*, ...)’, inlined from ‘std::vector<symbol_search> global_symbol_searcher::search() const’ at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4961:16: /usr/include/i386-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 9 and 2147483648 bytes into a destination of size 2147483647 38 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 39 | __glibc_objsize (__s), __fmt, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 40 | __va_arg_pack ()); | ~~~~~~~~~~~~~~~~~ PR build/29798 shows a similar error message but on Solaris. Work around that by using string_printf. It is a good thing to get rid of the alloca anyway. Change-Id: Ifbac11fee3062ad7f134d596b4e2229dc5d166f9 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29798
2022-11-18gdb/testsuite: rewrite gdb.cp/call-method-register.exp with dwarf assemblerAndrew Burgess2-76/+80
Convert the gdb.cp/call-method-register.exp test to make use of the DWARF assembler. The existing gdb.cp/call-method-register.exp test relies on a GCC extension - forcing a local variable into a particular named register. This means that the test will only work with Clang, and, as we have to name the register into which the variable will be placed, will only work for those targets where we've selected a suitable register, currently this is x86-64, i386, and ppc64. By switching to the DWARF assembler, the test will work with gcc and clang, and should work on most, if not all, architectures. The test creates a small structure, something that can fit within a register, and then tries to call a method on the structure from within GDB. This should fail because GDB can't take the address of the in register structure (for the `this` pointer). As the test is for a failure case, then we don't really care _which_ register the structure is in, and I take advantage of this for the DWARF assembler test, I just declare that the variable is in DW_OP_reg0, whatever that might be. I've tested the new test on x86-64, ppc, aarch64, and risc-v, and the test runs, and passes on all these architectures, which is already more than we used to cover. Additionally, on x86-64, I've tested with Clang and gcc, and the test runs and passed with both compilers. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: fix gdb.debuginfod/fetch_src_and_symbols.exp with ClangAndrew Burgess2-2/+10
The gdb.debuginfod/fetch_src_and_symbols.exp test is showing a single failure when run with some older versions of Clang, e.g. 9.0.1. The problem appears to be with Clang's generated line table. The test source looks like this: int main() { asm ("main_label: .globl main_label"); return 0; } In GDB, when we 'start', we expect to stop at the 'return 0;' line. This is the behaviour when the compiler is gcc, or later versions of Clang. However, with Clang 9.0.2, I see GDB stop on the 'asm' line. In this commit I'll fix this issue by placing a breakpoint on the return line, and then using gdb_continue_to_breakpoint to ensure we have stopped in the correct place. Of course, using gdb_continue_to_breakpoint will only work if we are not already stopped at the breakpoint location, so I've added some filler work before the 'return 0;' line. With this done we can use gdb_continue_to_breakpoint in all cases. As a result of adding the new filler work, one of the later tests, that used the 'list' command, no longer see the correct expected output (the top line of the source file is no longer included in the output). I've fixed this by listing a known specific line, the test is checking that GDB managed to find the source file, it doesn't matter which source line we list, as long as we can list something.
2022-11-18gdb/testsuite: rename source file gdb.debuginfod/main.cAndrew Burgess2-1/+1
The test gdb.debuginfod/fetch_src_and_symbols.exp uses a source file named main.c. I can't see any particular reason why the file is named as such. Usually test source files are named after the test script. This commit just renames the source file inline with the test script, and updates the call to standard_testfile (removing the reference to main.c). There's no particular reason for this change other than seeing the file named main.c made me thing that the source file must be shared with some other test (it isn't). There should be no change in what is tested after this commit.
2022-11-18gdb/testsuite: add (and use) a new build-id compile optionAndrew Burgess2-2/+11
I noticed that the gdb.debuginfod/fetch_src_and_symbols.exp test was failing when run with Clang as the compiler. This test relies on the compiled binaries having a build-id within them. For GCC, really GNU ld, the default is to always include a build-id. When compiling with Clang though, the default is for no build-id. I did consider *always* turning on the build-id feature when the compiler is Clang, but that felt a little weird. Instead, I propose that we add a new 'build-id' compiler option to gdb_compile, this flag indicates that the test _requires_ a build-id. In gcc_compile we can then add the required flags if the compiler is Clang so that we do get a build-id. With this change the gdb.debuginfod/fetch_src_and_symbols.exp test now (mostly) passes with Clang 9.0.1 and 15.0.2, and still passes with gcc. The 'mostly' part is an unrelated issue, and will be addressed in a later commit in this series. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: fix gdb.compile/compile-ops.exp with clangAndrew Burgess2-11/+15
I noticed that the gdb.compile/compile-ops.exp test was failing when run with Clang as the compiler. This test makes use of the DWARF assembler, and, it turns out, uses a technique which is not portable to Clang. This problem is described in the comment on the function_range proc in lib/dwarf.exp, the explanation is: # If the compiler is gcc, we can do the following to get function start # and end address too: # # asm ("func_start: .globl func_start"); # static void func (void) {} # asm ("func_end: .globl func_end"); # # however, this isn't portable, because other compilers, such as clang, # may not guarantee the order of global asms and function. The code # becomes: # # asm ("func_start: .globl func_start"); # asm ("func_end: .globl func_end"); # static void func (void) {} These start/end labels are used for computing the function start, end, and length. The portable solution is to place a label within the function, like this: # int main (void) # { # asm ("main_label: .globl main_label"); # return 0; # } And make use of 'proc function_range' (from lib/dwarf.exp). So, that's what I do in this commit. One consequence of this change is that we need to compile the source file, and have it loaded into a GDB session, before calling function_range, so I've added an early call to prepare_for_testing. Additionally, this test script was generating the DWARF assembler into a file called gdbjit-ops.S, I suspect a copy and paste issue there, so I've switched this to use compile-ops-dbg.S instead, which is more inline with what other DWARF assembler tests do. The only other change, which might be a problem, is that I also deleted these two lines from the source file: asm (".section \".text\""); asm (".balign 8"); These lines were setting the alignment of the .text section. What I don't know is whether this was significant or not. If it is significant, then I can't see why. On x86-64, the test still passes fine without these lines, but that doesn't mean the test wont start failing on some other architecture. Still, I figure, lets remove them, then, if/when we find a test that starts failing, we can add the lines back, along with an explanation for why the extra alignment is required. But, if people would prefer to be more conservative, then I'm happy to just add the lines back. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: fix gdb.trace/unavailable-dwarf-piece.exp with ClangAndrew Burgess1-2/+2
I noticed that the test gdb.trace/unavailable-dwarf-piece.exp was failing when run with Clang. Or rather, the test was not running as the test executable failed to compile. The problem is that Clang was emitting this warning: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] This warning is emitted when compiling the assembler file generated by the DWARF assembler. Most DWARF assembler tests generate the assembler file into a file with the '.S' extension. However, this particular test uses a '.s' extension. Now a .S file will be passed through the preprocessor, while a .s will be sent straight to the assembler. My guess is that Clang doesn't support the -fdiagnostics-color=never option for the assembler, but does for the preprocessor. That's a little annoying, but easily worked around. We don't care if our assembler file is passed through the preprocessor, so, in this commit, I just change the file extension from .s to .S, and the problem is fixed. Currently, the unavailable-dwarf-piece.exp script names the assembler file using standard_output_file, in this commit I've switched to make use of standard_testfile, as that seems to be the more common way of doing this sort of thing. With these changes the test now passes with Clang 9.0.1 and 15.0.2, and also still passes with gcc. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-18gdb/testsuite: don't avoid DWARF assembler tests with ClangAndrew Burgess2-11/+0
Two tests make the claim that the DWARF assembler requires gcc, however, this isn't true. I think at one point, when the DWARF assembler was first added, we did use some techniques that were not portable (see the comments in lib/dwarf.exp on function_range for details), however, I think most DWARF assembler tests will now work fine with Clang. The two tests that I modify in this commit both work fine with Clang, at least, I've tested with Clang 9.0.1 and 15.0.2, and don't see any problems, so I'm removing the early return logic that stops these tests from running with Clang. Reviewed-By: Lancelot SIX <lancelot.six@amd.com>
2022-11-17Fix static initialization order problem in windows-nat.cTom Tromey1-3/+6
This patch fixes a static initialization order problem in windows-nat.c that was pointed out by Jon Turney. The underlying problem is that the windows_nat_target constructor relies on serial_logfile already being constructed, but this is not enforced by C++ rules. This patch fixes the problem by initializing the global windows_nat_target later.
2022-11-17PowerPC, fix gdb.base/retval-large-struct.expCarl Love1-1/+7
Support for printining non-trivial return values was recently added in commit: commit a0eda3df5b750ae32576a9be092b361281a41787 Author: Carl Love <cel@us.ibm.com> Date: Mon Nov 14 16:22:37 2022 -0500 PowerPC, fix support for printing the function return value for non-trivial values. The functionality can now be used to fix gdb.base/retval-large-struct.exp. The test just needs to be compiled with -fvar-tracking to enable GDB to determine the address off the return buffer when the function is called. The current output from the test: 34 return big_struct; (gdb) PASS: gdb.base/retval-large-struct.exp: continue to breakpoint: Break in print_large_struct finish warning: Cannot determine the function return value. Try compiling with -fvar-tracking. Run till exit from #0 return_large_struct () at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:34 main (argc=1, argv=0x7fffffffcd58) at binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.c:44 44 return 0; Value returned has type: struct big_struct_t. Cannot determine contents (gdb) FAIL: gdb.base/retval-large-struct.exp: finish from return_large_struct testcase binutils-gdb-current/gdb/testsuite/gdb.base/retval-large-struct.exp completed in 1 seconds This patch adds the command line argument -fvar-tracking to enable gdb to determine the return vaule and thus fixing the test. Patch tested on Power 10 with no regressions.
generated by cgit v1.1 at 2025-09-20 16:29:09 +0000