aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2024-05-17Remove gdb_stdtargerrTom Tromey12-21/+3
This patch removes gdb_stdtargerr. There doesn't seem to be a need for this -- it is always the same as stdtarg, and (I believe) has been for many years. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17Don't allow new-ui to start the TUITom Tromey7-5/+25
The TUI can't really work properly with new-ui, at least not as currently written. This patch changes new-ui to reject an attempt. Attempting to make a DAP ui this way is also now rejected. Regression tested on x86-64 Fedora 38. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17Inline some ui_out methodsTom Tromey2-50/+10
I noticed a few ui_out methods that are just trivial wrappers. This patch moves these to ui-out.h, as it seems like they should be inlineable. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-17gdb/symtab: use symbol name matcher for all segments in a qualified nameDmitry Neverov1-10/+25
2024-05-17gdb/symtab: compute match_type outside the loopDmitry Neverov1-2/+3
It will be used for all segments in a qualified name, not only the last one. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-17gdb/symtab: reuse last segment lookup name info by creating it outside the loopDmitry Neverov1-3/+3
2024-05-17gdb/symtab: check name matches before expanding a CUDmitry.Neverov1-3/+19
The added check fixes the case when an unqualified lookup name without template arguments causes expansion of many CUs which contain the name with template arguments. This is similar to what dw2_expand_symtabs_matching_symbol does before expanding the CU. In the referenced issue the lookup name was wxObjectDataPtr and many CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused their expansion and the lookup took around a minute. The added check helps to avoid the expansion and makes the symbol lookup to return in a second or so. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520
2024-05-16[gdb/testsuite] Add missing terminator in Dwarf::_macro_unitTom de Vries2-0/+13
When printing complaints with one of the execs from test-case gdb.dwarf2/macro-source-path.exp, we run into: ... $ gdb -q -batch \ -iex "set complaints 100" \ macro-source-path-clang14-dw4-absolute-cwd-32 \ -ex "p main" During symbol reading: debug info runs off end of .debug_macro section \ [in module macro-source-path-clang14-dw4-absolute-cwd-32] $1 = {int ()} 0x4004b7 <main> ... and readelf complains more specifically: ... Contents of the .debug_macro section: Offset: 0 Version: 5 Offset size: 4 Offset into .debug_line: 0xe3 DW_MACRO_define - lineno : 0 macro : ONE 1 DW_MACRO_define_strp - lineno : 0 macro : THREE 3 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c DW_MACRO_define - lineno : 1 macro : TWO 2 DW_MACRO_end_file readelf: Error: .debug_macro section not zero terminated ... Fix this by adding the missing terminator in Dwarf::_macro_unit. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: remove unused includes in objfiles.{c,h}Simon Marchi2-9/+0
Remove some includes reported as unused by clangd. Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a
2024-05-16gdb, testsuite: Handle unused compiler option fdiagnostics-color=never.Ijaz, Abdul B1-10/+44
The 'univeral_compile_options' in gdb.exp file only verifies the support of '-fdiagnostics-color=never' for the "C" source file. So while running tests with assembly source file (.s), many of them are not able to run on icx/clang compilers because '-fdiagnostics-color=never' option is not supported. This problem is not seen for the ".S" assembly source files so these files are not handled separately. After this change, this function is split into multiple functions to check the support for different type of sources individually. Before this change, in the case of clang and ICX compiler, this error is shown for assembly source files (.s): ''' icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300) icx: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] gdb compile failed, icx: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare ''' Similarly this error is shown for the clang compiler: ''' clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s clang: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument] ''' Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: define type aliases for `fork_inferior()` callbacksSimon Marchi2-15/+18
The `fork_inferior()` function accepts multiple callbacks, making its signature a bit hard to read. Define some type aliases to make it a bit clearer. Use function view for all, while at it. Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: initialize packet_result::m_textual_err_msgSimon Marchi1-1/+1
When building GDB with -O2 and --enable-ubsan, I get some random errors in the packet_result self test: /home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool' This happens because packet_result::m_textual_err_msg is uninitialized when using the second constructor. When such a packet_result object gets copied, an invalid value for m_textual_err_msg (a bool field) is loaded, which triggers ubsan. Avoid this by initializing m_textual_err_msg. Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16gdb: remove unused include in infcmd.cSimon Marchi1-1/+0
clangd reports this header as unused. Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b
2024-05-16gdb: remove unused includes from progspace.{c,h}Simon Marchi2-3/+0
Remove some include files reported as unused by clangd. Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a
2024-05-16gdb: move lm_info to solib in dsbt_current_sosSimon Marchi1-0/+1
Commit 8971d2788e79 ("gdb: link so_list using intrusive_list") mistakenly removed the line that moves the lm_info unique pointer to sop->lm_info, probably due to a bad conflict resolution. Restore that line. Unfortunately, this code is only used for TI C66, which is not widely tested (if used at all). Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16Stop 'configure --enable-threading' if std::thread doesn't workPedro Alves1-3/+11
Currently, if you configure gdb with explicit --enable-threading, but then configure detects std::thread does not work, configure silently disables threading support and continues configuring. This patch makes that scenario cause a configuration error, like so: $ /home/pedro/gdb/src/configure --enable-threading && make ... configure: error: std::thread does not work; disable threading make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' make: *** [Makefile:1041: all] Error 2 $ Additionally, if you don't explicitly pass --enable-threading, and std::thread does not work, we will now get a warning (and the build continues): $ /home/pedro/gdb/src/configure && make ... configure: WARNING: std::thread does not work; disabling threading ... This is similar to how we handle --enable-tui and missing curses. The code and error/warning messages were borrowed from there. Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-16[gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assemblyTom de Vries2-1/+29
Add support for DW_MACRO_define_strp in dwarf assembly, and use it in test-case gdb.dwarf2/macro-source-path.exp. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-14Add spaceship operator to cp-name-parser.yTom Tromey1-1/+18
While debugging gdb, I saw this: During symbol reading: unexpected demangled name 'operator<=><std::chrono::_V2::system_clock, std::chrono::duration<long int>, std::chrono::duration<long int> >' This happens because cp-name-parser.y does not handle the spaceship operator. This patch implements this. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Allow function types as template parameters in name canonicalizerTom Tromey2-7/+4
This adds function types as template parameters in the C++ name canonicalizer. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Implement C++14 numeric separatorsTom Tromey3-10/+53
C++14 allows the use of the apostrophe as a numeric separator; that is, "23000" and "23'000" represent the same number. This patch implements this for gdb's C++ parser and the C++ name canonicalizer. I did this unconditionally for all C variants because I think it's unambiguous. For the name canonicalizer, there's at least one compiler that can emit constants with this form, see bug 30845. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Fix C++ canonicalization of hex literalsTom Tromey1-5/+56
Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to different things. I think it's nicer for them to be the same. Differences between types can be done using suffixes like "ll" and "u" -- it's not really possible to implement C++ rules in the canoncalizer, because no gdbarch is available. Possibly gdb should even drop the type here and just represent all integers the same way in names. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Remove some unnecessary allocations from cpname_state::parse_numberTom Tromey1-13/+12
cpname_state::parse_number allocates nodes for various types and then only uses one of them. This patch reduces the number of allocations by not performing the unnecessary ones. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Fix C++ name canonicalizations of character literalsTom Tromey1-6/+43
The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should canonicalize to the same string, but currently they do not -- the former remains unchanged and the latter is transformed to "void C<(char)'\001'>::m()". This patch fixes the bug and also adds some unit tests. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Change storage of demangle_componentTom Tromey3-81/+14
This changes demangle_component objects to be stored on the obstack that is part of demangle_info. It also arranges for a demangle_info object to be kept alive by cp_merge_demangle_parse_infos. This way, other data on the obstack can be kept while an "outer" demangle_info needs it. Acked-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Clean up demangle_parse_infoTom Tromey2-16/+4
This changes demangle_parse_info to use inline initializers and to remove some manual memory management. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Allow initialization functions in .y filesTom Tromey1-1/+3
If you add an initialization function to a .y file, it will not show up in init.c, because if the yacc output is in the build tree, it won't be found. This patch changes the Makefile to be more robust in this situation.
2024-05-14Remove test code from cp-name-parser.yTom Tromey3-153/+1
This removes the current test 'main' from cp-name-parser.y. There aren't any tests using this, and nowadays it would be better as a unit test. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-05-14Disallow trailing whitespace in docstringsTom Tromey8-15/+30
This patch changes the docstring self-test to verify that there is no trailing whitespace at the end of lines. A few existing docstrings had to be updated.
2024-05-14Remove fflush call from tui_refresh_cmd_winTom Tromey1-5/+0
tui_refresh_cmd_win calls fflush, but there's a comment explaining that the reason for the call is unknown. This patch removes the call. I don't think it can be useful, since gdb doesn't generally use stdout in this way -- only through ui_file.
2024-05-14gdb/doc: don't delete *.pod files too earlyAndrew Burgess1-4/+2
When doing 'make -C gdb/doc man' to build the man pages, I noticed that the outputs were being rebuilt each time the make command was rerun, even when the input files hadn't changed. This was caused by this commit: commit 824083f34c222aa7419e2ea58e82d6f230d5f531 Date: Fri Apr 12 17:47:20 2024 +0100 gdb/doc: use silent-rules.mk in the Makefile Which split the generation of the .pod file from the actual creation of the man page file. Prior to this split it was OK to delete the .pod file at the end of the recipe, the rule depending on the .texi input file, and output was the .1 or .5 man page file. Now however, with the split, the man page creation depends on the .pod file, if we delete this after creating the .1 or .5 man page file then the next time we run 'make' the .pod file is missing and is regenerated, which in turn triggers the regeneration of the man page file. Fix this by leaving the .pod file around, and only cleaning up these files in the 'mostlyclean' target. Which leads to a second problem, the POD_FILE_TMPS is not created correctly, so we don't actually clean up the .pod files! This too is fixed in this commit. After this commit running 'make -C gdb/doc man' will build the manual pages the first time, and each subsequent run will do nothing. Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-14gdb/testsuite: remove unnecessary -Wl,-soname,NAME build flagsAndrew Burgess4-14/+8
While working on another patch I needed to pass -Wl,-soname,NAME as a compiler flag. I initially looked for other tests that did this, and found a few examples, so I copied what they did. But when I checked the gdb.log file I noticed that we were actually getting -Wl,-soname passed twice. I tracked the repeated option to 'proc gdb_compile_shlib_1' in lib/gdb.exp. It turns out that we always add -Wl,-soname when compiling a shared library. Here's an example of a build command from gdb.base/prelink.exp: builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \ -fdiagnostics-color=never -shared -g \ -Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \ -o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so Notice that '-Wl,-soname,prelink.so' is repeated. I believe that all of the places where tests add '-Wl,-soname,NAME' as a build option, are unnecessary. In this commit I propose we remove them all. As part of this change I've switched from calling gdb_compile_shlib directly, to instead call build_executable and adding the 'shlib' flag. I've tested with gcc and clang and see no changes in the test results after this commit. All the compile commands still have -Wl,-soname added, but now it's only added once, from within lib/gdb.exp. There should be no change in what is tested after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-14Adjust C++ destructor type testsJason Merrill1-3/+3
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge" parameter from destructors of classes with no virtual bases; Linaro's CI informed me that the gdb testsuite needs to be adjusted to match. Teested against GCC 13.2 and GCC 15 trunk. Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-05-14Fix Segmentation Fault in AIX during multi process debugging.Aditya Vidyadhar Kamath1-1/+2
Due to the recent commit in aix-thread.c, we see a segmentation fault in AIX while debugging multiple process involving multiple threads. One example is a thread that can fork. The GDB output in AIX for the same is Reading symbols from //gdb_tests/multi-thread-fork... (gdb) set detach-on-fork off (gdb) r Starting program: /gdb_tests/multi-thread-fork [New Thread 258 (tid 67110997)] [New Thread 515 (tid 127404289)] [New inferior 2 (process 16580940)] Hello from Parent! [process 16580940 exited] [New inferior 3 (process 14549318)] Hello from Parent! [process 14549318 exited] Fatal signal: Segmentation fault ----- Backtrace ----- This is because in sync_threadlists () in aix-thread.c there when we delete threads in unknown state we iterate through all the threads. When we have one or more threads with the same user thread ID but of different process then we delete a wrong thread. Since we just check only the pdtid in in_queue_threads.count (priv->pdtid) == 0 this happened. This patch is a fix for the same. The output after we apply this patch is: Reading symbols from //gdb_tests/multi-thread-fork... (gdb) set detach-on-fork off (gdb) r Starting program: /gdb_tests/multi-thread-fork [New Thread 258 (tid 75565441)] [New Thread 515 (tid 63244397)] [New inferior 2 (process 10813892)] Hello from Parent! [New inferior 3 (process 19005888)] Hello from Parent! Thread 1.1 received signal SIGINT, Interrupt. 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) (gdb) info threads Id Target Id Frame * 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) 1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) 3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) (gdb) q A debugging session is active.
2024-05-11[gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.expTom de Vries1-1/+1
When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide container, I run into: ... temp/$pid/static-libc.c: In function 'main': temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function returning void [-Wreturn-mismatch] 2 | void main (void) { return 0; } | ^ ... UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link ... Fix this by changing the return type to int. Tested on x86_64-linux.
2024-05-10Change gdbarch_inner_than to return boolTom Tromey7-13/+13
A recent patch from Andrew pointed out that gdbarch_inner_than returns 'int', while it should really return 'bool'. Approved-By: Pedro Alves <pedro@palves.net>
2024-05-10Remove tui_refresh_allTom Tromey3-14/+5
This removes tui_refresh_all. There is only a single caller, tui_refresh_all_win, so inlining the code there simplifies gdb at no cost. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-10Add symbol, line, and location to DAP disassemble resultTom Tromey3-7/+209
The DAP spec allows a number of attributes on the resulting instructions that gdb currently does not emit. A user requested some of these, so this patch adds the 'symbol', 'line', and 'location' attributes. While the spec lets the implementation omit 'location' in some cases, it was simpler in the code to just always emit it, as then no extra tracking was needed.
2024-05-10Implement tp_richcompare for gdb.BlockTom Tromey1-1/+23
I noticed that two gdb.Block objects will never compare as equal with '=='. This patch fixes the problem by implementing tp_richcompare, as was done for gdb.Frame.
2024-05-10Simplify DAP make_source callersTom Tromey3-7/+8
A couple callers of make_source call basename by hand. Rather than add another caller like this, I thought it would be better to put this ability into make_source itself.
2024-05-10Remove FIXME from DAPTom Tromey1-1/+0
This patch removes one of the few DAP "FIXME" comments. This particular comment is already covered by PR dap/31036.
2024-05-10Pass stream to remote_console_outputTom Tromey1-8/+12
I noticed that remote_target::rcmd did not pass its ui_file argument down to remote_console_output. This patch fixes this oversight. Tested-By: Ciaran Woodward <ciaranwoodward@xmos.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-10gdb: add gdbarch_stack_grows_down functionAndrew Burgess3-6/+30
In another patch I'm working on I needed to ask: does the stack grow down, or grow up? Looking around I found in infcall.c some code where we needed to ask the same question, what we do there is ask: gdbarch_inner_than (gdbarch, 1, 2) which should do the job. However, I don't particularly like copying this, it feels like we're asking something slightly different that just happens to align with the question we're actually asking. I propose adding a new function `gdbarch_stack_grows_down`. This is not going to be a gdbarch method that can be overridden, instead, this will just call the gdbarch_inner_than function. We already have some gdbarch methods like this, checkout arch-utils.c for examples. I think it's now clearer what we're actually doing. A new self-test ensures that all architectures have a stack that either grows down, or grows up. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-10gdb sim testing, set gdb_protocol to "sim"Pedro Alves1-0/+4
Bernd reported that when testing with riscv-unknown-elf target using the simulator, before commit c7a2ee649115 ("gdb_is_target_native -> gdb_protocol_is_native"), he had: PASS: gdb.base/load-command.exp: probe for target native PASS: gdb.base/load-command.exp: check initial value of the_variable PASS: gdb.base/load-command.exp: manually change the_variable PASS: gdb.base/load-command.exp: check manually changed value of the_variable PASS: gdb.base/load-command.exp: reload: re-load binary PASS: gdb.base/load-command.exp: reload: check initial value of the_variable and now: UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command The problem is that the sim board/config isn't setting gdb_protocol anywhere, so gdb_protocol_is_native returns true. This commit fixes it by making gdb/testsuite/config/sim.exp set gdb_protocol to "sim". Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
2024-05-10[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup)Tom de Vries1-9/+17
In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust") I added this code in unwind_infopy_add_saved_register: ... if (value->optimized_out () || !value->entirely_available ()) ... which may throw c++ exceptions. This needs to be caught and transformed into a python exception. Fix this by using GDB_PY_HANDLE_EXCEPTION. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
2024-05-09Fix typo in gdb/README.Eli Zaretskii1-1/+1
Patch from Tiezhu Yang <yangtiezhu@loongson.cn>.
2024-05-09gdb: convert address_in_mem_range to mem_range::containsAndrew Burgess4-12/+10
Replace the global function address_in_mem_range with the member function mem_range::contains. The implementation of the function doesn't change. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-09gdb: add a new build_id_equal functionAndrew Burgess3-6/+29
Add two versions of a new function build_id_equal which can be used to compare build-ids, then make use of these functions in GDB. It seems better to have a specific function for the task of comparing build-ids rather than having a length check followed by a memcmp call. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-08gdb/doc: use silent-rules.mk in the MakefileAndrew Burgess2-85/+90
Make use of silent-rules.mk when building the GDB docs. During review it was requested that there be more specific rules than just reusing the general 'GEN' rule everywhere in the doc/ directory, so I've added: ECHO_DVIPS = @echo " DVIPS $@"; ECHO_TEX = @echo " TEX $@"; ECHO_PDFTEX = @echo " PDFTEX $@"; ECHO_TEXI2DVI = @echo " TEXI2DVI $@"; ECHO_MAKEHTML = @echo " MAKEHTML $@"; ECHO_TEXI2POD = @echo " TEXI2POD $@"; ECHO_TEXI2MAN = @echo " TEXI2MAN $@"; ECHO_MAKEINFO = @echo " MAKEINFO $@"; Then I've made use of these new silent rules and added lots of uses of SILENT to reduce additional clutter. As the man page generation is done in two phases, first the creation of a .pod file, then the creation of the final man page file, I've restructured the man page rules. Previously we had one rule for each of the 5 man pages. I now have one general rule that will generate all of the 5 .pod files, then I have two rules that convert the .pod files into the final man pages. I needed two rules for the man page generation as some man pages match %.1 and some match %.5. I could combine these by using the GNU Make .SECONDARYEXPANSION extension, but I think having two rules like this is probably clearer, and the duplication is minimal. Cleaning up the temporary .pod files is now moved into the 'mostlyclean' target rather than being done as soon as the man page is created. I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like SILENT_FLAG, but is set to '-q' when in silent mode, this can be used with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to mean: only report errors. As with the rest of the GDB makefiles, I've only converted the "generation" rules to use silent-rules.mk, the install / uninstall rules are left unchanged. When looking at the 'diststuff' target, which generates the info and man pages, I noticed the recipe for this rule just deleted a temporary file. As that temporary file is already cleaned up as part of the 'clean' rule I've removed the deletion from the 'diststuff' target. There are still a few "generation" targets that produce output, there seems to be no flag to silence the 'tex' and 'pdftex' commands which some recipes use, I've not worried about these for now, e.g. the refcard.dvi and refcard.pdf targets still produce some output. Luckily, when doing a 'make all' in the gdb/ directory, we only build the info docs by default, and those rules are now nice and silent, so a complete GDB build is now looking nice and quiet by default. While working on this patch I noticed that 'make -j all-doc' doesn't work (reliably), this is a preexisting bug in the way that dvi/pdf targets are generated. For example gdb.dvi and gdb.pdf both use the texi2dvi tool, which relies on temporary files to hold state. If both these rules run in parallel then one (or both) of the recipes will fail. Luckily, the default docs target (all), which is what gets run when we do 'make all' in the gdb/ directory, doesn't build the dvi and pdf targets, so we're OK in that case. I've not tried to fix this problem in this commit as it already existed, and I don't want to do too much in one commit. I mention it only because I ran into this issue while testing this commit.
2024-05-08gdb: Change "list ." command's error when no debuginfo is availableGuinevere Larsen6-13/+155
Currently, when a user tries to list the current location, there are 2 different error messages that can happen, either: (gdb) list . No symbol table is loaded. Use the "file" command. or (gdb) list . No debug information available to print source lines. The difference here is if gdb can find any symtabs at all or not, which is not something too important for end-users - and isn't informative at all. This commit changes it so that the error always says that there isn't debug information available, with these two variants: (gdb) list . Insufficient debug info for showing source lines at current PC (0x55555555511d). or (gdb) list . Insufficient debug info for showing source lines at default location. The difference now is if the inferior has started already, which is controlled by the user and may be useful. Unfortunately, it isn't as easy to differentiate if the symtab found for other list parameters is correct, so other invocations, such as "list +" still retain their original error message. Co-Authored-By: Simon Marchi <simark@simark.ca> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-08gdb: more filename stylingAndrew Burgess2-10/+16
I spotted a few places in solib.c and build-id.c where we could apply file name styling. Other than the extra styling, there should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2024-12-18 18:44:23 +0000