aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
10 daysUse an iterator range for 'using' directivesTom Tromey6-20/+9
This patch changes block::get_using to return an iterator range. This seemed cleaner to me than the current approach of returning a pointer to the first using directive; all the callers actually use this to iterate.
10 daysEnsure that help text fits in 80 columnsTom Tromey1-1/+9
This patch adds a new unit test that ensures that all help text wraps at 80 columns.
10 daysWrap help options when building help stringTom Tromey2-24/+42
When building a help string, it's possible that the resulting options will go over 80 columns. This patch changes this code to add line wrapping where needed. This can most be seen by looking "help bt" and in particular the "-frame-info" help text.
10 daysShorten internal problem help textTom Tromey1-8/+8
The help text for various "internal problem" settings is longer than 80 columns. This patch tightens this up a bit. Note that these commands are all "maint" commands so, IMO, it is sufficient if they are clear to a gdb developer. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
10 daysRemove the "title" from the remote packet helpTom Tromey1-4/+2
The help for remote packet controls includes the "title". However this is is just the parameter name, and not really useful to see repeated in the help text. Approved-By: Eli Zaretskii <eliz@gnu.org>
10 daysClean up opaque-type-resolution helpTom Tromey1-4/+4
The opaque-type-resolution help says "if set before loading symbols", but I don't think this is accurate. As far as I know, this resolution can be done at any time. This patch cleans up the help, also shortening it to less than 80 characters. Approved-By: Eli Zaretskii <eliz@gnu.org>
10 daysWrap help strings at 80 columnsTom Tromey21-80/+89
This patch ensures that all ordinary help strings are wrapped at 80 columns. For the most part this consists of changing code like this (note the embedded \n and the trailing backslash without a newline): -Manage the space-separated list of debuginfod server URLs that GDB will query \ -when missing debuginfo, executables or source files.\nThe default value is \ -copied from the DEBUGINFOD_URLS environment variable."), ... to end each line with \n\, like: +Manage the space-separated list of debuginfod server URLs that GDB will\n\ +query when missing debuginfo, executables or source files.\n\ +The default value is copied from the DEBUGINFOD_URLS environment variable."), Approved-By: Eli Zaretskii <eliz@gnu.org>
10 daysCall gdbpy_fix_doc_string_indentation for function helpTom Tromey1-0/+2
If you invoke "help function _caller_is", you'll see that the help text is indented strangely. The fix for this is to add a call to gdbpy_fix_doc_string_indentation in the appropriate spot, as is already done for Python commands and parameters.
10 daysAdd setting to control frame language mismatch warningTom Tromey7-6/+41
A customer noted that there is no way to prevent the "current language does not match this frame" warning. This patch adds a new setting to allow this warning to be suppressed. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
10 daysRe-run isortTom Tromey1-1/+1
pre-commit pointed out that one file needed a change to satisfy isort. This patch is the result.
10 daysgdb: fix missing operator % on xmethod matcher outputPedro Silva1-3/+8
Fixed missing operator % on xmethod matcher registration output and, as suggested on bug 32532, converted both uses of operator % to str.format. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32352 Change-Id: Ic471516292c2f1d6d1284aaeaea3ec14421decb8
10 daysgdb/dwarf2/read.c: Handle empty CU nameLancelot SIX3-0/+71
I recently came across a case where a compiler would emit a CU with an empty name. In such case, the attribute object constructed by GDB will return nullptr when as_string is called. One place is not checking for this possibility. As a result, loading such binary results in a GDB crash: $ gdb -q a.out Reading symbols from a.out... Fatal signal: Segmentation fault ----- Backtrace ----- [...] 0x742f4dd8afab __strcmp_avx2 ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 0x58593704a0bc prepare_one_comp_unit ../../gdb/dwarf2/read.c:21842 0x585937053fd9 process_psymtab_comp_unit ../../gdb/dwarf2/read.c:4633 0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_ ../../gdb/dwarf2/read.c:4943 [...] --------------------- A fatal error internal to GDB has been detected, further debugging is not possible. GDB will now terminate. This is a bug, please report it. For instructions, see: <https://www.gnu.org/software/gdb/bugs/>. Segmentation fault (core dumped) This seems to be a regression introduced by the following commit: commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36 Date: Tue Sep 24 10:24:22 2024 +0200 [gdb/symtab] Don't expand non-Ada CUs for info exceptions This patch fixes this issue by checking if attr->as_string returns nullptr. Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
11 daysgdb/python: implement Python find_exec_by_build_id hookAndrew Burgess15-235/+1615
Implement extension_language_ops::find_objfile_from_buildid within GDB's Python API. Doing this allows users to write Python extensions that can help locate missing objfiles when GDB opens a core file. A handler might perform some project- or site-specific actions to find a missing objfile. Or might provide some project- or site-specific advice to the user on how they can obtain the missing objfile. The implementation is very similar to the approach taken in: commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 Date: Sun Oct 15 22:48:42 2023 +0100 gdb: implement missing debug handler hook for Python The following new commands are added as commands implemented in Python, this is similar to how the Python missing debug and unwinder commands are implemented: info missing-objfile-handlers enable missing-objfile-handler LOCUS HANDLER disable missing-objfile-handler LOCUS HANDLER To make use of this extension hook a user will create missing objfile handler objects, and registers these handlers with GDB. When GDB opens a core file and encounters a missing objfile each handler is called in turn until one is able to help. Here is a minimal handler that does nothing useful: import gdb import gdb.missing_objfile class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler): def __init__(self): super().__init__("my_first_handler") def __call__(self, pspace, build_id, filename): # This handler does nothing useful. return None gdb.missing_objfile.register_handler(None, MyFirstHandler()) Returning None from the __call__ method tells GDB that this handler was unable to find the missing objfile, and GDB should ask any other registered handlers. Possible return values from a handler: - None: This means the handler couldn't help. GDB will call other registered handlers to see if they can help instead. - False: The handler has done all it can, but the objfile couldn't be found. GDB will not call any other handlers, and will continue without the objfile. - True: The handler has installed the objfile into a location where GDB would normally expect to find it. GDB should repeat its normal lookup process and the objfile should now be found. - A string: The handler can return a filename, which is the missing objfile. GDB will load this file. Handlers can be registered globally, or per program space. GDB checks the handlers for the current program space first, and then all of the global handles. The first handler that returns a value that is not None, has "handled" the missing objfile, at which point GDB continues. The implementation of this feature is mostly straight forward. I have reworked some of the missing debug file related code so that it can be shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is mostly content moved from gdb/python/lib/gdb/missing_debug.py, but updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py and the new file gdb/python/lib/gdb/missing_objfile.py both call into the missing_files.py file. For gdb/python/lib/gdb/command/missing_files.py this is even more extreme, gdb/python/lib/gdb/command/missing_debug.py is completely gone now and gdb/python/lib/gdb/command/missing_files.py provides all of the new commands in a generic way. I have made one change to the existing Python API, I renamed the attribute Progspace.missing_debug_handlers to Progspace.missing_file_handlers. I don't see this as too problematic. This attribute was only used to implement the missing debug feature and was never documented beyond the fact that it existed. There was no reason for users to be touching this attribute. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
11 daysgdb: add extension hook ext_lang_find_objfile_from_buildidAndrew Burgess7-27/+128
Add a new ext_lang_find_objfile_from_buildid function which is called from find_objfile_by_build_id and gives extension languages a chance to find missing objfiles. This commit adds the ext_lang_find_objfile_from_buildid function and the extension_language_ops::find_objfile_from_buildid() hook, but does not implement the hook for any extension languages, that will come in the next commit. This commit does rewrite find_objfile_by_build_id (build-id.c) to call the new hook though. The basic steps of find_objfile_by_build_id are now this: 1. Try to find the missing objfile using the build-id by looking in the debug-file-directory's .build-id/ sub-directory. If we find the file then we're done. 2. Ask debuginfod to download the missing file for us. If we download the file successfully then we're done. 3. Ask the extension language hook to find the file for us. If the extension language asks us to try again then we repeat step (1) only and if we still don't have the file, we move to step (4). If the extension language told us where the file is then we use that file and we're done. 4. We didn't find the file. Carry on without it. Only step (3) is new in this logic, everything else was already done. There are no tests added here as we can't currently write an extension language callback. The next commit will add the tests. Approved-By: Tom Tromey <tom@tromey.com>
11 daysgdb: rename ext_lang_missing_debuginfo_resultAndrew Burgess5-15/+15
In preparation for later commits in this series, rename ext_lang_missing_debuginfo_result to ext_lang_missing_file_result. A later commit will add additional Python APIs to handle different types of missing files beyond just debuginfo. This is just a rename commit, there should be no functional changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
11 daysgdb: use mapped file information to improve debuginfod textAndrew Burgess4-7/+60
When opening a core-file GDB is able to use debuginfod to download the executable that matches the core-file if GDB can find a build-id for the executable in the core-file. In this case GDB calls debuginfod_exec_query to download the executable and GDB prints a message like: Downloading executable for /path/to/core-file... which makes sense in that case. For a long time GDB has also had the ability to download memory-mapped files and shared libraries when opening a core-file. However, recent commits have made these cases more likely to trigger, which is a good thing, but the messaging from GDB in these cases is not ideal. When downloading a memory-mapped file GDB prints: Downloading executable for /path/to/memory-mapped-file And for a shared library: Downloading executable for /path/to/libfoo.so These last two messages could, I think, be improved. I propose making two changes. First, I suggest instead of using /path/to/core-file in the first case, we use the name of the executable that GDB is fetching. This makes the messaging consistent in that we print the name of the file we're fetching rather than the name of the file we're fetching something for. I further propose that we replace 'executable for' with the more generic word 'file'. The messages will then become: Downloading file /path/to/exec-file... Downloading file /path/to/memory-mapped-file... Downloading file /path/to/libfoo.so... I think these messages are clearer than what we used to have, and they are consistent in that we name the thing being downloaded in all cases. There is one tiny problem. The first case relies on GDB knowing the name of the executable it wants to download. The only place we can currently get that from is, I think, the memory-mapped file list. [ ASIDE: There is `bfd_core_file_failing_command` which reports the executable and argument list from the core file, but this information is not ideal for this task. First, the executable and arguments are merged into a single string, and second, the string is a relatively short, fixed length string, so the executable name is often truncated. For these reasons I don't consider fetching the executable name using this bfd function as a solution. ] We do have to consider the case that the core file does not have any mapped file information. This shouldn't ever be the case for a Linux target, but it's worth considering. [ ASIDE: I mention Linux specifically because this only becomes a problem if we try to do a lookup via debuginfod, which requires that we have build-ids available. Linux has special support for embedding build-ids into the core file, but I'm not sure if other kernels do this. ] For the unlikely edge case of a core-file that has build-ids, but doesn't have any mapped file information then I propose that we synthesis a filename like: 'with build-id xxxxxx'. We would then see a message like: Downloading file with build-id xxxxxx... Where 'xxxxxx' would be replaced by the actual build-id. This isn't ideal, but I think is good enough, and, as I said, I think this case is not going to be hit very often, or maybe at all. We already had some tests that emitted two of the above messages, which I've updated, these cover the mapped-file and shared library case. The message about downloading the exec for the core-file is actually really hard to trigger now as usually the exec will also appear in the memory-mapped file list and GDB will download the file at this stage. Then when GDB needs the executable for loading the symbols it'll ask debuginfod, and debuginfod will find the file in its cache, and so no message will be printed. If anyone has any ideas about how to trigger this case then I'm happy to add additional tests. Approved-By: Tom Tromey <tom@tromey.com>
13 daysAdd dw2-aranges.expAlexandra Hájková3-2/+77
This test checks that GDB is able to load DWARF information when .debug_aranges has a section address size that is set to 0. This test was originally written by Jan Kratochvil to test commit 927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer". This test was originally written using a static .S file and has been present in the Fedora tree for a long time. If dwarf2/aranges.c is modified to turn off the address_size check, GDB will crash with SIGFPE when loading the executable with address size set to zero. I modified the DWARF assembler to make it possible to set the address size to zero in a .debug_aranges section and used the DWARF assembler to produce the assembly file. Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com> Approved-by: Kevin Buettner <kevinb@redhat.com>
13 daysgdb: LoongArch: Remove use of gdbarch_remove_non_address_bits hookSchimpe, Christina1-8/+2
LoongArch doesn't implement the hook gdbarch_remove_non_address_bits, so there is no need to use the hook in gdb/loongarch-linux-nat.c. Approved-By: Luis Machado <luis.machado@arm.com>
13 daysgdb: make the error message for unreadable objfiles more informativeGuinevere Larsen1-2/+2
When GDB is unable to read an objfile, it prints the error message "I'm sorry Dave, I can't do that. Symbol format `%s' unknown.". While it is a great reference, an end user won't have much information about the problem. So far this wasn't much of a problem, as it is very uncommon for GDB to be unable to read an objfile. However, a future patch will allow users to selectively disable support to some formats, making it somewhat expected that the message will be seen by end users. This commit makes the end message more informative and direct. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13299 Approved-By: Tom Tromey <tom@tromey.com>
13 daysgdb/testsuite: fix gdb.base/basic-edit-cmd.exp testAndrew Burgess1-1/+4
In the recent commit: commit 31ada87f91b4c5306d81c8a896df9764c32941f3 Date: Wed Nov 6 22:18:55 2024 +0000 gdb: fixes and tests for the 'edit' command the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI highlighted an issue with the test which I failed to address before pushing the above commit. Part of the test loads a file into GDB and then uses the 'edit' command with no arguments to edit the default location. This default location is expected to be the 'main' function. On my local machine the line reported is the opening '{' of main, and that is what the test checks for. The Linaro CI though appears to see the first code line of main. I think either result is fine as far as this test is concerned, so I've expanded the test regexp to check for either line number. This should make the CI testing happy again.
13 daysgdb: fixes and tests for the 'edit' commandAndrew Burgess3-1/+211
This commit was inspired by this mailing list post: https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm When reviewing that patch, the first thing I wanted to do was add some tests for the 'edit' command because, as far as I can tell, there are no real tests right now. The approach I've taken for testing is to override the EDITOR environment variable, setting this to just 'echo'. Now when the 'edit' command is run, instead of entering an interactive editor, the shell instead echos back the arguments that GDB is trying to pass to the editor. The output might look like this: (gdb) edit +22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c (gdb) We can then test this like any other normal command. I then wrote some basic tests covering a few situations like, using 'edit' before the inferior is started. Using 'edit' without any arguments, and using 'edit' with a line number argument. There are plenty of cases that are still not tested, for example, the test program only has a single source file for example. But we can always add more tests later. I then used these tests to validate the fix proposed in the above patch. The patch above does indeed fix some cases, specifically, when GDB stops at a location (e.g. a breakpoint location) and then the 'edit' command without any arguments is fixed. But using the 'list' command to show some other location, and then 'edit' to edit the just listed location broken before and after the above patch. I am instead proposing this alternative patch which I think fixes more cases. When GDB stops at a location then 'edit' with no arguments should correctly edit the current line. And using 'list XX' to list a specific location, followed by 'edit' should also now edit the just listed location. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669 Co-Authored-By: Lluís Batlle i Rossell <viric@viric.name> Approved-By: Tom Tromey <tom@tromey.com>
13 days[gdb/tdep] Use raw_supply_zeroed in i387_supply_xsaveTom de Vries1-20/+19
Use reg_buffer::raw_supply_zeroed in i387_supply_xsave. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
13 days[gdb/tdep] Use raw_supply_zeroed for NIOS r0 regTom de Vries1-2/+1
Use reg_buffer::raw_supply_zeroed for NIOS register r0. Tested by rebuilding on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
13 days[gdb/tdep] Use raw_supply_zeroed for Alpha r31 regTom de Vries1-5/+1
Use reg_buffer::raw_supply_zeroed for Alpha register r31. Tested by rebuilding on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
13 days[gdb/tdep] Use raw_supply_zeroed for PA-RISC r0 regTom de Vries2-4/+2
Use reg_buffer::raw_supply_zeroed for PA-RISC register r0. Tested by rebuilding on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
13 days[gdb/tdep] Use raw_supply_zeroed for IA-64 gr0 and fr0 regsTom de Vries2-12/+4
Use reg_buffer::raw_supply_zeroed for IA-64 registers gr0 and fr0. Tested by rebuilding on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
14 daysDeprecate the ARM simulator.Nick Clifton1-1/+0
The ARM simulator is no longer able to simulator modern ARM cores, so it is being deprecated. Once this change has been active for a while - and assuming that no problems have been found - the ARm simulator codebase will be removed.
2024-11-06[gdb/tdep] Use raw_supply_zeroed for SPARC g0 regTom de Vries3-7/+3
Use reg_buffer::raw_supply_zeroed for SPARC register g0. Tested by rebuilding on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-11-06gdb: remove exact_match parameter from find_line_symtabKlaus Gerlicher3-17/+15
struct symtab *find_line_symtab (struct symtab *, int, int *, bool *); The last parameter is bool* that when set will receive information if the match was exact. This parameter is never used by any callsite and can therefore be removed. This will become: symtab *find_line_symtab (symtab *sym_tab, int line, int *index); Approved-By: Tom Tromey <tom@tromey.com>
2024-11-04Turn decode_line_2_compare_items into operator<Tom Tromey1-13/+9
This rewrites decode_line_2_compare_items to be an operator< on the relevant type. This simplifies the code a little. Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-11-04gdb: cleanup includes in *-typeprint.[ch]Simon Marchi6-8/+1
Remove includes reported as unused by clangd. Include "gdb-hashtab.h" in typeprint.h for the use of "htab_up". Change-Id: I5b04ec14e71800e2d6ad622838e39b7033e168cf
2024-11-04gdb: cleanup includes in gdbtypes.hSimon Marchi1-4/+0
Remove some includes reported as unused by clangd. Change-Id: Ifc74f782d5aaafd1d719816821860352090c6667
2024-11-04Remove gdb::hash_enumTom Tromey4-12/+4
gdb::hash_enum is a workaround for a small oversight in C++11: std::hash was not defined for enumeration types. This was rectified in C++14 and so we can remove the local workaround. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-11-04gdb: use option framework for add-inferior and clone-inferiorAndrew Burgess1-103/+188
Convert the add-inferior and clone-inferior commands to make use of the option framework. This improves the tab completion for these commands. Previously the add-inferior command used a trick to simulate completion of -exec argument. The command use filename completion for everything on the command line, thus you could do: (gdb) add-inferior /path/to/some/fil<TAB> and GDB would complete the file name, even though add-inferior doesn't really take a filename as an argument. This helped a little though because, if the user did this: (gdb) add-inferior -exec /path/to/some/fil<TAB> then the file name would be completed. However, GDB didn't really understand the options, so couldn't offer completion of the options themselves. After this commit, the add-inferior command makes use of the recently added gdb::option::filename_option_def feature. This means that the user now has full completion of the option names, and that file names will still complete for the '-exec' option, but will no longer complete if the '-exec' option is not used. I have also converted the clone-inferior command, though this command does not use any file name options. This command does now have proper completion of the command options.
2024-11-04gdb: add filename option supportAndrew Burgess5-18/+222
This commit adds support for filename options to GDB's option sub-system (see cli/cli-option.{c,h}). The new filename options support quoted and escaped filenames, and tab completion is fully supported. This commit adds the new option, and adds these options to the 'maintenance test-options' command as '-filename', along with some tests that exercise this new option. I've split the -filename testing into two. In gdb.base/options.exp we use the -filename option with some arbitrary strings. This tests that GDB can correctly extract the value from a filename option, and that GDB can complete other options after a filename option. However, these tests don't actually pass real filenames, nor do they test filename completion. In gdb.base/filename-completion.exp I have added some tests that test the -filename option with real filenames, and exercise filename tab completion. This commit doesn't include any real uses of the new filename options, that will come in the next commit.
2024-11-04gdb/testsuite: spring clean the gdb.stabs/gdb11479.exp testAndrew Burgess1-24/+30
I had reason to look at the gdb.stabs/gdb11479.exp test script and figured it could do with a small clean up. I've: - Made use of standard_testfile and the variables it defines. - Made use of with_test_prefix and removed the prefix from the end of each test name. - Avoid overwriting the test binary when we recompile, instead use a different name for each recompilation. - Add '.' at the end of each comment. There should be no changes in what is tested with this commit. Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-11-04Fix AIX core dump while main thread exits.Aditya Vidyadhar Kamath1-1/+1
Consider the test case: void *thread_main(void *) { std::cout << getpid() << std::endl; sleep(20); return nullptr; } int main(void) { pthread_t thread; pthread_create(&thread, nullptr, thread_main, nullptr); pthread_join(thread, nullptr); return 0; } This program creates a thread via main that sleeps for 20 seconds. When we debug this with gdb we get, Reading symbols from ./test... (gdb) b main Breakpoint 1 at 0x10000934: file test.c, line 11. (gdb) r Starting program: /read_only_gdb/binutils-gdb/gdb/test Breakpoint 1, main () at test.c:11 11 pthread_create(&thread, nullptr, thread_main, nullptr); (gdb) c Continuing. 15335884 [New Thread 258 (tid 31130079)] Thread 2 received signal SIGINT, Interrupt. [Switching to Thread 258 (tid 31130079)] 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) (gdb) thread 1 [Switching to thread 1 (Thread 1 (tid 25493845))] (gdb) c Continuing. [Thread 1 (tid 25493845) exited] [Thread 258 (tid 31130079) exited] inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ----- Backtrace ----- There are two bugs here. One is the core dump. The other is the main thread information not captured. So, while I was debugging the first part the reason, the reason I figured out was the last for loop in sync_threadlists (). Once both my threads exit we delete them as below: for (struct thread_info *it : all_threads ()) { if (in_queue_threads.count (priv->pdtid) == 0 && in_thread_list (proc_target, it->ptid) && pid == it->ptid.pid ()) { delete_thread (it); data->exited_threads.insert (priv->pdtid); But once these two threads are deleted, all_threads () has one more thread whose tid and pid are 0. gdb) c Continuing. In for loop 8782296 is pid, 19857879 is tid [Thread 1 (tid 19857879) exited] In for loop 8782296 is pid, 30933401 is tid [Thread 258 (tid 30933401) exited] In for loop 0 is pid, 0 is tid [Inferior 1 (process 8782296) exited normally] (gdb) q I used a printf in the for loop mentioned above for explaination. You see the loop enters the third time with 0 as pid. The reason being though the threads are removed but not deleted since they are not deletable (). Hence we use all_threads_safe () iterator instead. The second part to the bug is the lack of information of the main thread. Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html) Thank you Andrew. The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread failed. This returned EPERM as errno. if (!ptrace32 (PTT_READ_GPRS, tid, (uintptr_t) gprs32, 0, NULL)) memset (gprs32, 0, sizeof (gprs32)); Hence all registers were set to 0 and we did not get the required infromation. This issue will be fixed within the AIX ptrace call. Approved By: Ulrich Weigand <ulrich.weigand@de.ibm.com>.
2024-11-01Fix compile error due to [[noreturn]] with clangAndrew Oates1-1/+2
Since commit d9deb60b2e9e94b532f43a7d3ddddf5ddf6dbdd3, I get the following compiler error when building binutils (cross-compiling) on macos: CXX remote-sim.o ../../gdb/remote-sim.c:334:28: error: assigning to 'void (*)(host_callback *, const char *, ...) __attribute__((noreturn))' (aka 'void (*)(host_callback_struct *, const char *, ...) __attribute__((noreturn))') from incompatible type 'void (host_callback *, const char *, ...)' (aka 'void (host_callback_struct *, const char *, ...)') gdb_callback.error = gdb_os_error; ^~~~~~~~~~~~ 1 error generated. This appears to be due to the mismatch between ATTRIBUTE_NORETURN and [[noreturn]] on gdb_os_error. Reverting the change for gdb_os_error resolves the issue. Removing ATTTRIBUTE_NORETURN on the declaration of host_callback::error also works, but deprives the compiler of data. Tested by compiling on macos both with the system clang, as well as with GCC 14. With clang, remote-sim.c does not compile (per above) without this patch. With GCC, it compiles with and without the patch (it doesn't link, but AFAICT that is unrelated). The clang bug is reported upstream at https://github.com/llvm/llvm-project/issues/113511 Approved-By: Tom Tromey <tom@tromey.com>
2024-11-01Add gdb.events.tui_enabledTom Tromey10-0/+73
This adds a new event source so that Python scripts can track whether or not the TUI is presently enabled. v2 of the patch renames "status" -> "enabled". Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-10-31Prevent use-after-free of bfd filename in gdb_bfd_close_or_warnDomani Johannes1-2/+3
On Windows gcore is not implemented, and if you try it, you get an heap-use-after-free error: (gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test warning: cannot close "================================================================= ==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140 READ of size 111 at 0x1259ea503110 thread T0 #0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391 #1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558 #2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514 #3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41 #4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484 #5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106 #6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227 #7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571 #8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740 #9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73 #10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881 #11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181 #12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33 #13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437 #14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646 #15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 #16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 #17 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 #18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0) freed by thread T0 here: #0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90 #1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187 #2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247 #3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180 #4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960 #5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925 #6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643 #7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 #8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 #9 0x7ff68094b6f2 in gdb::ref_ptr<bfd, gdb_bfd_ref_policy>::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 #10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 It happens because gdb_bfd_close_or_warn uses a bfd-internal name for the failing-close warning, after the close is finished, and the name already freed: static int gdb_bfd_close_or_warn (struct bfd *abfd) { int ret; const char *name = bfd_get_filename (abfd); for (asection *sect : gdb_bfd_sections (abfd)) free_one_bfd_section (sect); ret = bfd_close (abfd); if (!ret) gdb_bfd_close_warning (name, bfd_errmsg (bfd_get_error ())); return ret; } Fixed by making a copy of the name for the warning. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-30gdb: Update SECURITY.txt to mention extension scripts and internal errorsGuinevere Larsen1-13/+38
Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update the gdb/SECURITY.txt to be more explicit about some details. Specifically, we now explicitly say that internal errors aren't security vulnerabilities, and mention that users should review plugins before running them, and under which conditions a plugin can cause a security bug. Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-30[gdb/tdep] Use std::array in amd64-windows-tdep.cTom de Vries1-24/+27
I noticed commit 84786372e1c ("Fix size of register buffer") fixing a stack-buffer-overflow found by AddressSanitizer in amd64_windows_store_arg_in_reg: ... - gdb_byte buf[8]; + gdb_byte buf[16]; ... and wondered if we could have found this without AddressSanitizer. I realized that the problem is that this: ... gdb_byte buf[N]; ... regcache->cooked_write (regno, buf); ... is using the deprecated variant of cooked_write instead of the one using gdb::array_view: ... /* Transfer of pseudo-registers. */ void cooked_write (int regnum, gdb::array_view<const gdb_byte> src); /* Deprecated overload of the above. */ void cooked_write (int regnum, const gdb_byte *src); ... and consequently cooked_write does not know the size of buf. Fix this by using std::array, and likewise in other places in gdb/amd64-windows-tdep.c. In the process I fixed another out of bounds access here: ... gdb_byte imm16[2]; ... cache->prev_sp = cur_sp + extract_unsigned_integer (imm16, 4, byte_order); ... where we're reading 4 bytes from the 2-byte buffer imm16. Tested by rebuilding on x86_64-linux. Tested-By: Hannes Domani <ssbssa@yahoo.de>
2024-10-29Fix signal unsafe call inside a signalBernd Edlinger4-9/+100
It can easily happen that the signal handler function `handle_fatal_signal` uses various signal unsafe functions. The problematic functions are `_` and `strsignal` which can be pre-computed after the `setlocale` call is done. Unfortunately when compiled with --disable-libbacktrace a different code path is used, that calls the glibc function `backtrace` which calls `malloc` and `free` and is therefore also signal unsafe, that is probably unfixable, so there is no attempt to fix anything in this code path. Approved-By: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9
2024-10-29[gdb/testsuite] Add read1 and readmore to make-check-all.shTom de Vries1-3/+42
There are two useful ways to run a test-case, that are not represented by a board file in gdb/testsuite/boards: check-read1 and check-readmore. Consequently, they're not run either by make-check-all.sh. Fix this by adding check-read1 and check-readmore to make-check-all.sh. Tested on x86_64-linux. Verified with shellcheck. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-10-29[gdb/symtab] Handle multiple .debug_info sectionsTom de Vries7-19/+109
When compiling dw2-multiple-debug-info.c using -gdwarf-5 -fdebug-types-section, we end with two .debug_info sections in the object file: ... $ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \ -gdwarf-5 \ -fdebug-types-section $ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info [10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8 [12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8 ... One of them contains the CU for dw2-multiple-debug-info.c, the other contains the TU for the type of variable a. When trying to print the type of variable a, we get: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" 'a' has unknown type; cast it to its declared type ... because the TU hasn't been read. Fix this by adding support for reading multiple .debug_info sections, similar to how that is done for multiple .debug_types sections, getting us instead: ... $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" type = class sp1::A { ... } ... Tested on x86_64-linux. PR symtab/32223 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
2024-10-29fortran: Fix arrays of variable length strings for FORTRANIjaz, Abdul B6-5/+219
Before this change resolve_dynamic_array_or_string was called for all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end, this function always called create_array_type_with_stride, which creates a TYPE_CODE_ARRAY type. Suppose we have subroutine vla_array (arr1, arr2) character (len=*):: arr1 (:) character (len=5):: arr2 (:) print *, arr1 ! break-here print *, arr2 end subroutine vla_array The "print arr1" and "print arr2" command at the "break-here" line gives the following output: (gdb) print arr1 $1 = <incomplete type> (gdb) print arr2 $2 = ('abcde', 'abcde', 'abcde') (gdb) ptype arr1 type = Type End Type (gdb) ptype arr2 type = character*5 (3) Dwarf info using Intel® Fortran Compiler for such case contains following: <1><fd>: Abbrev Number: 12 (DW_TAG_string_type) <fe> DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1 <102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8) After this change resolve_dynamic_array_or_string now calls create_array_type_with_stride or create_string_type, so if the incoming dynamic type is a TYPE_CODE_STRING then we'll get back a TYPE_CODE_STRING type. Now gdb shows following: (gdb) p arr1 $1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij') (gdb) p arr2 $2 = ('abcde', 'abcde', 'abcde') (gdb) ptype arr1 type = character*10 (5) (gdb) ptype arr2 type = character*5 (3) In case of GFortran, compiler emits DW_TAG_structure_type for string type arguments of the subroutine and it has only DW_AT_declaration tag. This results in <incomplete type> in gdb. So, following issue is raised in gcc bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826". Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp, i.e. the test forces the language to C/C++ and print a Fortran string value. The string value is a dynamic type with code TYPE_CODE_STRING. Before this commit the dynamic type resolution would always convert this to a TYPE_CODE_ARRAY of characters, which the C value printing could handle. But now after this commit we get a TYPE_CODE_STRING, which neither the C value printing, or the generic value printing code can support. And so, I've added support for TYPE_CODE_STRING to the generic value printing, all characters of strings are printed together till the first null character. Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp tests it expects type of character array in 'character (3)' format but now after this change we get 'character*3', so tests are updated accordingly. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28Fix size of register bufferHannes Domani1-1/+2
When calling a function with double arguments, I get this asan error: ==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40 READ of size 16 at 0x0053131ece38 thread T0 #0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814 #1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845 #2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840 #3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:874 #4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view<unsigned char const>) C:/gdb/src/gdb.git/gdb/regcache.c:914 #5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933 #6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216 Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame #0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208 This frame has 4 object(s): [32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable It's because the first 4 double arguments are passed via XMM registers, and they need a buffer of 16 bytes, even if we only use 8 bytes of them. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28Don't copy memory for arguments if there are noneHannes Domani1-0/+1
If amd64_windows_push_arguments is called with no arguments, then ARGS can be NULL, and inside the passed-by-pointer block, memcpy is called with this NULL, which is undefined behavior. So this just disable the passed-by-pointer block if there are no arguments. Fixes the following ubsan error: C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: add support to vzeroupper instructionGuinevere Larsen3-0/+73
This commit adds recording support for the AVX instruction vzeroupper, which zeroes the high bits of ymm registers 0..15. In the programmer's manual, it is explicitly states that ymm registers 16..31 won't be affected if present, so we only need to record the first 16 registers. We record ymm_h registers since only the higher bits are touched, and that reduces the memory footprint of the instruction. This instruction is tested differently as we want to confirm we're only saving the relevant registers, and we want to ensure we're saving all of them, so it makes use of "maint print record-instruction" to see exactly what was recorded. Approved-By: Tom Tromey <tom@tromey.com>
2024-10-28gdb/record: support AVX instructions VMOVDQ(U|A) when recordingGuinevere Larsen3-4/+115
This commit adds support for the instructions VMOVDQU and VMOVDQA, used to move values to/from 256 bit registers. Unfortunately, the programmer's manual is very incomplete (if not wrong) about these instructions, so the logic had to be reverse engineered from how gcc actually encodes the instruction. This commit also changes the memory regions from the test to store 256 bits, so its easier to test the instructions and that we're recording ymm registers correctly. Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2024-11-21 13:32:13 +0000