aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2022-04-21Fix for gdb.base/solib-search.exp test.Carl Love1-1/+1
The variable right_lib_flags is not being set correctly to define RIGHT. The value RIGHT is needed to force the address of the library functions lib1_func3 and lib2_func4 to occur at different address in the wrong and right libraries. With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur at different addresses the test runs correctly on Powerpc. The test needs the lib2 addresses to be different in the right and wrong cases. That is the point of introducing function lib2_spacer with the ifdef RIGHT compiler directive. On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the dynamic linker to move the addresses of the library. You can also get the same effect on PowerPC but you must use a value much larger than 8192. The key thing is that the test was not properly setting RIGHT to defined to get the lib2_spacer function on Intel and Powerpc. Without the patch, we have the Intel backtrace for the bad libraries: backtrace #0 break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7fae156 in ?? () #2 0x00007fffffffc150 in ?? () #3 0x00007ffff7fbb156 in ?? () #4 0x00007fffffffc160 in ?? () #5 0x00007ffff7fae146 in ?? () #6 0x00007fffffffc170 in ?? () #7 0x00007ffff7fbb146 in ?? () #8 0x00007fffffffc180 in ?? () #9 0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection) The backtrace on Intel with the good libraries is: backtrace #0 break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30 #1 0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49 #2 0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49 #3 0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30 #4 0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30 #5 0x0000555555555156 in main () at /...solib-search.c:23 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection) PASS: gdb.base/solib-search.exp: backtrace (with right libs) In one case the backtrace is correct and the other it is wrong on Intel. This is due to the fact that the ARRAY_SIZE caused the dynamic linker to move the library function addresses around. I believe it has to do with the default size of the data and code sections used by the dynamic linker. So without the patch the backtrace on PowerPC looks like: backtrace #0 break_here () at /.../solib-search.c:30 #1 0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49 #2 0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49 #3 0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30 #4 0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30 #5 0x000000001000074c in main () at /.../solib-search.c:23 for both the good and bad libraries. The patch fixes defining RIGHT in solib-search-lib1.c and solib-search- lib2.c. Note, without the patch the lib1_spacer and lib2_spacer functions do not show up in the object dump of the Intel or Powerpc libraries as it should. The patch fixes that by making sure RIGHT gets defined. Now with the patch the backtrace for the bad library on PowerPC looks like: backtrace #0 break_here () at /.../solib-search.c:30 #1 0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so Backtrace stopped: frame did not save the PC And the backtrace for the good libraries on PowerPC looks like: backtrace #0 break_here () at /.../solib-search.c:30 #1 0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49 #2 0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49 #3 0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30 #4 0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30 #5 0x000000001000074c in main () at /.../solib-search.c:23 (gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection) PASS: gdb.base/solib-search.exp: backtrace (with right libs) The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not sufficient to cause the dymanic linker to allocate the libraries at different addresses. I don't claim to understand the specifics of how the dynamic linker works and what the default size is for the data and code sections are. My guess is by default PowerPC allocates a larger data size by default, which is large enough to hold array[8192]. The default size of the data section allocated by the dynamic linker on Intel is not large enough to hold array[8192] thus causing the code section on Intel to have to move when the large array is defined. Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause the library addresses to occur at different addresses as the larger data section forces the code section to a different address. That was actually my original fix for the program until I spoke with Doug Evans who originally wrote the test. Doug noticed that RIGHT was not getting defined as he originally intended in the test. With the patch to fix the definition of RIGHT, PowerPC has a bad and a good backtrace because the address of lib1_func3 and lib2_func4 both move because lib1_spacer and lib2_spacer are now defined before lib1_func3 and lib2_func4. Without the patch, the lib1_spacer and lib2_spacer function doesn't show up in the binary for the correct or incorrect library on Intel or PowerPC. With the patch, RIGHT gets defined as originally intended for the test on both architectures and lib1_spacer and lib2_spacer function show up in the binaries on both architectures changing the other function addresses as intended thus causing the test work as intended on PowerPC.
2022-04-21gdb/dwarf: remove line_header::header_length fieldSimon Marchi2-3/+4
This can be a local in dwarf_decode_line_header. Change-Id: I2ecf4616d1a3197bd1e81ded9f999a2da9a685af
2022-04-21gdb/dwarf: remove line_header::total_length fieldSimon Marchi2-6/+5
This doesn' have to be a field, it can simply be a local variable in dwarf_decode_line_header. Name the local variable "unit_length", since that's what the field in called in DWARF 4 and 5. It's always easier to follow the code with the standard on the side when we use the same terminology. Change-Id: I3ad1022afd9410b193ea11b9b5437686c1e4e633
2022-04-21gdb/testsuite: fix "set temporary breakpoint" DUPLICATEsSimon Marchi6-16/+17
Commit c67f4e538 ("gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected location") introduced some DUPLICATEs in MI tests using mi_continue_to_line, for example: DUPLICATE: gdb.ada/mi_ref_changeable.exp: mi_continue_to_line: set temporary breakpoint These test names were previously differentiated by the location passed to mi_continue_to_line. Since the location can contain a path, that commit removed the location from the test name, in favor of a hardcoded string "set temporary breakpoint", hence removing the differentiator. mi_continue_to_line receives a "test" parameter, containing a test name. Add a "with_test_prefix" with that name, so that all tests recorded during mi_continue_to_line have this in their name. mi_continue_to_line passes that "test" string to mi_get_stop_line, that is a bit superfluous. mi_get_stop_line only uses that string in case of failures (it doesn't record a pass if everything goes fine). Since it's not crucial, just remove it, and adjust all callers. Adjust three gdb.mi/mi-var-*.exp tests to use prefixes to differentiate the multiple calls to mi_run_inline_test (which calls mi_continue_to_line). Change-Id: I511c6caa70499f8657b1cde37d71068d74d56a74
2022-04-21Always use dwarf2_initialize_objfileTom Tromey5-20/+8
Internally we noticed that some tests would fail like so on Windows: warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges. Debugging showed that, in fact, a second CU was being created at this offset. We tracked this down to the fact that, while the ELF reader is careful to re-use the per-BFD data, other readers are not, and could re-read the DWARF data multiple times. However, since the change to allow an objfile to have multiple "quick symbol" implementations, there's no reason for this approach -- it's safe and easy for all symbol readers to reuse the per-BFD data when reading DWARF. This patch implements this idea, simplifying dwarf2_build_psymtabs and making it private, and then switching to dwarf2_initialize_objfile as the sole way to start the DWARF reader. Note that, while I think the call to dwarf2_build_frame_info in machoread.c is also obsolete, I haven't attempted to remove it here.
2022-04-21gdb: fix 'remote show FOO-packet' aliasesAndrew Burgess2-4/+11
The following behaviour was observed in GDB: (gdb) show remote X-packet Support for the `p' packet is auto-detected, currently unknown. Note the message mentions the 'p' packet. This is a regression since this commit: commit 8579fd136a614985bd27f20539c7bb7c5a51287d Date: Mon Nov 8 14:58:46 2021 +0000 gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr Before this commit the behaviour was: (gdb) show remote X-packet Support for the `X' packet is auto-detected, currently unknown. The problem was caused by a failed attempt to ensure that some allocated strings were deleted when GDB exits. The code in the above commit attempted to make use of 'static' to solve this problem, however, the solution was just wrong. In this new commit I instead allocate a static vector into which all the allocated strings are stored, this ensures the strings are released when GDB exits (which makes output from tools like valgrind cleaner), but each string within the vector can be unique, which fixes the regression.
2022-04-21gdbsupport: add path_join functionSimon Marchi6-27/+100
In this review [1], Eli pointed out that we should be careful when concatenating file names to avoid duplicated slashes. On Windows, a double slash at the beginning of a file path has a special meaning. So naively concatenating "/" and "foo/bar" would give "//foo/bar", which would not give the desired results. We already have a few spots doing: if (first_path ends with a slash) path = first_path + second_path else path = first_path + slash + second_path In general, I think it's nice to avoid superfluous slashes in file paths, since they might end up visible to the user and look a bit unprofessional. Introduce the path_join function that can be used to join multiple path components together (along with unit tests). I initially wanted to make it possible to join two absolute paths, to support the use case of prepending a sysroot path to a target file path, or the prepending the debug-file-directory to a target file path. But the code in solib_find_1 shows that it is more complex than this anyway (for example, when the right hand side is a Windows path with a drive letter). So I don't think we need to support that case in path_join. That also keeps the implementation simpler. Change a few spots to use path_join to show how it can be used. I believe that all the spots I changed are guarded by some checks that ensure the right hand side operand is not an absolute path. Regression-tested on Ubuntu 18.04. Built-tested on Windows, and I also ran the new unit-test there. [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187559.html Change-Id: I0df889f7e3f644e045f42ff429277b732eb6c752
2022-04-21gdb_spawn_attach_cmdline: use unsupported instead of untestedLancelot SIX1-1/+1
In a previous commit (b750766ac96: gdb/testsuite: Introduce and use gdb_spawn_attach_cmdline), if gdb_spawn_attach_cmdline cannot have GDB attach to the process because of ptrace restrictions (operation not permitted), the proc issues UNTESTED. This should really be UNSUPPORTED, as it is done in gdb_attach. This patch fixes this oversight. Change-Id: Ib87e33b9230f3fa7a85e06220ef4c63814b71f7d
2022-04-21gdb/testsuite: add binary testcases to py-format-string.expEnze Li1-0/+37
We currently only test decimal and hexadecimal for the gdb.Value.format_string() interface, this patch adds testcases for binary format. Tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413").
2022-04-21gdb.debuginfod/fetch_src_and_symbols.exp: Fix "notice empty URL" testPedro Alves1-1/+1
The gdb_test_multiple pattern for the "notice empty URL" test in gdb.debuginfod/fetch_src_and_symbols.exp misses expecting the prompt. Fix it by using -re -wrap. Also, by using "confirm off", the message GDB prints if Debuginfod downloading is available doesn't contain "Enable debuginfod" any longer. E.g.: ~~~ (gdb) file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols... This GDB supports auto-downloading debuginfo from the following URLs: <http://localhost:123> Enable debuginfod for this session? (y or [n]) ~~~ ~~~ (gdb) with confirm off -- file testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols Reading symbols from testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols... This GDB supports auto-downloading debuginfo from the following URLs: <http://127.0.0.1:8000> <127.0.0.1:8000> Debuginfod has been disabled. To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. (No debugging symbols found in testsuite/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols) (gdb) ~~~ I handled that correctly in the other tests that use test_urls, but had forgotten to update the "notice empty URL" one. Change-Id: I00040c83466e1494b3875574eb009c571a1504bf
2022-04-20gdb/debuginfod: Prevent out_of_range exceptionAaron Merey2-3/+66
Trailing whitespace in the string of debuginfod URLs causes an out_of_range exception during the printing of URLs for the first use notice. To fix this, stop printing URLs when the substring to be printed consists only of whitespace. Also add first use notice testcases. Co-Authored-By: Pedro Alves <pedro@palves.net>
2022-04-20gdb/testsuite: Introduce and use gdb_spawn_attach_cmdlineLancelot SIX2-8/+49
Following a7e6a19e87f3d719ea23c65b580a6d9bca4ccab3 "gdb: testsuite: add new gdb_attach to check "attach" command", this commit proposes to introduce the gdb_spawn_attach_cmdline helper and use it in gdb.base/attach.exp. This helper starts GDB and adds the "--pid=$PID" argument. Also note that both the original and new implementation use gdb_spawn_with_cmdline_opts, which in the end uses default_gdb_spawn. This makes sure that we use $INTERNAL_GDBFLAGS, which by default already contain "-iex \"set height 0\" -iex \"set width 0\"". To avoid repetition of those arguments, gdb_spawn_attach_cmdline does not repeat those arguments. To maintain a behavior similat to what gdb.base/attach.exp used to do, gdb_spawn_attach_cmdline keeps the -quiet flag. Tested on x86_64-gnu-linux Change-Id: I1fdcdb71c86d9c5d34bb28fc86fac68bcec37358
2022-04-20Replace symbol_symtab with symbol::symtabTom Tromey20-76/+76
This turns symbol_symtab into a method on symbol. It also replaces symbol_set_symtab with a method.
2022-04-20Replace symbol_arch with symbol::archTom Tromey7-13/+13
This turns symbol_arch into a method on symbol.
2022-04-20Replace symbol_objfile with symbol::objfileTom Tromey13-29/+29
This turns symbol_objfile into a method on symbol.
2022-04-20Remove symbol::aclass_indexTom Tromey1-6/+1
Symbols have an aclass_index method, but this isn't needed, because the aclass index isn't useful outside of the symbol implementation.
2022-04-20Use array_view for symbol_implsTom Tromey2-2/+2
It seemed to me that using array_view for symbol_impls would give a bit more error checking, at least when gdb is built in libstdc++ debug mode.
2022-04-20Add accessors for symbol's artificial fieldTom Tromey3-6/+18
For a series I'm experimenting with, it was handy to hide a symbol's "artificial" field behind accessors. This patch is the result.
2022-04-20Unify the DWARF index holdersTom Tromey3-73/+72
The dwarf2_per_bfd object has a separate field for each possible kind of index. Until an earlier patch in this series, two of these were even derived from a common base class, but still had separate slots. This patch unifies all the index fields using the common base class that was introduced earlier in this series. This makes it more obvious that only a single index can be active at a time, and also removes some code from dwarf2_initialize_objfile.
2022-04-20Add an ad hoc version check to dwarf_scanner_baseTom Tromey2-2/+15
Some generic code in the DWARF reader has a special case for older versions of .gdb_index. This patch adds an ad hoc version check method so that these spots can work without specific knowledge of which index is in use.
2022-04-20Simplify version check in dw2_symtab_iter_nextTom Tromey1-5/+5
This simplifies the index versio check in dw2_symtab_iter_next, by passing a reference to the index object to this function. This avoids an indirection via the per_bfd object.
2022-04-20Introduce and use dwarf_scanner_baseTom Tromey3-8/+26
This introduces dwarf_scanner_base, a base class for all the index readers in the DWARF code. Then, it changes both mapped_index_base and cooked_index_vector to derive from this new base class.
2022-04-20Introduce readnow_functionsTom Tromey1-53/+56
This introduces readnow_functions, a new subclass of dwarf2_base_index_functions, and changes the DWARF reader to use it. This lets us drop the "index is NULL" hack from the gdb index code.
2022-04-20Remove some "OBJF_READNOW" code from dwarf2_debug_names_indexTom Tromey1-16/+1
The dwarf2_debug_names_index code treats a NULL debug_names_table as if it were from OBJF_READNOW. However, this trick is only done for gdb_index, never for debug_names -- see dwarf2_initialize_objfile.
2022-04-20Let mapped index classes create the quick_symbol_functions objectTom Tromey2-7/+28
This changes the mapped index classes to create the quick_symbol_functions objects. This is a step toward having a more abstract interface to mapped indices.
2022-04-20Give mapped_index_base a virtual destructorTom Tromey1-4/+1
This changes mapped_index_base to have a virtual destructor, so it can be destroyed via its base class.
2022-04-20Move mapped_index_base to new header fileTom Tromey3-72/+98
This moves mapped_index_base and the helper struct name_component to a new header file in gdb/dwarf2/.
2022-04-20Use symbol_symtab accessor in compile-object-load.cTom Tromey1-1/+1
I noticed that compile-object-load.c directly references owner.symtab of a symbol. However, I think it's better for all users to call symbol_symtab. This patch makes this change.
2022-04-20Micro-optimize cooked_index_entry::full_nameTom Tromey1-6/+5
I noticed that cooked_index_entry::full_name can return the canonical string when there is no parent entry. Regression tested on x86-64 Fedora 34.
2022-04-20gdb: LoongArch: Implement loongarch_scan_prologue()Tiezhu Yang1-1/+131
If can't determine prologue from the symbol table, need to examine instructions. Implement loongarch_scan_prologue() to analyze the function prologue from START_PC to LIMIT_PC, return the address of the first instruction past the prologue. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-04-19gdb/selftest-arch: Make register_test_foreach_arch generate arch tests lazilyLancelot SIX3-10/+47
The register_test_foreach_arch is used to instantiate a given selftest for all architectures supported by GDB. It is used in many _initialize_* functions (under initialize_all_files, called by gdb_init). Because the call is done during GDB's initialization, and because there is no guaranty about the order in which all the _initialize_* functions are executed, when register_test_foreach_arch is called, GDB is not fully initialized. Specifically, when a particular initialize function is executed, only the architectures registered at that point are listed by gdbarch_printable_names. As a consequence, the list of selftest effectively executed depends on the order the _initialize_* functions are called. This can be observed with the following: $ ./gdb/gdb \ -data-directory ./gdb/data-directory \ -quiet -batch -ex "maint selftest" 2>&1 \ | grep -E "Ran [0-9]+ unit tests" Ran 145 unit tests, 0 failed $ GDB_REVERSE_INIT_FUNCTIONS=1 ./gdb/gdb \ -data-directory ./gdb/data-directory \ -quiet -batch -ex "maint selftest" 2>&1 \ | grep -E "Ran [0-9]+ unit tests" Ran 82 unit tests, 0 failed To fix this, make register_test_foreach_arch register a lazy selftest generator. This way when the test generator is eventually executed, all architectures are registered and we do not have a dependency on the order the initialize functions are executed in. Tested on x86_64-linux Change-Id: I88eefebf7d372ad672f42d3a103e89354bc8a925
2022-04-19gdbsupport/selftest: Replace for_each_selftest with an iterator_rangeLancelot SIX1-7/+6
Remove the callback-based selftests::for_each_selftest function and use an iterator_range instead. Also use this iterator range in run_tests so all iterations over the selftests are done in a consistent way. This will become useful in a later commit. Change-Id: I0b3a5349a7987fbcb0071f11c394e353df986583
2022-04-18gdb/testsuite/dwarf: don't automatically add directory and file entry for ↵Simon Marchi3-19/+28
DWARF 5 To support DWARF 5 in the DWARF assembler line tables, we currently copy the first user-provided directory and the first user-provided files and make them elements at indices 0 in the directory and file name tables. That was a sufficient behavior at the time (see commit 44fda089397a ("[gdb/testsuite] Support .debug_line v5 in dwarf assembler")), but in the following patches, I would need to have finer grained control on what is generated exactly. For example, I'd like to generate a DWARF 5 line table with just a single file and a single directory. Get rid of this behavior, and implement what is suggested in 44fda089397a: make include_dir return the directory index that can be used to refer to that directory entry (based on the DWARF version), and use it afterwards. Adjust dw2-lines.exp and dw2-prologue-end.exp accordingly. Their produced DWARF5 binaries will change a bit, in that they will now have a single directory and file, where they had two before. But it doesn't change the expected GDB behavior. Change-Id: I5459b16ac9b7f28c34c9693c35c9afd2ebb3aa3b
2022-04-18gdbsupport: make gdb_realpath_keepfile return an std::stringSimon Marchi1-1/+2
I'm trying to switch these functions to use std::string instead of char arrays, as much as possible. Some callers benefit from it (can avoid doing a copy of the result), while others suffer (have to make one more copy). Change-Id: I793aab17baaef8345488f4c40b9094e2695425bc
2022-04-18gdbsupport: make gdb_abspath return an std::stringSimon Marchi8-31/+21
I'm trying to switch these functions to use std::string instead of char arrays, as much as possible. Some callers benefit from it (can avoid doing a copy of the result), while others suffer (have to make one more copy). Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993
2022-04-18gdb: call gdb_tilde_expand instead of gdb_tilde_expand_up in ↵Simon Marchi1-3/+3
source_script_with_search This removes a use of gdb_tilde_expand_up, which is removed later in this series. Change-Id: I5887d526cea987103e4ca24514a982b0a28e992a
2022-04-18Fix C++ cast of derived class to base classTom Tromey3-1/+27
PR c++/28907 points out that casting from a derived class to a base class fails in some situations. The problem turned out to be a missing use of value_embedded_offset. One peculiarity here is that, if you managed to construct a pointer-to-derived with an embedded offset of 0, the cast would work -- for example, one of the two new tests here passes without the patch. This embedded offset stuff is an endless source of bugs. I wonder if it's possible to get rid of it somehow. Regression tested on x86-64 Fedora 34. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28907
2022-04-18gdb/testsuite: make gdb.ada/mi_prot.exp stop at expected locationSimon Marchi2-7/+7
This test attempts to run until the line marked "STOP", which is at prot.adb:34. It first runs until the "main" symbol, then tries to place a breakpoint by line at line 34, without specifying the source file. When looking at the logs: -break-insert -t 34^M ^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x0000555555558a6c",func="adafinal",file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_pro t/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",thread-groups=["i1"],times="0",original-location="/home/simark/b uild/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb:34"}^M ... continues ... *stopped,reason="breakpoint-hit",disp="del",bkptno="2",frame={addr="0x0000555555558a6c",func="adafinal",args=[],file="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/ mi_prot/b~prot.adb",fullname="/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.ada/mi_prot/b~prot.adb",line="44",arch="i386:x86-64"},thread-id="1",stopped-threads="all",co re="8"^M ... we see that the breakpoint is placed in some generated file, not in the test source file as we expect. The problem is that "b main" in Ada does not place a breakpoint on the "Ada main", but on some symbol in a generated source file. So when stopped at the "main" symbol, we are not stopped in the file that contains the STOP marker at line 34. The test passes anyway today, so it doesn't seem to matter that we are stopped at an unexpected location. But it starts failing with this patch [1], because b~prot.adb:34 happens to be between two functions, so the breakpoint doesn't resolve. Fix this by placing the breakpoint at "$srcfile:$line", which works regardless of what is the current source file. However, this ends up introducing a path in the test name. Modify mi_tbreak and mi_continue_to_line to avoid that. [1] https://sourceware.org/pipermail/gdb-patches/2022-April/187686.html Change-Id: I742e2a9993046dcb5e30c64fe2ad920a363baf75
2022-04-18gdb/testsuite: add text_segment option to gdb_compileVignesh Balasubramanian5-21/+48
LLVM's lld linker doesn't have the "-Ttext-segment" option, but "--image-base" can be used instead. To centralize the logic of checking which option is supported, add the text_segment option to gdb_compile. Change tests that are currently using -Ttext-segment to use that new option instead. This patch fixes only compilation error, for example: Before: $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld" Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ... gdb compile failed, clang-13: warning: -Xlinker -Ttext-segment=0x7000000: 'linker' input unused [-Wunused-command-line-argument] After: $ make check TESTS="gdb.base/jit-elf.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang LDFLAGS_FOR_TARGET=-fuse-ld=ld" Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-elf.exp ... FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 1 FAIL: gdb.base/jit-elf.exp: one_jit_test-1: continue to breakpoint: break here 2 FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 1 FAIL: gdb.base/jit-elf.exp: one_jit_test-2: info function ^jit_function FAIL: gdb.base/jit-elf.exp: one_jit_test-2: continue to breakpoint: break here 2 FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: continue to breakpoint: break here 1 FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 1 FAIL: gdb.base/jit-elf.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2 === gdb Summary === # of expected passes 26 # of unexpected failures 9 Change-Id: I3678c5c9bbfc2f80671698e28a038e6b3d14e635
2022-04-18gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)Enze Li2-1/+66
The clear command shouldn't delete momentary and internal breakpoints, nor internal breakpoints created via Python's gdb.Breakpoint. This patch fixes this issue and adds a testcase. Regression tested on x86_64 openSUSE Tumbleweed(VERSION_ID="20220413"). Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7161
2022-04-16Add comments to dwarf2/abbrev-cache.hTom Tromey1-1/+9
This patch started when I noticed that the unordered_set include wasn't needed in abbrev-cache.h. (That was probably leftover from some earlier implementation of the class.) Then, I noticed that the class itself was under-commented. This patch fixes both issues.
2022-04-15Return void from gdb_putcTom Tromey4-10/+6
I don't think it's very useful to return the character from gdb_putc, so this patch changes it to return void.
2022-04-15Handle "set height 1"Tom Tromey2-5/+12
PR cli/17151 points out that "set height 1" has pathological behavior in gdb. What I see is that gdb will endlessly print the pagination prompt. This patch takes a simple and expedient approach to a fix: pretend that the height is really 2. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17151
2022-04-15Allow word wrapping even when paging is disabledTom Tromey1-8/+44
PR cli/20741 points out that when pagination is disabled, this also disabled word wrapping. However, the manual documents that these settings are separate -- if you intend to disable the wrapping, you must use "set width unlimited". This patch fixes the bug by letting the pagination-disabled case fall through to the code that also handles word-wrapping. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20741
2022-04-15Implement value_print for RustTom Tromey2-0/+26
This adds an implementation of the value_print method to Rust. As described in PR rust/22254, this removes a bit of weird-looking output from some "print"s -- because c_value_print is bypassed. I don't have a test for the bug that inspired this patch, because I only know how to reproduce it when using a relatively old Rust compiler. However, the new "cast-printing" code in value_print is required, because omitting this causes some existing tests to fail. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22254
2022-04-15Reimplement Rust slice printingTom Tromey4-27/+71
The current nightly Rust compiler (aka 1.61) added better DWARF representation for unsized types. Fixing this is PR rust/21466; but the code is actually the same as what is required to make slice printing more useful, which is PR rust/23871. This patch implements this. I tested this against various Rust compilers: 1.48, current stable, current beta, and current nightly. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21466 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23871
2022-04-15Remove some dead code from the Rust value printerTom Tromey1-8/+0
This removes a bit of dead code from the Rust value printer. This code wasn't always dead -- it fixed a real bug, and a test case was added for it. However, once val_print was removed, it became unnecessary.
2022-04-15Match rustc beta versionsTom Tromey1-1/+1
The rust_compiler_version proc extracts the Rust compiler version from the "rustc --version" output. For a beta compiler, the output looks like: rustc 1.60.0-beta.6 (7bccde197 2022-03-22) This patch slightly relaxes the regexp -- removing a space -- so that this can be understood by this proc.
2022-04-15[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32Tom de Vries1-5/+22
With test-case gdb.ada/float-bits.exp and native we get: ... (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M $9 = 5.0e+25^M (gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8# ... but with target board unix/-m32 we have instead: ... (gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M Cannot export value 2596145952482202326224873165792712 as 96-bits \ unsigned integer (must be between 0 and 79228162514264337593543950335)^M (gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8# ... Fix this by testing whether 16llf is supported by doing ptype long_long_float which gets us either: ... type = <16-byte float>^M ... or: ... type = <12-byte float>^M ... Tested on x86_64-linux with native and unix/-m32. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29041
2022-04-15Remove WITH_SIM defineTom Tromey3-7/+0
Since score-tdep.c was removed, the WITH_SIM define is not used in gdb. This patch removes it. Note that re-running autoheader shows a separate change that was missed. I've kept it in this patch to avoid extra work.
generated by cgit v1.1 at 2025-09-20 20:46:15 +0000