aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi42-144/+147
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06gdb: remove SYMBOL_IMPL macro, add methodSimon Marchi1-7/+11
Add a getter for a symbol's "impl". Remove the corresponding macro and adjust all callers. Change-Id: Ibe26ed442f0f99a0f5cddafca30bd96ec7fb9fa8
2022-02-06gdb: remove SYMBOL_ACLASS_INDEX macro, add getter/setterSimon Marchi9-96/+105
Add a getter and a setter for a symbol's aclass index. Remove the corresponding macro and adjust all callers. Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
2022-02-06gdb: remove SYMBOL_MATCHES_SEARCH_NAMESimon Marchi3-9/+4
It seems like this macro is not needed at all anymore, it just wraps the function of the same name with the same arguments. Change-Id: I3c342ac8d89c27af5aee1a819dc32cc6396fd41b
2022-02-06gdb: remove SYMTAB_DIRNAME macroSimon Marchi4-13/+19
Remove the macro, replace with an equivalent method. Change-Id: I46ec36b91bb734331138eb9cd086b2db01635aed
2022-02-06gdb: remove SYMTAB_PSPACE macroSimon Marchi5-23/+32
Remove the macro, replace with an equivalent method. Change-Id: Icccc20e7e8ae03ac4dac1c7514c25a12a9a0ac69
2022-02-06gdb: remove SYMTAB_OBJFILE macroSimon Marchi16-39/+45
Remove the macro, replace with an equivalent method. Change-Id: I8f9ecd290ad28502e53c1ceca5006ba78bf042eb
2022-02-06gdb: remove SYMTAB_BLOCKVECTOR macroSimon Marchi14-26/+32
Remove the macro, replace with an equivalent method. Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
2022-02-06gdb: remove SYMTAB_LANGUAGE macro, add getter/setterSimon Marchi11-22/+33
Add a getter and a setter for a symtab's language. Remove the corresponding macro and adjust all callers. Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
2022-02-06gdb: remove SYMTAB_LINETABLE macro, add getter/setterSimon Marchi11-57/+64
Add a getter and a setter for a symtab's linetable. Remove the corresponding macro and adjust all callers. Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c
2022-02-06gdb: remove SYMTAB_COMPUNIT macro, add getter/setterSimon Marchi13-27/+37
Add a getter and a setter for a symtab's compunit_symtab. Remove the corresponding macro and adjust all callers. For brevity, I chose the name "compunit" instead of "compunit_symtab" the the field, getter and setter names. Since we are already in symtab context, the _symtab suffix seems redundant. Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92
2022-02-06gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setterSimon Marchi5-9/+17
Add a getter and a setter for a compunit_symtab's macro table. Remove the corresponding macro and adjust all callers. Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a
2022-02-06gdb: remove COMPUNIT_EPILOGUE_UNWIND_VALID macro, add getter/setterSimon Marchi4-5/+14
Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag. Remove the corresponding macro and adjust all callers. Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a
2022-02-06gdb: remove COMPUNIT_LOCATIONS_VALID macro, add getter/setterSimon Marchi3-5/+14
Add a getter and a setter for a compunit_symtab's locations valid flag. Remove the corresponding macro and adjust all callers. Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01
2022-02-06gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setterSimon Marchi6-8/+17
Add a getter and a setter for a compunit_symtab's block line section. Remove the corresponding macro and adjust all callers. Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455
2022-02-06gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setterSimon Marchi15-39/+48
Add a getter and a setter for a compunit_symtab's blockvector. Remove the corresponding macro and adjust all callers. Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
2022-02-06gdb: remove COMPUNIT_DIRNAME macro, add getter/setterSimon Marchi7-14/+21
Add a getter and a setter for a compunit_symtab's dirname. Remove the corresponding macro and adjust all callers. Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
2022-02-06gdb: remove COMPUNIT_PRODUCER macro, add getter/setterSimon Marchi10-25/+33
Add a getter and a setter for a compunit_symtab's producer. Remove the corresponding macro and adjust all callers. Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
2022-02-06gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setterSimon Marchi8-9/+18
Add a getter and a setter for a compunit_symtab's debugformat. Remove the corresponding macro and adjust all callers. Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975
2022-02-06gdb: remove COMPUNIT_FILETABS macroSimon Marchi7-24/+24
I think that most remaining uses of COMPUNIT_FILETABS intend to get the primary filetab of the compunit_symtab specifically (and not to iterate over all filetabs, for example, those cases would use compunit_filetabs, which has been converted to compunit_symtab::filetabs), so replace mosts uses with compunit_symtab::primary_filetab. In jit.c, function finalize_symtab, we can save the symtab object returned by allocate_symtab and use it, it makes things simpler. Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
2022-02-06gdb: move compunit_filetabs to compunit_symtab::filetabsSimon Marchi7-41/+39
Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a method of compunit_symtab. The name filetabs conflicts with the current name of the field. Rename the field to m_filetabs, since at this point nothing outside of compunit_symtab uses it, so we should treat it as private (even though it's not actually private). Rename the last_filetab field to m_last_filetab as well (it's only used on compunit_symtab::add_filetab). Adjust the COMPUNIT_FILETABS macro to keep its current behavior of returning the first filetab. Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3
2022-02-06gdb: add compunit_symtab::set_primary_filetab methodSimon Marchi3-22/+36
Add a method to set the primary filetab of the CU. This is currently done in buildsym_compunit::end_symtab_with_blockvector. Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74
2022-02-06gdb: add compunit_symtab::add_filetab methodSimon Marchi2-10/+15
Add a method to append a filetab/symtab to a compunit_symtab. There is a single place where this is done currently, in allocate_symtab. Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d
2022-02-06gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetabSimon Marchi7-17/+15
Make compunit_primary_filetab a method of compunit_symtab. Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768
2022-02-06gdb: remove COMPUNIT_OBJFILE macroSimon Marchi7-14/+13
Remove the macro, update all users to use the getter directly. Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6
2022-02-06gdb: add getter/setter for compunit_symtab::objfileSimon Marchi4-8/+18
Rename the field to m_objfile, and add a getter and a setter. Update all users. Change-Id: If7e2f763ee3e70570140d9af9261b1b056253317
2022-02-06Allow non-ASCII characters in Rust identifiersTom Tromey3-18/+129
Rust 1.53 (quite a while ago now) ungated the support for non-ASCII identifiers. This didn't work in gdb. This is PR rust/20166. This patch fixes the problem by allowing non-ASCII characters to be considered as identifier components. It seemed simplest to just pass them through -- doing any extra checking didn't seem worthwhile. The new test also verifies that such characters are allowed in strings and character literals as well. The latter also required a bit of work in the lexer. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20166
2022-02-06Fix Rust parser bug with function fieldsTom Tromey4-1/+105
In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a function-valued field 'f' in 'obj'. The Rust parser in gdb currently gets this wrong. This is PR rust/24082. The expression and Rust parser rewrites made this simple to fix -- simply wrapping a parenthesized expression in a new operation handles it. This patch has a slight hack because I didn't want to introduce a new exp_opcode enumeration constant just for this. IMO this doesn't matter, since we should work toward removing dependencies on these opcodes anyway; but let me know what you think of this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24082
2022-02-06gdb/doc: update docs for 'info win' and 'winheight' commandsAndrew Burgess1-6/+7
This started by noticing that the docs for 'winheight' are out of date, the docs currently give a specific list of possible window names. However, now that windows can be implemented in Python, it is not possible to list all possible names. I now link the user to a mechanism by which they can discover the valid names for themselves at run time (by using 'info win'). That, and the fact that gdb provides tab-completion of the name at the command line, feels good enough. Finally, I noticed that the docs for 'win info' don't explicitly say that the name of the window is given in the output. This could probably have been inferred, but given I'm now linking to this as a mechanism to find the window name, I'd prefer to mention that the name can be found in the output.
2022-02-06gdb/tui: add window width information to 'info win' outputAndrew Burgess3-1/+68
Now that we support horizontal window placement in the tui, it makes sense to have 'info win' include the width, as well as the height, of the currently visible windows. That's what this commit does. Example output is now: (gdb) info win Name Lines Columns Focus src 12 40 (has focus) asm 12 41 status 1 80 cmd 11 80 I've added a NEWS entry, but the documentation was already suitably vague, it just says that 'info win' displays the size of the visible windows, so I don't think anything needs to be added there. I've also added some tests, as far as I could find, the 'info win' command was previously untested.
2022-02-04gdb: include jit_code_entry::symfile_addr value in names of objfiles created ↵Simon Marchi2-16/+29
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
2022-02-04Improve Ada unchecked union type printingTom Tromey3-29/+42
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.
2022-02-04Remove host_hex_valueTom Tromey6-27/+8
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.
2022-02-03testsuite: fix failure in gdb.threads/killed-outside.expTankut Baris Aktemur1-2/+2
Starting with commit commit 1da5d0e664e362857153af8682321a89ebafb7f6 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.
2022-02-02gdb: fix formatting for help set/show extended-promptAndrew Burgess1-3/+2
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.
2022-02-02gdb: test to check one aspect of the linespec parsing codeAndrew Burgess2-0/+10
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.
2022-02-02gdb: handle calls to edit command passing only a linespec conditionAndrew Burgess2-13/+20
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
2022-02-02gdb: handle calls to list command passing only a linespec conditionAndrew Burgess2-0/+24
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
2022-02-02gdb/testsuite: move linespec test into gdb.linespec/ directoryAndrew Burgess1-1/+1
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.
2022-02-02gdb: add empty string check in parse_linespecAndrew Burgess1-7/+7
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
2022-02-02gdb: update the comment on string_to_event_locationAndrew Burgess1-5/+4
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.
2022-02-01Fix flex rule in gdbTom Tromey1-14/+13
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.
2022-02-01gdb, btrace: improve error messagesMarkus Metzger1-2/+19
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>
2022-02-01gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled codeJan Vrany2-1/+11
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.
2022-02-01hurd: Fix RPC prototypesSamuel Thibault1-9/+9
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
2022-01-31hurd: Fix RPC link namesSamuel Thibault1-1/+1
The RPC stub code expects to be calling a C function, not a C++ function. Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f
2022-01-31gdb: fix some clang-tidy readability-misleading-indentation warningsSimon Marchi7-15/+15
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
2022-01-31gdb, testsuite, fortran: adapt info symbol expected output for intel compilersNils-Christian Kempke1-2/+27
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>
2022-01-30Remove unused variables in fbsd-tdep.c filesTom Tromey2-4/+0
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.
2022-01-28gdb: fix ppc-sysv-tdep.c build on 32-bit platformsJohn Baldwin1-1/+2
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.
generated by cgit v1.1 at 2025-09-21 00:04:21 +0000