binutils-gdb

Commit Graph

Author	SHA1	Message	Date
John Baldwin	5046f3c8c0	FreeBSD x86: Remove fallback for detecting signal trampolines by address. A few FreeBSD releases did not include the page holding the signal code in core dumps. As a workaround, a sysctl was used to fetch the default location of the signal code instead. The youngest affected FreeBSD release is 10.1 released in November 2014 and EOLed in December 2016. The fallback only works for native processes and would require a separate unwinder once the FreeBSD arches are converted to use tramp_frame for signal frames.	4 years ago
John Baldwin	bf84b776bd	Remove support for pre-5.0 FreeBSD/i386 signal trampolines. The last relevant release (FreeBSD 4.11) was released in January of 2005.	4 years ago
John Baldwin	187365caaa	Remove vestigal FreeBSD/i386 3.x support. This was orphaned when a.out support was removed as the FreeBSD/i386 ELF support always used the register layouts from 4.0+.	4 years ago
Bruno Larsen	5647d3e3dc	Add Bruno Larsen to gdb/MAINTAINERS	4 years ago
Enze Li	12735d3472	gdb/build: Fix Wpessimizing-move in clang build When building with clang, I run into an error: ... tui/tui-disasm.c:138:25: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move] tal.addr_string = std::move (gdb_dis_out.release ()); ^ tui/tui-disasm.c:138:25: note: remove std::move call here tal.addr_string = std::move (gdb_dis_out.release ()); ^~~~~~~~~~~ ~ ... The error above is caused by the recent commit `5d10a2041e` ("gdb: add string_file::release method"). Fix this by removing std::move. Build on x86_64-linux with clang 13.0.0.	4 years ago
Simon Marchi	459140adc0	Add top-level .editorconfig file Add a .editorconfig [1] file. This helps configure editors automatically with the right whitespace settings. It will help me, since I need to juggle with different whitespace settings for different projects. But I think it can also help newcomers get things right from the start. Some editors have native support for reading these files, while others require a plug-in [2]. And if you don't want to use it, then this file doesn't change anything to your life. I added rules for the kinds of files I edit most often, but more can be added later. I assumed that the rules were the same for GDB and the other projects, but if that's not the case, we can always put .editorconfig files in project subdirectories to override settings. [1] https://editorconfig.org/ [2] https://editorconfig.org/#download Change-Id: Ifda136d13877fafcf0d137fec8501f6a34e1367b	4 years ago
Nick Clifton	2f49159cfb	Updated French translation for the gas sub-directory.	4 years ago
Alan Modra	5617fae703	Set __ehdr_start rel_from_abs earlier This is just a tidy, making the __ehdr_start symbol flag tweaks all in one place. * ldelf.c (ldelf_before_allocation): Don't set rel_from_abs for __ehdr_start. * ldlang.c (lang_symbol_tweaks): Set it here instead.	4 years ago
Alan Modra	1004091634	PowerPC64 handling of @tocbase * elf64-ppc.c (ppc64_elf_relocate_section): Warn if the symbol on R_PPC64_TOC isn't local.	4 years ago
Alan Modra	ef5684c2bd	Update PowerPC64 symtocbase test Using a symbol other than .TOC. with @tocbase is an extension to the ABI. It is never valid to use a symbol without a definition in the binary, and symbols on these expressions cannot be overridden. Make this explicit by using ".hidden" in the testcase. * testsuite/ld-powerpc/symtocbase-1.s: Align data. Make function entry symbol hidden. * testsuite/ld-powerpc/symtocbase-2.s: Likewise. * testsuite/ld-powerpc/symtocbase.d: Adjust expected output.	4 years ago
Alan Modra	0441f94fba	PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu The assertion is this one in ppc_build_one_stub BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size); It is checking that a stub doesn't overwrite the tail of a previous stub, so not something trivial. Normally, stub sizing iterates until no stubs are added, detected by no change in stub section size. Iteration also continues if no stubs are added but one or more stubs increases in size, which also can be detected by a change in stub section size. But there is a pathological case where stub section sizing decreases one iteration then increases the next. To handle that situation, stub sizing also stops at more than STUB_SHRINK_ITER (20) iterations when calculated stub section size is smaller. The previous larger size is kept for the actual layout (so that building the stubs, which behaves like another iteration of stub sizing, will see the stub section sizes shrink). The problem with that stopping condition is that it assumes that stub sizing is only affected by addresses external to the stub sections, which isn't always true. This patch fixes that by also keeping larger individual stub_offset addresses past STUB_SHRINK_ITER. It also catches a further pathological case where one stub shrinks and another expands in such a way that no stub section size change is seen. PR 28827 * elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed. (STUB_SHRINK_ITER): Move earlier in file. (ppc_size_one_stub): Detect any change in stub_offset. Keep larger one if past STUB_SHRINK_ITER. (ppc64_elf_size_stubs): Iterate on stub_changed too.	4 years ago
Alan Modra	07c9f243b3	PR28826 x86_64 ld segfaults building xen Fallout from commit `e86fc4a5bc` PR 28826 * coffgen.c (coff_write_alien_symbol): Init dummy to zeros.	4 years ago
Alan Modra	085b299b71	PR28753, buffer overflow in read_section_stabs_debugging_info PR 28753 * rddbg.c (read_section_stabs_debugging_info): Don't read past end of section when concatentating stab strings.	4 years ago
GDB Administrator	1f01799f55	Automatic date update in version.in	4 years ago
Simon Marchi	dfa1952ee8	gdb: work around negative DW_AT_data_member_location GCC 11 bug g++ 11.1.0 has a bug where it will emit a negative DW_AT_data_member_location in some cases: $ cat test.cpp #include <memory> int main() { std::unique_ptr<int> ptr; } $ g++ -g test.cpp $ llvm-dwarfdump -F a.out ... 0x00000964: DW_TAG_member DW_AT_name [DW_FORM_strp] ("_M_head_impl") DW_AT_decl_file [DW_FORM_data1] ("/usr/include/c++/11.1.0/tuple") DW_AT_decl_line [DW_FORM_data1] (125) DW_AT_decl_column [DW_FORM_data1] (0x27) DW_AT_type [DW_FORM_ref4] (0x0000067a "default_delete<int>") DW_AT_data_member_location [DW_FORM_sdata] (-1) ... This leads to a GDB crash (when built with ASan, otherwise probably garbage results), since it tries to read just before (to the left, in ASan speak) of the value's buffer: ==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18 READ of size 1 at 0x6020000c52af thread T0 #0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827 #1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347 #2 0x555c497909cd in value_primitive_field(value, long, int, type) /home/simark/src/binutils-gdb/gdb/value.c:3126 #3 0x555c478f2eaa in cp_print_value_fields(value, ui_file, int, value_print_options const, type, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333 #4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #5 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #7 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #9 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 #11 0x555c4760df4c in c_value_print_inner(value, ui_file, int, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 #12 0x555c483ff9a7 in language_defn::value_print_inner(value, ui_file, int, value_print_options const) const /home/simark/src/binutils-gdb/gdb/language.c:632 #13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 #14 0x555c49759b17 in common_val_print(value, ui_file, int, value_print_options const, language_defn const) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 #15 0x555c478f2fcb in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 #16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #17 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 #19 0x555c4760df4c in c_value_print_inner(value, ui_file, int, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 #20 0x555c483ff9a7 in language_defn::value_print_inner(value, ui_file, int, value_print_options const) const /home/simark/src/binutils-gdb/gdb/language.c:632 #21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 #22 0x555c49759b17 in common_val_print(value, ui_file, int, value_print_options const, language_defn const) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 #23 0x555c478f2fcb in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 #24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 #25 0x555c4760df4c in c_value_print_inner(value, ui_file, int, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 #26 0x555c483ff9a7 in language_defn::value_print_inner(value, ui_file, int, value_print_options const) const /home/simark/src/binutils-gdb/gdb/language.c:632 #27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 #28 0x555c49759b17 in common_val_print(value, ui_file, int, value_print_options const, language_defn const) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 #29 0x555c4760f04c in c_value_print(value, ui_file, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587 #30 0x555c483ff954 in language_defn::value_print(value, ui_file, value_print_options const) const /home/simark/src/binutils-gdb/gdb/language.c:614 #31 0x555c49759f61 in value_print(value, ui_file, value_print_options const) /home/simark/src/binutils-gdb/gdb/valprint.c:1189 #32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337 #33 0x555c48958eda in print_value(value, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258 #34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367 #35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458 #36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97 #37 0x555c47692e25 in cmd_func(cmd_list_element, char const, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475 #38 0x555c4936107e in execute_command(char const, int) /home/simark/src/binutils-gdb/gdb/top.c:670 #39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523 #40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618 #41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317 #42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338 #43 0x555c485f6d65 in gdb_main(captured_main_args) /home/simark/src/binutils-gdb/gdb/main.c:1363 #44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32 #45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24) #46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d) 0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8) allocated by thread T0 here: #0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154 #1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100 #2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29 #3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029 #4 0x555c4977be25 in allocate_value(type) /home/simark/src/binutils-gdb/gdb/value.c:1040 #5 0x555c4979030d in value_primitive_field(value, long, int, type) /home/simark/src/binutils-gdb/gdb/value.c:3092 #6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501 #7 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #9 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #11 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 #13 0x555c4760df4c in c_value_print_inner(value, ui_file, int, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 #14 0x555c483ff9a7 in language_defn::value_print_inner(value, ui_file, int, value_print_options const) const /home/simark/src/binutils-gdb/gdb/language.c:632 #15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 #16 0x555c49759b17 in common_val_print(value, ui_file, int, value_print_options const, language_defn const) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 #17 0x555c478f2fcb in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 #18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513 #19 0x555c478f02ca in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161 #20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 #21 0x555c4760df4c in c_value_print_inner(value, ui_file, int, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 #22 0x555c483ff9a7 in language_defn::value_print_inner(value, ui_file, int, value_print_options const) const /home/simark/src/binutils-gdb/gdb/language.c:632 #23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 #24 0x555c49759b17 in common_val_print(value, ui_file, int, value_print_options const, language_defn const) /home/simark/src/binutils-gdb/gdb/valprint.c:1151 #25 0x555c478f2fcb in cp_print_value_fields(value, ui_file, int, value_print_options const, type*, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335 #26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383 #27 0x555c4760df4c in c_value_print_inner(value, ui_file, int, value_print_options const) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438 #28 0x555c483ff9a7 in language_defn::value_print_inner(value, ui_file, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632 #29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048 Since there are some binaries with this in the wild, I think it would be useful for GDB to work around this. I did the obvious simple thing, if the DW_AT_data_member_location's value is -1, replace it with 0. I added a producer check to only apply this fixup for GCC 11. The idea is that if some other compiler ever uses a DW_AT_data_member_location value of -1 by mistake, we don't know (before analyzing the bug at least) if they did mean 0 or some other value. So I wouldn't want to apply the fixup in that case. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063 Change-Id: Ieef3459b0b9bbce8bdad838ba83b4b64e7269d42	4 years ago
Kevin Buettner	3ceda72296	Fix GDB internal error by using text (instead of data) section offset Fedora Rawhide is now using gcc-12.0. As part of updating to the gcc-12.0 package set, Rawhide is also now using a version of libgcc_s which lacks a .data section. This causes gdb to fail in the following fashion while debugging a program (such as gdb) which uses libgcc_s: (top-gdb) run Starting program: rawhide-master/bld/gdb/gdb ... objfiles.h:467: internal-error: sect_index_data not initialized A problem internal to GDB has been detected, further debugging may prove unreliable. ... I snipped the backtrace from the above output. Instead, here's a portion of a backtrace obtained using GDB's backtrace command. (Obviously, in order to obtain it, I used a GDB which has been patched with this commit.) #0 internal_error ( file=0xc6a508 "gdb/objfiles.h", line=467, fmt=0xc6a4e8 "sect_index_data not initialized") at gdbsupport/errors.cc:51 #1 0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0) at gdb/objfiles.h:467 #2 0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0) at gdb/stap-probe.c:1333 #3 0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0, objfile=0x4fa48f0) at gdb/stap-probe.c:1341 #4 0x00000000004d7025 in create_exception_master_breakpoint_probe ( objfile=0x4fa48f0) at gdb/breakpoint.c:3505 #5 0x00000000004d7426 in create_exception_master_breakpoint () at gdb/breakpoint.c:3575 #6 0x00000000004efcc1 in breakpoint_re_set () at gdb/breakpoint.c:13407 #7 0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1) at gdb/solib.c:1001 #8 0x00000000009576a8 in handle_solib_event () at gdb/solib.c:1269 ... The function 'relocate_address' in gdb/stap-probe.c attempts to do its "relocation" by using objfile->data_section_offset(). That method, data_section_offset() is defined as follows in objfiles.h: CORE_ADDR data_section_offset () const { return section_offsets[SECT_OFF_DATA (this)]; } The internal error occurs when the SECT_OFF_DATA macro finds that the 'sect_index_data' field is -1: #define SECT_OFF_DATA(objfile) \ ((objfile->sect_index_data == -1) \ ? (internal_error (__FILE__, __LINE__, \ _("sect_index_data not initialized")), -1) \ : objfile->sect_index_data) relocate_address() is obtaining the section offset in order to compute a relocated address. For some ABIs, such as the System V ABI, the section offsets will all be the same. So for those ABIs, it doesn't matter which offset is used. However, other ABIs, such as the FDPIC ABI, will have different offsets for the various sections. Thus, for those ABIs, it is vital that this and other relocation code use the correct offset. In stap_probe::get_relocated_address, the address to which to add the offset (thus forming the relocated address) is obtained via this->get_address (); get_address is a getter for m_address in probe.h. It's documented/defined as follows (also in probe.h): /* The address where the probe is inserted, relative to SECT_OFF_TEXT. / CORE_ADDR m_address; (Thanks to Tom Tromey for this observation.) So, based on this, the current use of data_section_offset / SECT_OFF_DATA is wrong. This relocation code should have been using text_section_offset / SECT_OFF_TEXT all along. That being the case, I've adjusted the stap-probe.c relocation code accordingly. Searching the sources turned up one other use of data_section_offset, in gdb/dtrace-probe.c, so I've updated that code as well. The same reasoning presented above applies to this case too. Summary: gdb/dtrace-probe.c (dtrace_probe::get_relocated_address): Use method text_section_offset instead of data_section_offset. * gdb/stap-probe.c (relocate_address): Likewise.	4 years ago
Markus Metzger	0d8cbc5f2f	gdb, remote, btrace: move switch_to_thread call right before xfer call In remote_target::remote_btrace_maybe_reopen, we switch to the currently iterated thread in order to set inferior_ptid for a subsequent xfer. Move the switch_to_thread call directly before the target_read_stralloc call to clarify why we need to switch threads.	4 years ago
Markus Metzger	696c0d5ef2	gdb, gdbserver: update thread identifier in enable_btrace target method The enable_btrace target method takes a ptid_t to identify the thread on which tracing shall be enabled. Change this to thread_info * to avoid translating back and forth between the two. This will be used in a subsequent patch.	4 years ago
Markus Metzger	b674665b51	gdb, btrace: switch threads in remote_btrace_maybe_reopen() In remote_btrace_maybe_reopen() we iterate over threads and use set_general_thread() to set the thread from which to transfer the btrace configuration. This sets the remote general thread but does not affect inferior_ptid. On the xfer request later on, remote_target::xfer_partial() again sets the remote general thread to inferior_ptid, overwriting what remote_btrace_maybe_reopen() had done. In one case, this led to inferior_ptid being null_ptid when we tried to enable tracing on a newly created thread inside a newly created process during attach. This, in turn, led to find_inferior_pid() asserting when we iterated over threads in record_btrace_is_replaying(), which was called from record_btrace_target::xfer_partial() when reading the btrace configuration of the new thread to check whether it was already being recorded. The bug was exposed by `0618ae4149` gdb: optimize all_matching_threads_iterator and found by FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error) Use switch_to_thread() in remote_btrace_maybe_reopen().	4 years ago
Markus Metzger	b02b09623d	gdb, btrace: rename record_btrace_enable_warn() We use record_btrace_enable_warn() as the new-thread observer callback. It is not used in other contexts. Rename it to record_btrace_on_new_thread() to make its role more clear.	4 years ago
Nick Clifton	5fa0c2231c	Updated Swedish translation for the binutils subdirectory	4 years ago
GDB Administrator	423f33d970	Automatic date update in version.in	4 years ago
Andrew Burgess	299953ca95	gdb/python: handle non utf-8 characters when source highlighting This commit adds support for source files that contain non utf-8 characters when performing source styling using the Python pygments package. This does not change the behaviour of GDB when the GNU Source Highlight library is used. For the following problem description, assume that either GDB is built without GNU Source Highlight support, of that this has been disabled using 'maintenance set gnu-source-highlight enabled off'. The initial problem reported was that a source file containing non utf-8 characters would cause GDB to print a Python exception, and then display the source without styling, e.g.: Python Exception <class 'UnicodeDecodeError'>: 'utf-8' codec can't decode byte 0xc0 in position 142: invalid start byte /* Source code here, without styling... */ Further, as the user steps through different source files, each time the problematic source file was evicted from the source cache, and then later reloaded, the exception would be printed again. Finally, this problem is only present when using Python 3, this issue is not present for Python 2. What makes this especially frustrating is that GDB can clearly print the source file contents, they're right there... If we disable styling completely, or make use of the GNU Source Highlight library, then everything is fine. So why is there an error when we try to apply styling using Python? The problem is the use of PyString_FromString (which is an alias for PyUnicode_FromString in Python 3), this function converts a C string into a either a Unicode object (Py3) or a str object (Py2). For Python 2 there is no unicode encoding performed during this function call, but for Python 3 the input is assumed to be a uft-8 encoding string for the purpose of the conversion. And here of course, is the problem, if the source file contains non utf-8 characters, then it should not be treated as utf-8, but that's what we do, and that's why we get an error. My first thought when looking at this was to spot when the PyString_FromString call failed with a UnicodeDecodeError and silently ignore the error. This would mean that GDB would print the source without styling, but would also avoid the annoying exception message. However, I also make use of `pygmentize`, a command line wrapper around the Python pygments module, which I use to apply syntax highlighting in the output of `less`. And this command line wrapper is quite happy to syntax highlight my source file that contains non utf-8 characters, so it feels like the problem should be solvable. It turns out that inside the pygments module there is already support for guessing the encoding of the incoming file content, if the incoming content is not already a Unicode string. This is what happens for Python 2 where the incoming content is of `str` type. We could try and make GDB smarter when it comes to converting C strings into Python Unicode objects; this would probably require us to just try a couple of different encoding schemes rather than just giving up after utf-8. However, I figure, why bother? The pygments module already does this for us, and the colorize API is not part of the documented external API of GDB. So, why not just change the colorize API, instead of the content being a Unicode string (for Python 3), lets just make the content be a bytes object. The pygments module can then take responsibility for guessing the encoding. So, currently, the colorize API receives a unicode object, and returns a unicode object. I propose that the colorize API receive a bytes object, and return a bytes object.	4 years ago
Tom Tromey	27d326da43	Remove global wrap_here function This removes the global wrap_here function, so that future calls cannot be introduced. Instead, all callers must use the method on the appropriate ui_file. This temporarily moves the implementation of this method to utils.c. This will change once the remaining patches to untangle the pager have been written.	4 years ago
Tom Tromey	1285ce8629	Always call the wrap_here method This changes all existing calls to wrap_here to call the method on the appropriate ui_file instead. The choice of ui_file is determined by context.	4 years ago
Tom Tromey	7016a382b0	Add ui_file::wrap_here Right now, wrap_here is a global function. In the long run, we'd like output streams to be relatively self-contained objects, and having a global function like this is counter to that goal. Also, existing code freely mixes writes to some parameterized stream with calls to wrap_here -- but wrap_here only really affects gdb_stdout, so this is also incoherent. This step is a patch toward making wrap_here more sane. It adds a wrap_here method to ui_file and changes ui_out implementations to use it.	4 years ago
Tom Tromey	6c92c33953	Convert wrap_here to use integer parameter I think it only really makes sense to call wrap_here with an argument consisting solely of spaces. Given this, it seemed better to me that the argument be an int, rather than a string. This patch is the result. Much of it was written by a script.	4 years ago
Andrew Burgess	bbea680797	gdb/python: improve the auto help text for gdb.Parameter This commit attempts to improve the help text that is generated for gdb.Parameter objects when the user fails to provide their own documentation. Documentation for a gdb.Parameter is currently pulled from two sources: the class documentation string, and the set_doc/show_doc class attributes. Thus, a fully documented parameter might look like this: class Param_All (gdb.Parameter): """This is the class documentation string.""" show_doc = "Show the state of this parameter" set_doc = "Set the state of this parameter" def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_All, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_All ('param-all') Then in GDB we see this: (gdb) help set param-all Set the state of this parameter This is the class documentation string. Which is fine. But, if the user skips both of the documentation parts like this: class Param_None (gdb.Parameter): def get_set_string (self): val = "on" if (self.value == False): val = "off" return "Test Parameter has been set to " + val def __init__ (self, name): super (Param_None, self).__init__ (name, gdb.COMMAND_DATA, gdb.PARAM_BOOLEAN) self._value = True Param_None ('param-none') Now in GDB we see this: (gdb) help set param-none This command is not documented. This command is not documented. That's not great, the duplicated text looks a bit weird. If we drop different parts we get different results. Here's what we get if the user drops the set_doc and show_doc attributes: (gdb) help set param-doc This command is not documented. This is the class documentation string. That kind of sucks, we say it's undocumented, then proceed to print the documentation. Finally, if we drop the class documentation but keep the set_doc and show_doc: (gdb) help set param-set-show Set the state of this parameter This command is not documented. That seems OK. So, I think there's room for improvement. With this patch, for the four cases above we now see this: # All values provided by the user, no change in this case: (gdb) help set param-all Set the state of this parameter This is the class documentation string. # Nothing provided by the user, the first string is now different: (gdb) help set param-none Set the current value of 'param-none'. This command is not documented. # Only the class documentation is provided, the first string is # changed as in the previous case: (gdb) help set param-doc Set the current value of 'param-doc'. This is the class documentation string. # Only the set_doc and show_doc are provided, this case is unchanged # from before the patch: (gdb) help set param-set-show Set the state of this parameter This command is not documented. The one place where this change might be considered a negative is when dealing with prefix commands. If we create a prefix command but don't supply the set_doc / show_doc strings, then this is what we saw before my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- This command is not documented. ... snip ... And after my patch: (gdb) python Param_None ('print param-none') (gdb) help set print set print, set pr, set p Generic command for setting how things print. List of set print subcommands: ... snip ... set print param-none -- Set the current value of 'print param-none'. ... snip ... This seems slightly less helpful than before, but I don't think its terrible. Additionally, I've changed what we print when the get_show_string method is not provided in Python. Back when gdb.Parameter was first added to GDB, we didn't provide a show function when registering the internal command object within GDB. As a result, GDB would make use of its "magic" mangling of the show_doc string to create a sentence that would display the current value (see deprecated_show_value_hack in cli/cli-setshow.c). However, when we added support for the get_show_string method to gdb.Parameter, there was an attempt to maintain backward compatibility by displaying the show_doc string with the current value appended, see get_show_value in py-param.c. Unfortunately, this isn't anywhere close to what deprecated_show_value_hack does, and the results are pretty poor, for example, this is GDB before my patch: (gdb) show param-none This command is not documented. off I think we can all agree that this is pretty bad. After my patch, we how show this: (gdb) show param-none The current value of 'param-none' is "off". Which at least is a real sentence, even if it's not very informative. This patch does change the way that the Python API behaves slightly, but only in the cases when the user has missed providing GDB with some information. In most cases I think the new behaviour is a lot better, there's the one case (noted above) which is a bit iffy, but I think is still OK. I've updated the existing gdb.python/py-parameter.exp test to cover the modified behaviour. Finally, I've updated the documentation to (I hope) make it clearer how the various bits of help text come together.	4 years ago
Andrew Burgess	30a87e90be	gdb/python: add gdb.history_count function Add a new function gdb.history_count to the Python api, this function returns an integer, the number of items in GDB's value history. This is useful if you want to pull items from the history by their absolute number, for example, if you wanted to show a complete history list. Previously we could figure out how many items are in the history list by trying to fetch the items, and then catching the exception when the item is not available, but having this function seems nicer.	4 years ago
Tom Tromey	51d185a65f	Remove unused declaration This removes an unused declaration from top.h. This type is not defined anywhere.	4 years ago
Simon Marchi	fdf1350dc1	gdb: convert maintenance target-async and target-non-stop settings to callbacks This simplifies things a bit, as we don't need two variables and think about reverting target_async_permitted_1 and target_non_stop_enabled_1 values if we can't change the setting. Change-Id: I36acab045dacf02ae1988486cfdb27c1dff309f6	4 years ago
Keith Seitz	91ddba836c	Reference array of structs instead of first member during memcpy aarch64-tdep.c defines the following macro: #define MEM_ALLOC(MEMS, LENGTH, RECORD_BUF) \ do \ { \ unsigned int mem_len = LENGTH; \ if (mem_len) \ { \ MEMS = XNEWVEC (struct aarch64_mem_r, mem_len); \ memcpy(&MEMS->len, &RECORD_BUF[0], \ sizeof(struct aarch64_mem_r) * LENGTH); \ } \ } \ while (0) This is simlpy allocating a new array and copying it. However, for the destination address, it is actually copying into the first member of the first element of the array (`&MEMS->len"). This elicits a warning with GCC 12: ../../binutils-gdb/gdb/aarch64-tdep.c: In function ‘int aarch64_process_record(gdbarch, regcache, CORE_ADDR)’: ../../binutils-gdb/gdb/aarch64-tdep.c:3711:23: error: writing 16 bytes into a region of size 8 [-Werror=stringop-overflow=] 3711 \| memcpy(&MEMS->len, &RECORD_BUF[0], \ \| ^ ../../binutils-gdb/gdb/aarch64-tdep.c:4394:3: note: in expansion of macro ‘MEM_ALLOC’ 4394 \| MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count, \| ^~~~~~~~~ ../../binutils-gdb/gdb/aarch64-tdep.c:3721:12: note: destination object ‘aarch64_mem_r::len’ of size 8 3721 \| uint64_t len; /* Record length. */ \| ^~~ The simple fix is to reference the array, `MEMS' as the destination of the copy. Tested by rebuilding. # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want to. # An empty message aborts the commit. # # Date: Tue Jan 25 08:28:32 2022 -0800 # # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # (use "git push" to publish your local commits) # # Changes to be committed: # modified: aarch64-tdep.c #	4 years ago
Simon Marchi	5d10a2041e	gdb: add string_file::release method A common pattern for string_file is to want to move out the internal string buffer, because it is the result of the computation that we want to return. It is the reason why string_file::string returns a non-const reference, as explained in the comment. I think it would make sense to have a dedicated method for that instead and make string_file::string return a const reference. This allows removing the explicit std::move in the typical case. Note that compile_program::compute was missing a move, meaning that the resulting string was copied. With the new version, it's not possible to forget to move. Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79	4 years ago
Tom Tromey	b583c328e7	Add a way to temporarily set a gdb parameter from Python It's sometimes useful to temporarily set some gdb parameter from Python. Now that the 'endian' crash is fixed, and now that the current language is no longer captured by the Python layer, it seems reasonable to add a helper function for this situation. This adds a new gdb.with_parameter function. This creates a context manager which temporarily sets some parameter to a specified value. The old value is restored when the context is exited. This is most useful with the Python "with" statement: with gdb.with_parameter('language', 'ada'): ... do Ada stuff This also adds a simple function to set a parameter, gdb.set_parameter, as suggested by Andrew. This is PR python/10790. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10790	4 years ago
Tom Tromey	dedb7102b3	Fix another crash with gdb parameters in Python While looking into the language-capturing issue, I found another way to crash gdb using parameters from Python: (gdb) python print(gdb.parameter('endian')) (This is related to PR python/12188, though this patch isn't going to fix what that bug is really about.) The problem here is that the global variable that underlies the "endian" parameter is initialized to NULL. However, that's not a valid value for an "enum" set/show parameter. My understanding is that, in gdb, an "enum" parameter's underlying variable must have a value that is "==" (not just strcmp-equal) to one of the values coming from the enum array. This invariant is relied on in various places. I started this patch by fixing the problem with "endian". Then I added some assertions to add_setshow_enum_cmd to try to catch other problems of the same type. This patch fixes all the problems that I found. I also looked at all the calls to add_setshow_enum_cmd to ensure that they were all included in the gdb I tested. I think they are: there are no calls in nat-* files, or in remote-sim.c; and I was trying a build with all targets, Python, and Guile enabled. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188	4 years ago
Tom Tromey	1da5d0e664	Change how Python architecture and language are handled Currently, gdb's Python layer captures the current architecture and language when "entering" Python code. This has some undesirable effects, and so this series changes how this is handled. First, there is code like this: gdbpy_enter enter_py (python_gdbarch, python_language); This is incorrect, because both of these are NULL when not otherwise assigned. This can cause crashes in some cases -- I've added one to the test suite. (Note that this crasher is just an example, other ones along the same lines are possible.) Second, when the language is captured in this way, it means that Python code cannot affect the current language for its own purposes. It's reasonable to want to write code like this: gdb.execute('set language mumble') ... stuff using the current language gdb.execute('set language previous-value') However, this won't actually work, because the language is captured on entry. I've added a test to show this as well. This patch changes gdb to try to avoid capturing the current values. The Python concept of the current gdbarch is only set in those few cases where a non-default value is computed or needed; and the language is not captured at all -- instead, in the cases where it's required, the current language is temporarily changed.	4 years ago
H.J. Lu	8a782bbf70	bfd: Make bfd.stamp depend on source bfd.texi Make bfd.stamp depend on source bfd.texi to avoid regenerating doc/bfd.info for each make run. PR binutils/28807 * Makefile.in: Regenerate. * doc/local.mk (%D%/bfd.stamp): Depend on $(srcdir)/%D%/bfd.texi.	4 years ago
H.J. Lu	c804c6f98d	ld: Rewrite lang_size_relro_segment_1 1. Compute the desired PT_GNU_RELRO segment base and find the maximum section alignment of sections starting from the PT_GNU_RELRO segment. 2. Find the first preceding load section. 3. Don't add the 1-page gap between the first preceding load section and the relro segment if the maximum page size >= the maximum section alignment. Align the PT_GNU_RELRO segment first. Subtract the maximum page size if therer is still a 1-page gap. PR ld/28743 PR ld/28819 * ldlang.c (lang_size_relro_segment_1): Rewrite. * testsuite/ld-x86-64/pr28743-1.d: New file. * testsuite/ld-x86-64/pr28743-1.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run pr28743-1.	4 years ago
Lancelot SIX	8357282156	gdb/testsuite: Ensure constant test name in gdb.base/break-interp.exp When running the testsuite, I have lines similar to the following in the gdb.sum file: ~~~ PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: first backtrace: p /x 0x7f283d2f0fd1 ... PASS: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: first backtrace: p /x 0x7f00de0317a5 ... ~~~ The address part of the command might change between execution of the test, which adds noise to a diff between two .sum files. This patch changes to test name to "p /x $pc" in order to have constant test name. Tested on x86_64-Linux. Change-Id: I973c1237a084dd6d424276443cbf0920533c9a21	4 years ago
GDB Administrator	a80032197f	Automatic date update in version.in	4 years ago
Tom Tromey	a8e9f25759	Always print the "host libthread-db" message to stdout linux-thread-db.c has a bit of unusual code that unconditionally prints a message, but decides whether to print to gdb_stdout or gdb_stdlog based on a debug flag. It seems better to me to simply always print this; and this is the only spot in gdb where we conditionally pass gdb_stdout to one of the f*_unfiltered functions.	4 years ago
Tom Tromey	d4396e0e97	Reduce explicit use of gdb_stdout In an earlier version of the pager rewrite series, it was important to audit unfiltered output calls to see which were truly necessary. This is no longer necessary, but it still seems like a decent cleanup to change calls to avoid explicitly passing gdb_stdout. That is, rather than using something like fprintf_unfiltered with gdb_stdout, the code ought to use plain printf_unfiltered instead. This patch makes this change. I went ahead and converted all the _filtered calls I could find, as well, for the same clarity.	4 years ago
Tom Tromey	244ac24b51	Sent timing stats to gdb_stdlog This changes the time / space / symtab per-command statistics code to send its output to gdb_stdlog rather than gdb_stdout. This seems slightly more correct to me.	4 years ago
Tom Tromey	1475b18b77	Send some error output to gdb_stderr This changes some code to send some error messages to gdb_stderr rather than gdb_stdout.	4 years ago
Klaus Ziegler	b6437be687	Fix a probem building the binutils on SPARC/amd64 PR 28816 * elf/common.h (AT_SUN_HWCAP): Make definition conditional.	4 years ago
H.J. Lu	042a82e5ee	bfd: Regenerate Makefile.in * Makefile.in: Regenerate.	4 years ago
Mike Frysinger	7d9d9c1078	gold: drop old cygnus install hack The gold subdir doesn't actually have a manual, so this hack doesn't do anything. Plus the automake cygnus option was removed years ago by Simon in `d0ac1c4488` ("Bump to autoconf 2.69 and automake 1.15.1"). So delete it here.	4 years ago
Mike Frysinger	9a84a44d5d	gas: drop old cygnus install hack This was needed when gas was using the automake cygnus option, but this was removed years ago by Simon in `d0ac1c4488` ("Bump to autoconf 2.69 and automake 1.15.1"). So delete it here. The info pages are already & still installed by default w/out it.	4 years ago
GDB Administrator	823f6c5f05	Automatic date update in version.in	4 years ago
H.J. Lu	94fd627d46	bfd: Update doc/local.mk PR binutils/28807 * Makefile.in: Regenerate. * doc/local.mk (AM_MAKEINFOFLAGS): Add -I "$(srcdir)/%D%" -I %D%. (TEXI2DVI): New. (%D%/bfd.texi): Removed. (doc/bfd/index.html): Remove -I$(srcdir). Replace bfd.texi with %D%/bfd.texi.	4 years ago

... 3 4 5 6 7 ...

109083 Commits (216722984fec8aa76e2d97d7b8fcc2fb1608825b) All Branches Search

109083 Commits (216722984fec8aa76e2d97d7b8fcc2fb1608825b)

All Branches