binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Faraz Shahbazker	b6af5f3a74	sim: Factor out NaN handling in floating point operations 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com> sim/common/ChangeLog: * sim-fpu.c (sim_fpu_op_nan): New. (sim_fpu_add): Factor out NaN operand handling with a call to sim_fpu_op_nan. (sim_fpu_sub, sim_fpu_mul, sim_fpu_div): Likewise. (sim_fpu_rem, sim_fpu_max, sim_fpu_min): Likewise. * sim-fpu.h (sim_fpu_op_nan): New declaration.	4 years ago
Faraz Shahbazker	bf484e9348	sim: Allow toggling of quiet NaN-bit semantics IEEE754-1985 specifies the top bit of the mantissa as an indicator of signalling vs. quiet NaN, but does not define the precise semantics. Most architectures treat this bit as indicating quiet NaN, but legacy (pre-R6) MIPS goes the other way and treats it as signalling NaN. This used to be controlled by a macro that was only defined for MIPS. This patch replaces the macro with a variable to track the current semantics of the NaN bit and allows differentiation between older (pre-R6) and and newer MIPS cores. 2022-02-01 Faraz Shahbazker <fshahbazker@wavecomp.com> sim/common/ChangeLog: * sim-fpu.c (_sim_fpu): New. (pack_fpu, unpack_fpu): Allow reversal of quiet NaN semantics. * sim-fpu.h (sim_fpu_state): New struct. (_sim_fpu): New extern. (sim_fpu_quiet_nan_inverted): New define. sim/mips/ChangeLog: * cp1.h (fcsr_NAN2008_mask, fcsr_NAN2008_shift): New. * mips.igen (check_fpu): Select default quiet NaN mode for legacy MIPS. * sim-main.h (SIM_QUIET_NAN_NEGATED): Remove.	4 years ago
GDB Administrator	eb06e60a98	Automatic date update in version.in	4 years ago
H.J. Lu	565c20212a	ld: Remove emultempl/armcoff.em Remove emultempl/armcoff.em which has been unused after commit `2ac93be706` Author: Alan Modra <amodra@gmail.com> Date: Mon Apr 16 20:33:36 2018 +0930 Remove arm-aout and arm-coff support This also removes arm-netbsd (not arm-netbsdelf!), arm-openbsd, and arm-riscix. Those targets weren't on the obsolete list but they are all aout, and it doesn't make all that much sense to remove arm-aout without removing them too. * emultempl/armcoff.em: Removed.	4 years ago
Simon Marchi	4a620b7e30	gdb: include jit_code_entry::symfile_addr value in names of objfiles created by jit reader API This commit includes the JIT object's symfile address in the names of objfiles created by JIT reader API (e.g., << JIT compiled code at 0x7ffd8a0c77a0 >>). This allows one to at least differentiate one from another. The address is the one that the debugged program has put in jit_code_entry::symfile_addr, and that the JIT reader's read function receives. As we can see in gdb.base/jit-reader-host.c and gdb.base/jit-reader.c, that may not be the actual value of where the JIT-ed code is. But it is a value chosen by the author of the JIT engine and the JIT reader, so including this value in the objfile name may help them correlate the JIT objfiles created by with their logs / data structures. To access this field, we need to pass down a reference to the jit_code_entry. So make jit_dbg_reader_data a structure (instead of an alias for a CORE_ADDR) that includes the address of the code entry in the inferior's address space (the previous meaning of jit_dbg_reader_data) plus a reference to the jit_code_entry as read into GDB's address space. And while at it, pass down the gdbarch, so that we don't have to call target_gdbarch. Co-Authored-By: Jan Vrany <jan.vrany@labware.com> Change-Id: Ib26c4d1bd8de503d651aff89ad2e500cb312afa5	4 years ago
Tom Tromey	480157863b	Improve Ada unchecked union type printing Currently, "ptype" of an Ada unchecked union may show a compiler-generated wrapper structure in its output. It's more Ada-like to elide this structure, which is what this patch implements. It turned out to be simplest to reuse a part of print_variant_clauses for this. As this is Ada-specific, and Joel already reviewed it internally, I am going to check it in.	4 years ago
Tom Tromey	2b53149244	Remove host_hex_value I noticed that host_hex_value is redundant, because gdbsupport already has fromhex. This patch removes the former in favor of the latter. Regression tested on x86-64 Fedora 34.	4 years ago
Andi Kleen	fd3c53675c	Support symbol+offset lookup in addr2line The Linux kernel usually ouputs symbol+offset instead of plain code addresses these days, to avoid leaking ASLR secrets and to handle dynamically loaded modules. Converting those with addr2line is somewhat involved: it requires looking up the symbol first using nm and then manually compute the offset, and then pass it to addr2line. This patch implements the necessary steps directly in addr2line, by looking up the symbol (with demangling if needed) and computing the offset. It's possible that a symbol is ambigious with a hex number. In this case it uses the symbol lookup if the string contains a +. When it isn't ambigious the + is optional.	4 years ago
GDB Administrator	78110c3f77	Automatic date update in version.in	4 years ago
Cary Coutant	dfbcbf85ea	Rename EM_56800V4 to EM_56800EF. include/elf: * common.h: Rename EM_56800V4 to EM_56800EF.	4 years ago
H.J. Lu	8d26ee1cd1	x86: Update X86_64_GOT_TYPE_P to cover more GOT relocations Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64 to X86_64_GOT_TYPE_P to cover more GOT relocations. PR ld/28858 * elfxx-x86.h (X86_64_GOT_TYPE_P): Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64.	4 years ago
Cary Coutant	9d5d41c405	Add new e_machine values. include/elf: * common.h: Add EM_U16_U8CORE, EM_TACHYUM, EM_56800V4.	4 years ago
Tankut Baris Aktemur	e69d64d21a	testsuite: fix failure in gdb.threads/killed-outside.exp Starting with commit commit `1da5d0e664` Date: Tue Jan 4 08:02:24 2022 -0700 Change how Python architecture and language are handled we see a failure in gdb.threads/killed-outside.exp: ... Executing on target: kill -9 16622 (timeout = 300) builtin_spawn -ignore SIGHUP kill -9 16622 continue Continuing. Couldn't get registers: No such process. (gdb) [Thread 0x7ffff77c2700 (LWP 16626) exited] Program terminated with signal SIGKILL, Killed. The program no longer exists. FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout) This is not a regression but a failure due to a change in GDB's output. Prior to the aforementioned commit, GDB has been printing the "Couldn't get registers: No such process." message twice. The second one came from (top-gdb) bt #0 amd64_linux_nat_target::fetch_registers (this=0x555557f31440 <the_amd64_linux_nat_target>, regcache=0x555558805ce0, regnum=16) at /gdb-up/gdb/amd64-linux-nat.c:225 #1 0x000055555640ac5f in target_ops::fetch_registers (this=0x555557d636d0 <the_thread_db_target>, arg0=0x555558805ce0, arg1=16) at /gdb-up/gdb/target-delegates.c:502 #2 0x000055555641a647 in target_fetch_registers (regcache=0x555558805ce0, regno=16) at /gdb-up/gdb/target.c:3945 #3 0x0000555556278e68 in regcache::raw_update (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:587 #4 0x0000555556278f14 in readable_regcache::raw_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:601 #5 0x00005555562792aa in readable_regcache::cooked_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:690 #6 0x000055555627965e in readable_regcache::cooked_read_value (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:748 #7 0x0000555556352a37 in sentinel_frame_prev_register (this_frame=0x555558181090, this_prologue_cache=0x5555581810a8, regnum=16) at /gdb-up/gdb/sentinel-frame.c:53 #8 0x0000555555fa4773 in frame_unwind_register_value (next_frame=0x555558181090, regnum=16) at /gdb-up/gdb/frame.c:1235 #9 0x0000555555fa420d in frame_register_unwind (next_frame=0x555558181090, regnum=16, optimizedp=0x7fffffffd570, unavailablep=0x7fffffffd574, lvalp=0x7fffffffd57c, addrp=0x7fffffffd580, realnump=0x7fffffffd578, bufferp=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1143 #10 0x0000555555fa455f in frame_unwind_register (next_frame=0x555558181090, regnum=16, buf=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1199 #11 0x00005555560178e2 in i386_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/i386-tdep.c:1972 #12 0x0000555555cd2b9d in gdbarch_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/gdbarch.c:3007 #13 0x0000555555fa3a5b in frame_unwind_pc (this_frame=0x555558181090) at /gdb-up/gdb/frame.c:948 #14 0x0000555555fa7621 in get_frame_pc (frame=0x555558181160) at /gdb-up/gdb/frame.c:2572 #15 0x0000555555fa7706 in get_frame_address_in_block (this_frame=0x555558181160) at /gdb-up/gdb/frame.c:2602 #16 0x0000555555fa77d0 in get_frame_address_in_block_if_available (this_frame=0x555558181160, pc=0x7fffffffd708) at /gdb-up/gdb/frame.c:2665 #17 0x0000555555fa5f8d in select_frame (fi=0x555558181160) at /gdb-up/gdb/frame.c:1890 #18 0x0000555555fa5bab in lookup_selected_frame (a_frame_id=..., frame_level=-1) at /gdb-up/gdb/frame.c:1720 #19 0x0000555555fa5e47 in get_selected_frame (message=0x0) at /gdb-up/gdb/frame.c:1810 #20 0x0000555555cc9c6e in get_current_arch () at /gdb-up/gdb/arch-utils.c:848 #21 0x000055555625b239 in gdbpy_before_prompt_hook (extlang=0x555557451f20 <extension_language_python>, current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/python/python.c:1063 #22 0x0000555555f7cfbb in ext_lang_before_prompt (current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/extension.c:922 #23 0x0000555555f7d442 in std::_Function_handler<void (char const), void ()(char const)>::_M_invoke(std::_Any_data const&, char const&&) (__functor=..., __args#0=@0x7fffffffd900: 0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:316 #24 0x0000555555f752dd in std::function<void (char const)>::operator()(char const) const (this=0x55555817d838, __args#0=0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:706 #25 0x0000555555f75100 in gdb::observers::observable<char const>::notify (this=0x555557f49060 <gdb::observers::before_prompt>, args#0=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/../gdbsupport/observable.h:150 #26 0x0000555555f736dc in top_level_prompt () at /gdb-up/gdb/event-top.c:444 #27 0x0000555555f735ba in display_gdb_prompt (new_prompt=0x0) at /gdb-up/gdb/event-top.c:411 #28 0x00005555564611a7 in tui_on_command_error () at /gdb-up/gdb/tui/tui-interp.c:205 #29 0x0000555555c2173f in std::_Function_handler<void (), void ()()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/7/bits/std_function.h:316 #30 0x0000555555e10c20 in std::function<void ()>::operator()() const (this=0x5555580f9028) at /usr/include/c++/7/bits/std_function.h:706 #31 0x0000555555e10973 in gdb::observers::observable<>::notify() const (this=0x555557f48d20 <gdb::observers::command_error>) at /gdb-up/gdb/../gdbsupport/observable.h:150 #32 0x00005555560e9b3f in start_event_loop () at /gdb-up/gdb/main.c:438 #33 0x00005555560e9bcc in captured_command_loop () at /gdb-up/gdb/main.c:481 #34 0x00005555560eb616 in captured_main (data=0x7fffffffddd0) at /gdb-up/gdb/main.c:1348 #35 0x00005555560eb67c in gdb_main (args=0x7fffffffddd0) at /gdb-up/gdb/main.c:1363 #36 0x0000555555c1b6b3 in main (argc=12, argv=0x7fffffffded8) at /gdb-up/gdb/gdb.c:32 Commit `1da5d0e664` eliminated the call to 'get_current_arch' in 'gdbpy_before_prompt_hook'. Hence, the second instance of "Couldn't get registers: No such process." does not appear anymore. Fix the failure by updating the regular expression in the test.	4 years ago
Alan Modra	3a3a4c1fe4	PowerPC64 treatment of absolute symbols Supporting -static-pie on PowerPC64 requires the linker to properly treat SHN_ABS symbols for cases like glibc's _nl_current_LC_CTYPE_used absolute symbol. I've been slow to fix the linker on powerpc because there is some chance that this will break some shared libraries or PIEs. bfd/ * elf64-ppc.c (ppc64_elf_check_relocs): Consolidate local sym handling code. Don't count dyn relocs against non-dynamic absolute symbols. (dec_dynrel_count): Adjust to suit. (ppc64_elf_edit_toc): Don't remove entries for absolute symbols when pic. (allocate_got): Don't allocate space for got relocs against non-dynamic absolute syms. (ppc64_elf_layout_multitoc): Likewise. (got_and_plt_relr): Likewise. (ppc64_elf_size_dynamic_sections): Likewise for local got. (got_and_plt_relr_for_local_syms): Likewise. (ppc64_elf_size_stubs): Don't allocate space for relr either. (ppc64_elf_relocate_section): Don't write relocs against non-dynamic absolute symbols. Don't optimise got and toc code sequences loading absolute symbol entries. ld/ * testsuite/ld-powerpc/abs-reloc.s, * testsuite/ld-powerpc/abs-static.d, * testsuite/ld-powerpc/abs-static.r, * testsuite/ld-powerpc/abs-pie.d, * testsuite/ld-powerpc/abs-pie.r, * testsuite/ld-powerpc/abs-shared.d, * testsuite/ld-powerpc/abs-shared.r, * testsuite/ld-powerpc/abs-pie-relr.d, * testsuite/ld-powerpc/abs-pie-relr.r, * testsuite/ld-powerpc/abs-shared-relr.d, * testsuite/ld-powerpc/abs-shared-relr.r: New tests. * testsuite/ld-powerpc/powerpc.exp: Run them.	4 years ago
GDB Administrator	36a13a0e62	Automatic date update in version.in	4 years ago
Nick Clifton	41ba8b76cc	Stop the BFD library complaining about compressed dwarf debug string sections being too big. PR 28834 * dwarf2.c (read_section): Change the heuristic that checks for overlarge dwarf debug info sections.	4 years ago
Andrew Burgess	2f6b20e2e0	gdb: fix formatting for help set/show extended-prompt The formatting of the help text for 'help set extended-prompt' and 'help show extended-prompt' is a little off. Here's the offending snippet: Substitutions are applied to VALUE to compute the real prompt. The currently defined substitutions are: \[ Begins a sequence of non-printing characters. \\ A backslash. \] Ends a sequence of non-printing characters. \e The ESC character. Notice that the line for '\[' is indented more that the others. Turns out this is due to how we build this help text, something which is done in Python. We extended a classes __doc__ string with some dynamically generated text. The classes doc string looks like this: """Set the extended prompt. Usage: set extended-prompt VALUE Substitutions are applied to VALUE to compute the real prompt. The currently defined substitutions are: """ Notice the closing """ are in a line of their own, and include some white space just before. It's this extra white space that's causing the problem. Fix the formatting issue by moving the """ to the end of the previous line. I then add the extra newline in at the point where the doc string is merged with the dynamically generated text. Now everything lines up correctly.	4 years ago
Andrew Burgess	a591084285	gdb: test to check one aspect of the linespec parsing code While working on the fix for PR cli/28665 (see previous couple of commits), I was playing with making a change in the linespec parsing code. Specifically, I was thinking about whether the spec_string for LINESPEC_LOCATION locations should ever be nullptr. I made a change to prevent the spec_string from ever being nullptr, tested gdb, and saw no regressions. However, as part of this work I was reviewing how the breakpoint code handles this case (spec_string being nullptr), and spotted that in parse_breakpoint_sals the nullptr case is specifically handled, so changing this should have caused a regression. But I didn't see one. So, this commit adds a comment in location.c mentioning that the nullptr case is (a) not an oversight, and (b) is required. Then I add a new test to gdb.base/break.exp that ensures a change in this area will cause a regression. This test passes on current gdb, but with my modified (and broken) gdb, the test would fail.	4 years ago
Andrew Burgess	82d0a72cdc	gdb: handle calls to edit command passing only a linespec condition While working on the previous commit to fix PR cli/28665, I noticed that the 'edit' command would suffer from the same problem. That is, something like: (gdb) edit task 123 would cause GDB to break. For a full explanation of what's going on here, see the commit message for the previous commit. As with the previous commit, this issue can be prevented by detecting, and throwing, a junk at the end of the line error earlier, before calling decode_line_1. So, that's what this commit does. I've also added some tests for this issue. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665	4 years ago
Andrew Burgess	3c5fcec6dc	gdb: handle calls to list command passing only a linespec condition In PR cli/28665, it was reported that GDB would crash when given a command like: (gdb) list task 123 The problem here is that in cli/cli-cmd.c:list_command, the string 'task 123' is passed to string_to_event_location in find a location specification. However, this location parsing understands about breakpoint conditions, and so, will stop parsing when it sees something that looks like a condition, in this case, the 'task 123' looks like a breakpoint condition. As a result, the location we get back from string_to_event_location has no actual location specification attached to it. The actual call path is: list_command string_to_event_location string_to_event_location_basic new_linespec_location In new_linespec_location we call linespec_lex_to_end, which looks at 'task 123' and decides that there's nothing there that describes a location. As such, in new_linespec_location, the spec_string field of the location is left as nullptr. Back in list_command we then call decode_line_1, which calls event_location_to_sals, which calls parse_linespec, which takes the spec_string we found earlier, and tries to converts this into a list of sals. However, parse_linespec is not intended to be passed a nullptr, for example, calling is_ada_operator will try to access through the nullptr, causing undefined behaviour. But there are other cases within parse_linespec which don't expect to see a nullptr. When looking at how to fix this issue, I first considered having linespec_lex_to_end detect the problem. That function understands when the first thing in the linespec is a condition keyword, and so, could throw an error saying something like: "no linespec before condition keyword", however, this is not going to work, at least, not without additional changes to GDB, it is valid to place a breakpoint like: (gdb) break task 123 This will place a breakpoint at the current location with the condition 'task 123', and changing linespec_lex_to_end breaks this behaviour. So, next, I considered what would happen if I added a condition to an otherwise valid list command, this is what I see: (gdb) list file.c:1 task 123 Junk at end of line specification. (gdb) So, then I wondered, could we just pull the "Junk" detection forward, so that we throw the error earlier, before we call decode_line_1? It turns out that yes we can. Well, sort of. It is simpler, I think, to add a separate check into the list_command function, after calling string_to_event_location, but before calling decode_line_1. We know when we call string_to_event_location that the string in question is not empty, so, after calling string_to_event_location, if non of the string has been consumed, then the content of the string must be junk - it clearly doesn't look like a location specification. I've reused the same "Junk at end of line specification." error for consistency, and added a few tests to cover this issue. While the first version of this patch was on the mailing list, a second bug PR gdb/28797 was raised. This was for a very similar issue, but this time the problem command was: (gdb) list ,, Here the list command understands about the first comma, list can have two arguments separated by a comma, and the first argument can be missing. So we end up trying to parse the second command "," as a linespec. However, in linespec_lex_to_end, we will stop parsing a linespec at a comma, so, in the above case we end up with an empty linespec (between the two commas), and, like above, this results in the spec_string being nullptr. As with the previous case, I've resolved this issue by adding an extra check for junk at the end of the line - after parsing (or failing to parse) the nothing between the two commas, we still have the "," left at the end of the list command line - when we see this we can throw the same "junk at the end of the line" error, and all is good. I've added tests for this case too. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797	4 years ago
Andrew Burgess	ed2a947856	gdb/testsuite: move linespec test into gdb.linespec/ directory The gdb.base/linespecs.exp test should really live in the gdb.linespec directory, so lets move it there. As we already have gdb.linespec/linespec.exp, I've renamed the test to gdb.linespec/errors.exp, as this better reflects what the test is actually checking. Finally, the test script doesn't have its own source file, it was reusing a random other source file, gdb.base/memattr.c. Now the tests script is in gdb.linespec/, I've updated the test to use a different source file from that directory.	4 years ago
Andrew Burgess	8e454b9c61	gdb: add empty string check in parse_linespec If parse_linespec (linespec.c) is passed ARG as an empty string then we end up calling `strchr (linespec_quote_characters, '\0')`, which will return a pointer to the '\0' at the end of linespec_quote_characters. This then results in GDB calling skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG only contained a single character, the '\0'). Fix this by checking for the first character of ARG being '\0' before the call to strchr. I have additionally added an assertion that ARG can't itself be nullptr, as calling is_ada_operator with nullptr can end up calling 'startswith' on the nullptr, which is undefined behaviour. Finally, I moved the declaration of TOKEN into the body of parse_linespec, to where TOKEN is defined. This patch came about while I was working on fixes for PR cli/28665 and PR gdb/28797. The actual fixes for these two issues will be in a later commit in this series, but, with this patch in place, both of the above bugs would hit the new assertion rather than accessing invalid memory and crashing. The '\0' check is not currently ever hit, but just makes the code a little safer. Because this patch only changes the nature of the failure for the above two bugs, there's no tests here. A later commit will fix the above two issues, at which point I'll add some tests. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28665 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28797	4 years ago
Andrew Burgess	b6e05abee3	gdb: update the comment on string_to_event_location The comment on string_to_event_location is (I believe) out of date. This commit fixes the two issues I see: 1. This function can't return NULL any more. The implementation calls string_to_explicit_location which can return NULL, but if this is the case we then call string_to_event_location_basic, which I don't believe can ever return NULL. 2. I've removed the mention that the returned string is malloc'd, though this is true, now that we return a managed pointer, I believe the source of the memory allocation is irrelevant, and so, shouldn't be discussed in the header comment. There should be no user visible changes after this commit.	4 years ago
Nick Clifton	a698397481	Updated French translation for the ld/ and gold/ sub-directories	4 years ago
Stafford Horne	c7c6e55b60	or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto Previously when fixing PR 21464 we masked out upper bits of the relocation value in order to avoid overflow complaints when acceptable. It turns out this does not work when the relocation value ends up being signed. To fix this this patch introduces a special howto with complain_on_overflow set to complain_overflow_dont. This is used in place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16 relocations. bfd/ChangeLog: PR 28735 * elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define. (or1k_elf_relocate_section): Use new howto instead of trying to mask out relocation bits.	4 years ago
GDB Administrator	14f9835738	Automatic date update in version.in	4 years ago
Tom Tromey	326f526e1b	Fix flex rule in gdb Currently, if flex fails, it will leave the resulting .c file in the tree. This will cause a cascade of errors, and requires the manual deletion of the .c file in order to recreate the problem. It's better for the rule to fail such that the .c file is not updated. This way, 'make' will fail the same way every time -- which is much handier for debugging syntax errors. This fix just updates the Makefile rule to follow the way that the "yacc" rule already works.	4 years ago
Markus Metzger	cd393cec3a	gdb, btrace: improve error messages When trying to use 'record btrace' on a system that does not support it, the error message isn't as clear as it could be. See https://sourceware.org/pipermail/gdb/2022-January/049870.html. Improve the error message in a few cases. Reported-by: Simon Sobisch <simonsobisch@gnu.org>	4 years ago
Jan Vrany	219c04fc3b	gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled code While experimenting with JIT reader API I realized that calling repr () on objfile created by JIT reader crashes GDB. The problem was that objfpy_repr () called objfile_filename () which returned NULL, causing PyString_FromFormat () to crash. This commit fixes this problem by using objfile_name () instead of objfile_filename (). This also makes consistent with the value of gdb.Objfile.filename variable.	4 years ago
Samuel Thibault	fc46f98d5d	hurd: Fix RPC prototypes The last updates of MIG introduced qualifying strings and arrays with const as appropriate. We thus have to update the protypes in gdb too. Change-Id: I3f72aac1dfa6e58d1394d5776b822d7c8f2409df	4 years ago
Samuel Thibault	e327c35ef5	hurd: Fix RPC link names The RPC stub code expects to be calling a C function, not a C++ function. Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f	4 years ago
GDB Administrator	21cbd63389	Automatic date update in version.in	4 years ago
H.J. Lu	4bed253f22	elf: Check symbol version without any symbols VER_FLG_WEAK doesn't indicate that all symbol references of the symbol version have STB_WEAK. VER_FLG_WEAK indicates a weak symbol version definition with no symbols associated with it. It is used to verify the existence of a particular implementation without any symbol references to the weak symbol version. PR ld/24718 * testsuite/ld-elf/pr24718-1.d: New file. * testsuite/ld-elf/pr24718-1.s: Likewise. * testsuite/ld-elf/pr24718-1.t: Likewise.	4 years ago
H.J. Lu	e1dbfc17c5	Load debug section only when dumping debug sections Don't load debug sections if we aren't dumping any debug sections. PR binutils/28843 * objdump.c (dump_any_debugging): New. (load_debug_section): Return false if dump_any_debugging isn't set. (main): Set dump_any_debugging when dumping any debug sections. * readelf (dump_any_debugging): New. (parse_args): Set dump_any_debugging when dumping any debug sections. (load_debug_section): Return false if dump_any_debugging isn't set.	4 years ago
Simon Marchi	492325c4b7	gdb: fix some clang-tidy readability-misleading-indentation warnings I have warnings like these showing in my editor all the time, so I thought I'd run clang-tidy with this diagnostic on all the files (that I can compile) and fix them. There is still one warning, in utils.c, but that's because some code is mixed up with preprocessor macros (#ifdef TUI), so I think there no good solution there. Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b	4 years ago
Nils-Christian Kempke	8d2ef06e1c	gdb, testsuite, fortran: adapt info symbol expected output for intel compilers Info symbol is expected to print the symbol table name of a symbol, since symbol lookup happens via the minimal symbol table. This name corresponds to the linkage name in the full symbol table. For gfortran (and maybe others) these names currently have the form XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler generated appendix for mangling. An example taken from the modified nested-funcs-2.exp would be ~~~~ $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 \| grep \ increment 00000000000014ab l F .text 0000000000000095 increment.3883 000000000000141c l F .text 000000000000008f increment_program_global.3881 ~~~~ This mangled name gets recognized by the Ada demangler/decoder and decoded as Ada to XXXX (setting the symbol language to Ada). This leads to output of XXXX over XXXX.NUMBER for info symbol on gfortran symbols. For ifort and ifx the generated linkage names have the form SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any other demangler for that matter) and thus printed as is. The respective objdump in the above case looks like ~~~~ $ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 \| grep \ increment 0000000000403a44 l F .text 0000000000000074 contains_keyword_IP_increment_ 0000000000403ab8 l F .text 0000000000000070 contains_keyword_IP_increment_program_global_ ~~~~ In the unmodified testcase this results in 'fails' when ran with the intel compilers: ~~~~ >> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \ GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'" ... === gdb Summary === \# of expected passes 80 \# of unexpected failures 14 ~~~~ Note that there is no Fortran mangling standard. We keep the gfortran behavior as is and modify the test to reflect ifx and ifort mangled names which fixes above fails. Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>	4 years ago
Nick Clifton	f10f8617a3	Import patch from mainline GCC to fix an infinite recusion in the Rust demangler. PR 98886 PR 99935 * rust-demangle.c (struct rust_demangler): Add a recursion counter. (demangle_path): Increment/decrement the recursion counter upon entry and exit. Fail if the counter exceeds a fixed limit. (demangle_type): Likewise. (rust_demangle_callback): Initialise the recursion counter, disabling if requested by the option flags.	4 years ago
Alan Modra	9ff8aa7d41	Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu In trying to find a testcase for PR28827, I managed to hit a linker error in bfd_set_section_contents with a .branch_lt input section being too large for the output .branch_lt. bfd/ PR 28827 * elf64-ppc.c (ppc64_elf_size_stubs): Set section size to maxsize past STUB_SHRINK_ITER before laying out. Remove now unnecessary conditional setting of maxsize at start of loop. ld/ * testsuite/ld-powerpc/pr28827-2.d, * testsuite/ld-powerpc/pr28827-2.lnk, * testsuite/ld-powerpc/pr28827-2.s: New test. * testsuite/ld-powerpc/powerpc.exp: Run it.	4 years ago
Tom Tromey	a634f5af2f	Remove unused variables in fbsd-tdep.c files i386-fbsd-tdep.c and amd64-fbsd-tdep.c failed to build on my x86-64 Fedora 34 machine, using the system gcc, after a recent patch. These two files now have unused variables, which provokes a warning in this configuration. I'm checking in this patch to remove the unused variables.	4 years ago
GDB Administrator	fb0a17c77d	Automatic date update in version.in	4 years ago
GDB Administrator	35b5767cf4	Automatic date update in version.in	4 years ago
Alan Modra	2405fc4016	Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu The previous patch wasn't quite correct. The size and padding depends on offset used in the current iteration, and if we're fudging the offset past STUB_SHRINK_ITER then we'd better use that offset. We can't have plt_stub_pad using stub_sec->size as the offset. PR 28827 * elf64-ppc.c (plt_stub_pad): Add stub_off param. (ppc_size_one_stub): Set up stub_offset to value used in this iteration before sizing the stub. Adjust plt_stub_pad calls.	4 years ago
Alan Modra	7c4643efe7	objcopy --only-keep-debug From: Peilin Ye <peilin.ye@bytedance.com> objcopy's --only-keep-debug option has been broken for ELF files since commit `8c803a2dd7`. 1. binutils/objcopy.c:setup_section() marks non-debug sections as SHT_NOBITS, then calls bfd_copy_private_section_data(); 2. If ISEC and OSEC share the same section flags, bfd/elf.c:_bfd_elf_init_private_section_data() restores OSEC's section type back to ISEC's section type, effectively undoing "make_nobits". * objcopy.c (setup_section): Act on make_nobits after calling bfd_copy_private_section_data.	4 years ago
GDB Administrator	5800c9abd0	Automatic date update in version.in	4 years ago
John Baldwin	e5783467a3	gdb: fix ppc-sysv-tdep.c build on 32-bit platforms The previous code triggered the following error on an i386 host: /git/gdb/gdb/ppc-sysv-tdep.c:1764:34: error: non-constant-expression cannot be narrowed from type 'ULONGEST' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing] unscaled.read ({writebuf, TYPE_LENGTH (valtype)}, ^~~~~~~~~~~~~~~~~~~~~ /git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH' ^~~~~~~~~~~~~~~~~~ /git/gdb/gdb/ppc-sysv-tdep.c:1764:34: note: insert an explicit cast to silence this issue unscaled.read ({writebuf, TYPE_LENGTH (valtype)}, ^~~~~~~~~~~~~~~~~~~~~ static_cast<size_t>( ) /git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH' ^~~~~~~~~~~~~~~~~~ 1 error generated. Fix this by using gdb::make_array_view.	4 years ago
John Baldwin	00d7af046f	FreeBSD x86 nat: Use register maps for GP register sets. Rather than using the x86-specific register offset tables, use register maps to describe the layout of the general purpose registers fetched via PT_GETREGS. The sole user-visible difference is that FreeBSD/amd64 will now report additional segment registers ($ds, $es, $fs, and $gs) for both 32-bit and 64-bit processes. As part of these changes, the FreeBSD x86 native targets no longer use amd64-bsd-nat.c or i386-bsd-nat.c. Remove FreeBSD-specific register handling (for $fs_base, $gs_base, and XSAVE state) from these files. Similarly, remove the global x86bsd_xsave_len from x86-bsd-nat.c. The FreeBSD x86 native targets use a static xsave_len instead. While here, rework the probing of PT_GETXMMREGS on FreeBSD/i386. Probe the ptrace op once in the target read_description method and cache the result for the future similar to the way the status of XSAVE support is probed in the read_description method. In addition, return the proper xcr0 mask (X87-only) for old kernels or systems without either XSAVE or XMM support.	4 years ago
John Baldwin	b95a31ed5d	fbsd-nat: Return a bool from fetch_register_set and store_register_set. Change these helper functions to return true if they did any work.	4 years ago
John Baldwin	7384826ebf	FreeBSD x86: Use tramp-frame for signal frames. Use a register map to describe the registers in mcontext_t as part of the signal frame as is done on several other FreeBSD arches. This permits fetching the fsbase and gsbase register values from the signal frame for both amd64 and i386 and permits fetching additional segment registers stored as 16-bit values on amd64. While signal frames on FreeBSD do contain floating point/XSAVE state, these unwinders do not attempt to supply those registers. The existing x86 signal frame uwinders do not support these registers, and the only existing functions which handle FSAVE/FXSAVE/XSAVE state all work with regcaches. In the future these unwinders could create a tempory regcache, collect floating point registers, and then supply values out of the regcache into the trad-frame.	4 years ago
John Baldwin	a423c9f392	Use register maps for gp regsets on FreeBSD/x86 core dumps. In particular, this permits reporting the value of the $ds, $es, $fs, and $gs segment registers from amd64 core dumps since they are stored as 16-bit values rather than the 32-bit size assumed by i386_gregset.	4 years ago
John Baldwin	b623bbc9a5	regcache: Zero-extend small registers described by a register map. When registers are supplied via regcache_supply_register from a register block described by a register map, registers may be stored in slots smaller than GDB's native register size (e.g. x86 segment registers are 16 bits, but the GDB registers for those are 32-bits). regcache_collect_regset is careful to zero-extend slots larger than a register size, but regcache_supply_regset just used regcache::raw_supply_part and did not initialize the upper bytes of a register value. trad_frame_set_reg_regmap assumes these semantics (zero-extending short registers). Upcoming patches also require these semantics for handling x86 segment register values stored in 16-bit slots on FreeBSD. Note that architecturally x86 segment registers are 16 bits, but the x86 gdb architectures treat these registers as 32 bits.	4 years ago

... 2 3 4 5 6 ...

109083 Commits (216722984fec8aa76e2d97d7b8fcc2fb1608825b) All Branches Search

109083 Commits (216722984fec8aa76e2d97d7b8fcc2fb1608825b)

All Branches