aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-01-09Automatic date update in version.inGDB Administrator1-1/+1
2023-01-08Automatic date update in version.inGDB Administrator1-1/+1
2023-01-07Automatic date update in version.inGDB Administrator1-1/+1
2023-01-06Automatic date update in version.inGDB Administrator1-1/+1
2023-01-05Automatic date update in version.inGDB Administrator1-1/+1
2023-01-04Automatic date update in version.inGDB Administrator1-1/+1
2023-01-03[gdb] Fix segfault during inferior call to ifuncAndrew Burgess2-2/+10
With a simple test-case: ... $ cat test.c char *p = "a"; int main (void) { return strlen (p); } $ gcc -g test.c ... we run into this segfault: ... $ gdb -q -batch a.out -ex start -ex "p strlen (p)" Temporary breakpoint 1 at 0x1151: file test.c, line 4. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Temporary breakpoint 1, main () at test.c:4 4 return strlen (p); Fatal signal: Segmentation fault ... The strlen is an ifunc, and consequently during the call to call_function_by_hand_dummy for "p strlen (p)" another call to call_function_by_hand_dummy is used to resolve the ifunc. This invalidates the get_current_frame () result in the outer call. Fix this by using prepare_reinflate and reinflate. Note that this series ( https://inbox.sourceware.org/gdb-patches/20221214033441.499512-1-simon.marchi@polymtl.ca/ ) should address this problem, but this patch is a simpler fix which is easy to backport. Tested on x86_64-linux. Co-Authored-By: Tom de Vries <tdevries@suse.de> PR gdb/29941 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29941
2023-01-03Automatic date update in version.inGDB Administrator1-1/+1
2023-01-02Fix target remote pipe command for MinGWJonas Hoerberg1-0/+6
The cced7cacecad104fff0 ("gdb: preserve `|` in connection details string") commit added '|' detection and removal to ser-pipe.c, but missed to add it to ser-mingw.c. This results in the error message below for MinGW hosts: error starting child process '| <executable> <args>': CreateProcess: No such file or directory This commit add the missing '|' detection and removal to ser-mingw.c. (cherry picked from commit c43d829bca5e45c5e6c0255a549abc5766f6de7f)
2023-01-02Automatic date update in version.inGDB Administrator1-1/+1
2023-01-01manual copyright year range of various GDB files to add 2023Joel Brobecker3-5/+5
This commit updates the following file... gdb/doc/gdb.texinfo gdb/doc/refcard.tex gdb/syscalls/update-netbsd.sh ... by hand as instructed by the gdb/copyright.py script. The update by hand is needed because the copyright headers to update are actually nested inside those files, rather than located at the start of the file. (cherry picked from commit 944bfb2ccb564803279f41019e75c62d7ec8e5af)
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker7052-7052/+7052
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2023-01-01gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions...Joel Brobecker1-1/+1
... to sim/ppc/powerpc.igen This file is in the NOT_FSF_LIST because this file has a copyright which is not assigned to the FSF. Since the file got renamed, the corresponding entry in NOT_FSF_LIST needs to be renamed as well. (cherry picked from commit e4661570ead7be521c9d693f188b0944d7b8c78c)
2023-01-01Update copyright year in help message of gdb, gdbserver, gdbreplayJoel Brobecker3-6/+6
This commit updates the copyright year displayed by gdb, gdbserver and gdbreplay's help message from 2022 to 2023, as per our Start of New Year procedure. The corresponding source files' copyright header are also updated accordingly. (cherry picked from commit e1ca55341ca328b2343ecc5cb78699fdbd1caa22)
2023-01-01Automatic date update in version.inGDB Administrator1-1/+1
2022-12-31Automatic date update in version.inGDB Administrator1-1/+1
2022-12-30Automatic date update in version.inGDB Administrator1-1/+1
2022-12-29Automatic date update in version.inGDB Administrator1-1/+1
2022-12-28Fix "set debug timestamp"Tom Tromey2-1/+25
PR cli/29945 points out that "set debug timestamp 1" stopped working -- this is a regression due to commit b8043d27 ("Remove a ui-related memory leak"). This patch fixes the bug and adds a regression test. I think this should probably be backported to the gdb 13 branch. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29945 (cherry picked from commit a60535c39ba52d88c47740db6ab116db32e2331a)
2022-12-28Automatic date update in version.inGDB Administrator1-1/+1
2022-12-27Automatic date update in version.inGDB Administrator1-1/+1
2022-12-26Automatic date update in version.inGDB Administrator1-1/+1
2022-12-25Automatic date update in version.inGDB Administrator1-1/+1
2022-12-24Automatic date update in version.inGDB Administrator1-1/+1
2022-12-23Automatic date update in version.inGDB Administrator1-1/+1
2022-12-22Fix MinGW build using mingw.org's MinGWEli Zaretskii1-1/+5
This allows to build GDB even though the default value of _WIN32_WINNT is lower than the one needed to expose some new APIs used here, and leave the test for their actual support to run time. * gdb/nat/windows-nat.c (EXTENDED_STARTUPINFO_PRESENT): Define if not defined. (create_process_wrapper): Use 'gdb_lpproc_thread_attribute_list' instead of 'PPROC_THREAD_ATTRIBUTE_LIST' (which might not be defined at compile time). This fixes compilation error using mingw.org's MinGW.
2022-12-22PR29915, bfdio.c does not compile with mingw.org's MinGWAlan Modra4-6/+22
PR 29915 * configure.ac: Add AC_CHECK_DECLS test ___lc_codepage_func. * configure: Regenerate. * config.in: Regenerate. * bfdio.c (___lc_codepage_func): Move declaration to.. (_bfd_real_fopen): ..here, and use !HAVE_DECL____LC_CODEPAGE_FUNC. (cherry picked from commit 9d0991449285833b9a77cc02850a1e113e460362)
2022-12-22Automatic date update in version.inGDB Administrator1-1/+1
2022-12-21Automatic date update in version.inGDB Administrator1-1/+1
2022-12-20Fix install-strip targetHannes Domani1-2/+2
The libtool patch broke install-strip of gdb: /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb transformed_name=`t='s,y,y,'; \ echo gdb | sed -e "$t"` ; \ if test "x$transformed_name" = x; then \ transformed_name=gdb ; \ else \ true ; \ fi ; \ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \ /bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \ gdb \ /src/gdb/inst/bin/$transformed_name ; \ /bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \ /usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h libtool: install: `/src/gdb/inst/bin/gdb' is not a directory libtool: install: Try `libtool --help --mode=install' for more information. Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the gdb executable is not installed with install-strip.
2022-12-20gdb: fix command lookup in execute_command ()Jan Vrany1-6/+2
Commit b5661ff2 ("gdb: fix possible use-after-free when executing commands") used lookup_cmd_exact () to lookup command again after its execution to avoid possible use-after-free error. However this change broke test gdb.base/define.exp which defines a post-hook for subcommand ("target testsuite"). In this case, lookup_cmd_exact () returned NULL because there's no command 'testsuite' in top-level commands. This commit fixes this case by looking up the command again using the original command line via lookup_cmd (). Approved-By: Simon Marchi <simon.marchi@efficios.com> (cherry picked from commit 37e5833da583310268dc1b04fc6839e81b987897)
2022-12-20Automatic date update in version.inGDB Administrator1-1/+1
2022-12-19Automatic date update in version.inGDB Administrator1-1/+1
2022-12-18Set development mode to "off" by default.Joel Brobecker1-1/+1
This is done by setting the "development" variable to "false" in bfd/development.sh.
2022-12-18Bump version to 13.0.90.DATE-git.Joel Brobecker1-1/+1
Now that the GDB 13 branch has been created, this commit bumps the version number in gdb/version.in to 13.0.90.DATE-git For the record, the GDB 13 branch was created from commit 71c90666e601c511a5f495827ca9ba545e4cb463.
2022-12-18Automatic date update in version.ingdb-13-branchpointGDB Administrator1-1/+1
2022-12-17bfd_get_relocated_section_contents allow NULL data bufferAlan Modra18-51/+143
This patch removes the bfd_malloc in default_indirect_link_order and bfd_simple_get_relocated_section_contents, pushing the allocation down to bfd_get_relocated_section_contents. The idea is to make use of the allocation done with sanity checking in bfd_get_full_section_contents, which is called by bfd_generic_get_relocated_section_contents. Doing this exposed a bug in bfd_get_full_section_contents. With relaxation it is possible that an input section rawsize is different to the section size. In that case we want to use the larger of rawsize (the on-disk size for input sections) and size. * reloc.c (bfd_generic_get_relocated_section_contents), * reloc16.c (bfd_coff_reloc16_get_relocated_section_contents), * coff-alpha.c (alpha_ecoff_get_relocated_section_contents), * coff-sh.c (sh_coff_get_relocated_section_contents), * elf-m10200.c (mn10200_elf_get_relocated_section_contents), * elf-m10300.c (mn10300_elf_get_relocated_section_contents), * elf32-avr.c (elf32_avr_get_relocated_section_contents), * elf32-cr16.c (elf32_cr16_get_relocated_section_contents), * elf32-crx.c (elf32_crx_get_relocated_section_contents), * elf32-h8300.c (elf32_h8_get_relocated_section_contents), * elf32-nds32.c (nds32_elf_get_relocated_section_contents), * elf32-sh.c (sh_elf_get_relocated_section_contents), * elfxx-mips.c (_bfd_elf_mips_get_relocated_section_contents): Handle NULL data buffer. * bfd.c (bfd_get_section_alloc_size): New function. * bfd-in2.h: Regenerate. * compress.c (bfd_get_full_section_contents): Correct section malloc size. * linker.c (default_indirect_link_order): Don't malloc memory here before calling bfd_get_relocated_section_contents. * simple.c (bfd_simple_get_relocated_section_contents): Likewise.
2022-12-17asan: elf.c:12621:18: applying zero offset to null pointerAlan Modra1-1/+1
That's this line in elf_parse_notes: while (p < buf + size) * elf.c (_bfd_elf_make_section_from_shdr): Don't call elf_parse_notes when sh_size is zero.
2022-12-17Re: The problem with warning in elf_object_pAlan Modra9-75/+279
Commit 5aa0f10c424e added a per_xvec_warn array to provide support for warnings from elf_object_p (and a later patch for warnings from pe_bfd_object_p) to be cached and then only printed if the target matches. It was quite limited in the style of message supported, only one message could be printed, and didn't really meet the stated aim of only warning when a target matches: There are many other errors and warnings that can be emitted by functions called from elf_object_p. So this patch extends the error handler functions to support printing to a string buffer, extends per_xvec_warn to support multiple errors/ warnings, and hooks this all into bfd_check_format_matches. If bfd_check_format_matches succeeds then any errors/warnings are printed for the matching target. If bfd_check_format_matches fails either due to no match or to multiple matches and only one target vector produced errors, then those errors are printed. * bfd.c (MAX_ARGS): Define, use throughout. (print_func): New typedef. (_bfd_doprnt): Add new print param. Replace calls to fprintf with print. (PRINT_TYPE): Similarly. (error_handler_fprintf): Renamed from error_handler_internal. Use _bfd_get_error_program_name. Add fprintf arg. Move code setting up args.. (_bfd_doprnt_scan): ..to here. Add ap param. (struct buf_stream): New. (err_sprintf): New function. (error_handler_bfd): New static variable. (error_handler_sprintf): New function. (_bfd_set_error_handler_caching): New function. (_bfd_get_error_program_name): New function. * elfcode.h (elf_swap_shdr_in): Use _bfd_error_handler in warning messages. (elf_object_p): Likewise. * format.c (print_warnmsg): New function. (clear_warnmsg): Rewrite. (null_error_handler): New function. (bfd_check_format_matches): Ignore warnings from recursive calls checking first element of an archive. Use caching error handler otherwise. Print warnings on successful match, or when only one target has emitted warnings/errors. * peicode.h (pe_bfd_object_p): Use _bfd_error_handler in warning messages. * targets.c (per_xvec_warn): Change type of array elements. (struct per_xvec_message): New. (_bfd_per_xvec_warn): Rewrite. * Makefile.am (LIBBFD_H_FILES): Add bfd.c. * Makefile.in: Regenerate. * bfd-in2.h: Regenerate. * libbfd.h: Regenerate.
2022-12-16sframe: doc: update spec for the mangled-RA bit in FREIndu Bhagat1-2/+2
ChangeLog: * libsframe/doc/sframe-spec.texi
2022-12-16gas: sframe: testsuite: add testcase for .cfi_negate_ra_stateIndu Bhagat3-0/+39
Add a new test to check that .cfi_negate_ra_state on aarch64 is handled well (a non-empty SFrame section with valid SFrame FREs is generated). ChangeLog: * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.d: New test. * testsuite/gas/cfi-sframe/cfi-sframe-aarch64-2.s: Likewise. * testsuite/gas/cfi-sframe/cfi-sframe.exp: Adjust the list accordingly.
2022-12-16objdump/readelf: sframe: emit marker for FREs with mangled RAIndu Bhagat1-2/+9
In the textual dump of the SFrame section, when an SFrame FRE recovers a mangled RA, use string "[s]" in the output to indicate that the return address is a signed (mangled) one. ChangeLog: * libsframe/sframe-dump.c (dump_sframe_func_with_fres): Postfix with "[s]" if RA is signed with authorization code.
2022-12-16libsframe: provide new access API for mangled RA bitIndu Bhagat2-0/+25
include/ChangeLog: * sframe-api.h (sframe_fre_get_ra_mangled_p): New declaration. ChangeLog: * libsframe/sframe.c (sframe_get_fre_ra_mangled_p): New definition. (sframe_fre_get_ra_mangled_p): New static function.
2022-12-16gas: sframe: add support for .cfi_negate_ra_stateIndu Bhagat5-41/+39
DW_CFA_AARCH64_negate_ra_state in aarch64 is multiplexed with DW_CFA_GNU_window_save in the DWARF format. Remove the common-empty-4 testcase because the generated SFrame section will not be be empty anymore. A relevant test will be added in a later commit. ChangeLog: * gas/gen-sframe.c (sframe_v1_set_fre_info): Add new argument for mangled_ra_p. (sframe_set_fre_info): Likewise. (output_sframe_row_entry): Handle mangled_ra_p. (sframe_row_entry_new): Reset mangled_ra_p. (sframe_row_entry_initialize): Initialize mangled_ra_p. (sframe_xlate_do_gnu_window_save): New definition. (sframe_do_cfi_insn): Handle DW_CFA_GNU_window_save. * gas/gen-sframe.h (struct sframe_row_entry): New member. (struct sframe_version_ops): Add a new argument for mangled_ra_p. * gas/testsuite/gas/cfi-sframe/cfi-sframe.exp: Remove test. * gas/testsuite/gas/cfi-sframe/common-empty-4.d: Removed. * gas/testsuite/gas/cfi-sframe/common-empty-4.s: Removed.
2022-12-16sframe.h: add support for .cfi_negate_ra_stateIndu Bhagat1-8/+15
Use the last remaining bit in the 'SFrame FRE info' word to store whether the RA is signed/unsigned with PAC authorization code: this bit is named as the "mangled RA" bit. This bit is still unused for x86-64. The behaviour of the mangled-RA info bit in SFrame format closely follows the behaviour of DW_CFA_AARCH64_negate_ra_state in DWARF. During unwinding, whenever an SFrame FRE with non-zero "mangled RA" bit is encountered, it means the upper bits of the return address contain Pointer Authentication code. The unwinder, hence, must use appropriate means to restore LR correctly in such cases. include/ChangeLog: * sframe.h (SFRAME_V1_FRE_INFO_UPDATE_MANGLED_RA_P): New macro. (SFRAME_V1_FRE_MANGLED_RA_P): Likewise.
2022-12-17Automatic date update in version.inGDB Administrator1-1/+1
2022-12-16Delay checking whether /proc/pid/mem is writable (PR gdb/29907)Pedro Alves1-3/+6
As of 1bcb0708f229 ("gdb/linux-nat: Check whether /proc/pid/mem is writable"), GDB checks if /proc/pid/mem is writable. This is done early at GDB startup, in order to get a consistent warning, instead of a warning that depends on whenever GDB writes to inferior memory. PR gdb/29907 points out that some build systems (like QEMU's, apparently) may call 'gdb --version' to check GDB's presence & its version on the system, and that Gentoo's build process has sandboxing which blocks the /proc/pid/mem access and thus GDB warns, which results in build fails. To help with that, this patch delays the /proc/pid/mem check until we start or attach to an inferior. Ends up potentially emiting a warning close where we already emit other ptrace- and /proc- related warnings, which just Feels Right. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29907 Change-Id: I5537653ecfbbe76a04ab035e40e59d09b4980763
2022-12-16Fix previous delta to allow for compilation on 32-bit systemsNick Clifton5-3/+60
2022-12-16[gdb/testsuite] Fix race in gdb.threads/detach-step-over.expTom de Vries1-8/+26
Once in a while I run into: ... FAIL: gdb.threads/detach-step-over.exp: \ breakpoint-condition-evaluation=host: target-non-stop=off: non-stop=off: \ displaced=off: iter 1: all threads running ... In can easily reproduce this by doing: ... # Wait a bit, to give time for the threads to hit the # breakpoint. - sleep 1 return true ... Fix this by counting the running threads in a loop, effectively allowing 10 seconds (instead of 1) for the threads to start running, but only sleeping if needed. Reduces total execution time from 1m27s to 56s. Tested on x86_64-linux.
2022-12-16gdb: fix crash when getting the value of a label symbolAndrew Burgess3-14/+103
When the source program contains a goto label, it turns out it's actually pretty hard for a user to find out more about that label. For example: (gdb) p some_label No symbol "some_label" in current context. (gdb) disassemble some_label No symbol "some_label" in current context. (gdb) x/10i some_label No symbol "some_label" in current context. (gdb) break some_label Breakpoint 2 at 0x401135: file /tmp/py-label-symbol-value.c, line 35. In all cases, some_label is a goto label within the current frame. Only placing a breakpoint on the label worked. This all seems a little strange to me, it feels like asking about a goto label would not be an unreasonable thing for a user to do. This commit doesn't fix any of the above issues, I mention them just to provide a little context for why the following issue has probably not been seen before. It turns out there is one way a user can access the symbol for a goto label, through the Python API: python frame = gdb.selected_frame() python frame_pc = frame.pc() python block = gdb.current_progspace().block_for_pc(frame_pc) python symbol,_ = gdb.lookup_symbol('some_label', block, gdb.SYMBOL_LABEL_DOMAIN) python print(str(symbol.value())) ../../src/gdb/findvar.c:204: internal-error: store_typed_address: Assertion `type->is_pointer_or_reference ()' failed. The problem is that label symbols are created using the builtin_core_addr type, which is a pure integer type. When GDB tries to fetch the value of a label symbol then we end up in findvar.c, in the function language_defn::read_var_value, in the LOC_LABEL case. From here store_typed_address is called to store the address of the label into a value object with builtin_core_addr type. The problem is that store_typed_address requires that the destination type be a pointer or reference, which the builtin_core_addr type is not. Now it's not clear what type a goto label address should have, but GCC has an extension that allows users to take the address of a goto label (using &&), in that case the result is of type 'void *'. I propose that when we convert the CORE_ADDR value to a GDB value object, we use builtin_func_ptr type instead of builtin_core_addr, this means the result will be of type 'void (*) ()'. The benefit of this approach is that when gdbarch_address_to_pointer is called the target type will be correctly identified as a pointer to code, which should mean any architecture specific adjustments are done correctly. We can then cast the new value to 'void *' type with a call to value_cast_pointer, this should not change the values bit representation, but will just update the type. After this asking for the value of a label symbol works just fine: (gdb) python print(str(symbol.value())) 0x401135 <main+35> And the type is maybe what we'd expect: (gdb) python print(str(symbol.value().type)) void *