summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Re: Add section caches to coff_data_typeHEADmasterAlan Modra2023-05-184-84/+57
| | | | | | | | | | | | | | | | | | | | | | | Commit 0e759f232b6d regressed these tests: rs6000-aix7.2 +FAIL: Garbage collection test 1 (32-bit) rs6000-aix7.2 +FAIL: Garbage collection test 1 (64-bit) rs6000-aix7.2 +FAIL: Glink test 1 (32-bit) rs6000-aix7.2 +FAIL: Glink test 1 (64-bit) Investigation showed segfaults in coff_section_from_bfd_index called by xcoff_write_global_symbol due to the hash table pointer being NULL. Well, yes, the hash table isn't initialised for the output bfd. mkobject_hook is the wrong place to do that. * coffcode.h: Revert 0e759f232b6d changes. * peicode.h: Likewise. * coff-x86_64.c (htab_hash_section_index, htab_eq_section_index): Moved here from coffcode.h. (coff_amd64_rtype_to_howto): Create section_by_index htab. * coffgen.c (htab_hash_section_target_index), (htab_eq_section_target_index): Moved here from coffcode.h. (coff_section_from_bfd_index): Create section_by_target_index htab. Stash newly created sections in htab.
* PR11601, Solaris assembler compatibility doesn't workAlan Modra2023-05-182-1/+5
| | | | | | | | | | | | | Well, it doesn't work on x86 or ppc, which both have # starting comments anywhere on a line. I think it is therefore only useful on sparc. PR 11601 * config/obj-elf.c (obj_elf_section_word): Only compile for sparc. (obj_elf_section): Only support solaris .section directive on sparc. * doc/as.texi (Section): Mention that solaris .section directive is only supported for sparc.
* Automatic date update in version.inGDB Administrator2023-05-181-1/+1
|
* Special case "&str" in Rust parserTom Tromey2023-05-172-0/+13
| | | | | | | | | | | | | | | "&str" is an important type in Rust -- it's the type of string literals. However, the compiler puts it in the DWARF in a funny way. The slice itself is present and named "&str". However, the Rust parser doesn't look for types with names like this, but instead tries to construct them from components. In this case it tries to make a pointer-to-"str" -- but "str" isn't always available, and in any case that wouldn't yield the best result. This patch adds a special case for &str. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22251 Reviewed-By: Andrew Burgess <aburgess@redhat.com>
* Decorated symbols in import libs (BUG 30421)Luca Bacci2023-05-178-9/+160
| | | | | | | | | | | PR 30421 * cofflink.c (_decoration_hash_newfunc): New function. (_bfd_coff_link_hash_table_init): Call it. * libcoff-in.h (struct coff_link_hash_table): Add decoration_hash field. (struct decoration_hash_entry): Declare. (_decoration_hash_newfunc): Prototype. * libcoff.h: Regenerate. * emultempl/pe.em (set_decoration): New function. (pe_fixup_stdcalls): Call the new function. * emultempl/pep.em (set_decoration): New function. (pep_fixup_stdcalls): Call the new function. * pe-dll.c (make_one): Check for decoated symbols.
* PR29961, plugin-api.h: "Could not detect architecture endianess"Alan Modra2023-05-171-22/+23
| | | | | | | | | | | | Found when attempting to build binutils on sparc sunos-5.8 where sys/byteorder.h defines _BIG_ENDIAN but not any of the BYTE_ORDER variants. This patch adds the extra tests to cope with the old machine, and tidies the header a little. PR 29961 plugin-api.h: When handling non-gcc or gcc < 4.6.0 include necessary header files before testing macros. Make more use of #elif. Test _LITTLE_ENDIAN and _BIG_ENDIAN in final tests.
* gcc-4.5 build fixesAlan Modra2023-05-175-68/+65
| | | | | | | | | | | | | | | | | | | | Trying to build binutils with an older gcc currently fails. Working around these gcc bugs is not onerous so let's fix them. bfd/ * elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun pointer. * elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat" variable to "status". gas/ * compress-debug.c (compress_finish): Supply all fields in ZSTD_inBuffer initialisation. include/ * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary forward declaration. opcodes/ * loongarch-opc.c: Supply all fields of zero struct initialisation in various opcode tables.
* Automatic date update in version.inGDB Administrator2023-05-171-1/+1
|
* gprofng: include a new function in the right placeVladimir Mezentsev2023-05-161-45/+18
| | | | | | | | | | | | | Static function name is not available in stripped libraries. In this case, gprofng maps PC to a fake function like <static>@0xPC (<libname>). Sometimes gprofng creates two functions instead of one. Also FUNC_FLAG_SIMULATED is needed for these fake functions. gprofng/ChangeLog 2023-05-11 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * src/LoadObject.cc (LoadObject::find_function): Set FUNC_FLAG_SIMULATED. Include a new function in the right place.
* [gdb/tui] Don't show line number for lines not in source fileTom de Vries2023-05-163-21/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, for a source file containing only 5 lines, we also show line numbers 6 and 7 if they're in scope of the source window: ... 0 +-compact-source.c----------------+ 1 |___3_{ | 2 |___4_ return 0; | 3 |___5_} | 4 |___6_ | 5 |___7_ | 6 +---------------------------------+ ... Fix this by not showing line numbers not in a source file, such that we have instead: ... 0 +-compact-source.c----------------+ 1 |___3_{ | 2 |___4_ return 0; | 3 |___5_} | 4 | | 5 | | 6 +---------------------------------+ ... Tested on x86_64-linux. Suggested-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
* Document how to use the linker to create a resource only DLL.Nick Clifton2023-05-162-0/+38
| | | | | PR 30359 * ld.texi (WIN32): Document how to create a resource only DLL.
* Add section caches to coff_data_typeOleg Tolmatcev2023-05-167-11/+171
| | | | | | | | | * libcoff-in.h (struct coff_tdata): Add section_by_index and section_by_target_index hash tables. * libcoff.h: Regenerate. * coffcode.h (htab_hash_section_index): New function. (htab_eq_section_index): New function. (htab_hash_section_target_index): New function. (htab_eq_section_target_index): New function. (coff_mkobject_hool): Create the hash tables. * peicode.h: Add the same new functions. (pe_mkobject_hook): Create the hash tables. * coff-x86_64.c (coff_amd64_rtype_to_howto): Use the new tables to speed up lookups. * coffgen.c (coff_section_from_bfd_index): Likewise. (_bfd_coff_close_and_cleanup): Delete the hash tables.
* Update comments for the gdb/24331 fix.Paul Pluzhnikov2023-05-162-3/+4
| | | | Approved-by: Andrew Burgess <aburgess@redhat.com>
* gdb/testsuite: fix formatting of gdb.python/py-disasm.pyAndrew Burgess2023-05-161-3/+3
| | | | Run black on gdb.python/py-disasm.py file and commit the changes.
* gdb/testsuite: make gdb_supported_languages a caching procAndrew Burgess2023-05-161-5/+23
| | | | | | | | | | Rewrite gdb_supported_languages as a caching proc that actually queries GDB for the list of supported languages, rather than just containing a hard-coded list of languages. There's only one test that uses this proc right now, gdb.python/py-function.exp, and that still passes after this change, with no changes in the test names.
* -Ur option documentationNick Clifton2023-05-162-8/+16
| | | | * ld.texi (-Ur): Clarify the actions of this option.
* gdb/testsuite: fix regressions in break-main-file-remove-fail.expAndrew Burgess2023-05-161-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After this commit: commit a68f7e9844208ad8cd498f89b5100084ece7d0f6 Date: Tue May 9 10:28:42 2023 +0100 gdb/testsuite: extend special '^' handling to gdb_test_multiple buildbot notified me of a regression on s390 in the test: gdb.base/break-main-file-remove-fail.exp the failure looks like this: print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096) warning: Error removing breakpoint 0 $2 = 0 (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)" On the mailing list it has been reported that this failure also impacts arm, aarch64, and possibly ppc/ppc64 too. The above commit changed get_integer_valueof so that no output is expected between the command and the '$2 = 0' line. In this case the 'warning: Error removing breakpoint 0' output is causing the get_integer_valueof call to fail. The reason for this warning is that this test deliberately calls munmap on a page of the inferior's code. The test is checking that GDB can handle the situation where a s/w breakpoint can't be removed (due to the page no longer being readable/writable). The test that is supposed to trigger the warning is later in the test script when we delete a breakpoint. So why do some targets trigger the warning earlier during the inferior call? The impacted targets use AT_ENTRY_POINT as their strategy for handling inferior calls, that is, the trampoline that calls the inferior function is placed at the program's entry point, e.g. often the _start label. If this location happens to be on the same page as the page that the test script unmaps then, when the inferior function call returns, GDB will not be able to remove the temporary breakpoint that is inserted to catch the inferior function call returning! As a result we end up seeing the warning earlier than expected. I did wonder if this means I should relax the pattern in get_integer_valueof - just accept that there might be additional output from GDB which we should ignore. However, I don't think this the right way to go. With the change in a68f7e984420 we are now stricter for GDB emitting additional, unexpected, output, and I think that is a good thing. So, I think, in this case, in order to handle the possible extra output, we should implement something like get_integer_valueof directly in the gdb.base/break-main-file-remove-fail.exp test script. This local version will handle the possible warning output. After this the test should pass again on the impacted targets.
* gdb/python: extend the Python Disassembler API to allow for stylingAndrew Burgess2023-05-165-93/+1366
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit extends the Python Disassembler API to allow for styling of the instructions. Before this commit the Python Disassembler API allowed the user to do two things: - They could intercept instruction disassembly requests and return a string of their choosing, this string then became the disassembled instruction, or - They could call builtin_disassemble, which would call back into libopcode to perform the disassembly. As libopcode printed the instruction GDB would collect these print requests and build a string. This string was then returned from the builtin_disassemble call, and the user could modify or extend this string as needed. Neither of these approaches allowed for, or preserved, disassembler styling, which is now available within libopcodes for many of the more popular architectures GDB supports. This commit aims to fill this gap. After this commit a user will be able to do the following things: - Implement a custom instruction disassembler entirely in Python without calling back into libopcodes, the custom disassembler will be able to return styling information such that GDB will display the instruction fully styled. All of GDB's existing style settings will affect how instructions coming from the Python disassembler are displayed in the expected manner. - Call builtin_disassemble and receive a result that represents how libopcode would like the instruction styled. The user can then adjust or extend the disassembled instruction before returning the result to GDB. Again, the instruction will be styled as expected. To achieve this I will add two new classes to GDB, DisassemblerTextPart and DisassemblerAddressPart. Within builtin_disassemble, instead of capturing the print calls from libopcodes and building a single string, we will now create either a text part or address part and store these parts in a vector. The DisassemblerTextPart will capture a small piece of text along with the associated style that should be used to display the text. This corresponds to the disassembler calling disassemble_info::fprintf_styled_func, or for disassemblers that don't support styling disassemble_info::fprintf_func. The DisassemblerAddressPart is used when libopcodes requests that an address be printed, and takes care of printing the address and associated symbol, this corresponds to the disassembler calling disassemble_info::print_address_func. These parts are then placed within the DisassemblerResult when builtin_disassemble returns. Alternatively, the user can directly create parts by calling two new methods on the DisassembleInfo class: DisassembleInfo.text_part and DisassembleInfo.address_part. Having created these parts the user can then pass these parts when initializing a new DisassemblerResult object. Finally, when we return from Python to gdbpy_print_insn, one way or another, the result being returned will have a list of parts. Back in GDB's C++ code we walk the list of parts and call back into GDB's core to display the disassembled instruction with the correct styling. The new API lives in parallel with the old API. Any existing code that creates a DisassemblerResult using a single string immediately creates a single DisassemblerTextPart containing the entire instruction and gives this part the default text style. This is also what happens if the user calls builtin_disassemble for an architecture that doesn't (yet) support libopcode styling. This matches up with what happens when the Python API is not involved, an architecture without disassembler styling support uses the old libopcodes printing API (the API that doesn't pass style info), and GDB just prints everything using the default text style. The reason that parts are created by calling methods on DisassembleInfo, rather than calling the class constructor directly, is DisassemblerAddressPart. Ideally this part would only hold the address which the part represents, but in order to support backwards compatibility we need to be able to convert the DisassemblerAddressPart into a string. To do that we need to call GDB's internal print_address function, and to do that we need an gdbarch. What this means is that the DisassemblerAddressPart needs to take a gdb.Architecture object at creation time. The only valid place a user can pull this from is from the DisassembleInfo object, so having the DisassembleInfo act as a factory ensures that the correct gdbarch is passed over each time. I implemented both solutions (the one presented here, and an alternative where parts could be constructed directly), and this felt like the cleanest solution. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom Tromey <tom@tromey.com>
* gdb/python: rework how the disassembler API reads the result objectAndrew Burgess2023-05-165-80/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is a refactor ahead of the next change which will make disassembler styling available through the Python API. Unfortunately, in order to make the styling support available, I think the easiest solution is to make a very small change to the existing API. The current API relies on returning a DisassemblerResult object to represent each disassembled instruction. Currently GDB allows the DisassemblerResult class to be sub-classed, which could mean that a user tries to override the various attributes that exist on the DisassemblerResult object. This commit removes this ability, effectively making the DisassemblerResult class final. Though this is a change to the existing API, I'm hoping this isn't going to cause too many issues: - The Python disassembler API was only added in the previous release of GDB, so I don't expect it to be widely used yet, and - It's not clear to me why a user would need to sub-class the DisassemblerResult type, I allowed it in the original patch because at the time I couldn't see any reason to NOT allow it. Having prevented sub-classing I can now rework the tail end of the gdbpy_print_insn function; instead of pulling the results out of the DisassemblerResult object by calling back into Python, I now cast the Python object back to its C++ type (disasm_result_object), and access the fields directly from there. In later commits I will be reworking the disasm_result_object type in order to hold information about the styled disassembler output. The tests that dealt with sub-classing DisassemblerResult have been removed, and a new test that confirms that DisassemblerResult can't be sub-classed has been added. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom Tromey <tom@tromey.com>
* Automatic date update in version.inGDB Administrator2023-05-161-1/+1
|
* Correctly handle forward DIE references in scannerTom Tromey2023-05-152-3/+104
| | | | | | | | | | | | | | | | | | | | The cooked index scanner has special code to handle forward DIE references. However, a bug report lead to the discovery that this code does not work -- the "deferred_entry::spec_offset" field is written to but never used, i.e., the lookup is done using the wrong key. This patch fixes the bug and adds a regression test. The test in the bug itself used a thread_local variable, which provoked a failure at runtime. This test instead uses "maint print objfiles" and then inspects to ensure that the entry in question has a parent. This lets us avoid a clang dependency in the test. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30271
* LoongArch: Fix PLT entry generate bugmengqinggang2023-05-152-4/+3
| | | | | | | | | | | | | | If a function symbol only get its address by la.global, without directly called by bl instruction, the PLT entry is not required. bfd/ChangeLog: * elfnn-loongarch.c (loongarch_elf_adjust_dynamic_symbol): Fix PLT entry generate bug. ld/ChangeLog: * testsuite/ld-elf/shared.exp: Clear xfail for LoongArch.
* Automatic date update in version.inGDB Administrator2023-05-151-1/+1
|
* Automatic date update in version.inGDB Administrator2023-05-141-1/+1
|
* Fix bad interaction between element limit and repeated values (BZ#24331).Paul Pluzhnikov2023-05-133-7/+35
| | | | | | | | | | | | Currently print -elements=3 -- "AAAAAA" prints complete string, which is not what the user asked for. Fix two buggy tests exposed by the fix, and add a new test. Reviewed-by: Keith Seitz <keiths@redhat.com>
* PR28955 mips gas segfaultAlan Modra2023-05-131-2/+4
| | | | | | | | | Testing for NULL in pic_need_relax fixes the other call to this function in md_estimate_size_before_relax. PR 28955 * config/tc-mips.c (mips_frob_file): Move NULL sym test to.. (pic_need_relax): ..here.
* PR28902, -T script with INSERT orderingAlan Modra2023-05-131-1/+8
| | | | | | | | | | | | | | | The answer to PR28902 may be deduced from the existing INSERT documentation that says the default script is parsed after the -T INSERT script, if you assume (correctly) that nothing special is done when inserting into -T scripts overriding the default script. In both cases INSERT handling looks for the specified output section later on the internal list of parsed script commands. This isn't obvious though, so make the ordering explicit, and mention that section assignments are the same too. PR 28902 * ld.texi (INSERT): Specify ordering when -T is used both to override the default script and to augment.
* Automatic date update in version.inGDB Administrator2023-05-131-1/+1
|
* Fix regression due to Pragma Import seriesTom Tromey2023-05-124-0/+28
| | | | | | | | | | | | | | | | | | | | | A co-worker here at AdaCore discovered that the Pragma Import series caused a rgression. When debugging gnat1, gdb started asking for overload resolution like: (gdb) call pp(n) Multiple matches for pp [0] cancel [1] pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511 [2] treepr.pp (types.union_id) at ../../gcc/gcc/ada/treepr.adb:511 This worked before the series, and is strange anyway, because the matches refer to the same function. This patch adds a test case for this situation and fixes the bug by pruning identical functions in remove_extra_symbols.
* Use bool and early loop exit in remove_extra_symbolsTom Tromey2023-05-121-5/+5
| | | | | | | | This changes remove_extra_symbols to use bool rather than int, and changes the nested loops to exit early when "remove_p" is set.
* Use reference parameter in remove_extra_symbolsTom Tromey2023-05-121-25/+25
| | | | | | | | | Changing ada-lang.c:remove_extra_symbols to take a reference parameter makes the code a bit easier to read, by replacing "(*syms)" with plain "syms".
* Handle Ada Pragma Import and Pragma ExportTom Tromey2023-05-1212-4/+442
| | | | | | | | | | | | | Ada can import C APIs and also export Ada constructs to C via Pragma Import and Pragma Export. This patch adds support for these to gdb, by arranging to either defer some aspects of a symbol to the underlying C symbol (for Import) or by introducing a second symbol (for Export). A somewhat tricky approach is needed, both because gdb doesn't generally handle symbol aliasing, and because Ada treats symbol names in an unusual way (as compared to the rest of gdb).
* Introduce symbol_block_ops::get_block_valueTom Tromey2023-05-122-1/+11
| | | | | | | | | This adds a new callback to symbol_block_ops. This callback lets a LOC_BLOCK symbol implement its own function to find the underlying block.
* Define symbol::value_block separatelyTom Tromey2023-05-121-4/+7
| | | | | | | | | | This moves the definition of symbol::value_block outside of the class. A subsequent patch will change this method to use SYMBOL_BLOCK_OPS, and it seemed simplest to move this method out-of-line, and cleaner to do this as a separate change.
* Bump MAX_SYMBOL_IMPLSTom Tromey2023-05-121-1/+1
| | | | | | | | | | A subsequent patch will introduce more aclass registrations, causing the number to go over the current maximum. This bumps the number. Note that there's a separate static assert that ensures that this number doesn't get too large for the field size in the symbol.
* Introduce lookup_minimal_symbol_linkageTom Tromey2023-05-123-23/+38
| | | | | | | | | This introduces a new function, lookup_minimal_symbol_linkage, and refactors a couple other existing functions to call it. This function will be used in a subsequent patch.
* gdb: remove unnecessary call to std::string constructorSimon Marchi2023-05-121-1/+1
| | | | | | | | | | I spotted this explicit call to std::string, which creates an unnecessary temporary extra std::string, while calling emplace_back. I'm not sure if it has any impact in an optimized build, maybe the compiler elides it. But still, it's unnecessary. Change-Id: I873337ea91db29ac06267aff8fc12dcf52824cac Approved-By: Tom Tromey <tom@tromey.com>
* Add dynamic_prop::is_constantTom Tromey2023-05-1214-43/+45
| | | | | | | | | | | | | | | I noticed many spots checking whether a dynamic property's kind is PROP_CONST. Some spots, I think, are doing a slightly incorrect check -- checking for != PROP_UNDEFINED where == PROP_CONST is actually required, the key thing being that const_val may only be called for PROP_CONST properties. This patch adds dynamic::is_constant and then updates these checks to use it. Regression tested on x86-64 Fedora 36.
* Implement DAP register scopeTom Tromey2023-05-122-5/+33
| | | | | | | | | I noticed that gdb's DAP code did not provide a way to see register values. DAP defines a "register" scope, which this patch implements. This patch also adds the missing (and optional) "presentationHint" to scopes.
* Fix calling debuginfo-less functions in AdaTom Tromey2023-05-126-2/+113
| | | | | | | | | | | | | | | A co-worker at AdaCore noticed that calling a function without debuginfo yields: (gdb) print plus_one(23) 'pck.plus_one' has unknown return type; cast the call to its declared return type However, this also happens if you follow the directions and add the cast. This patch fixes the problem and adds a regression test.
* gdb/python: implement DisassemblerResult.__str__ methodAndrew Burgess2023-05-123-9/+30
| | | | | | | | Add the DisassemblerResult.__str__ method. This gives the same result as the DisassemblerResult.string attribute, but can be useful sometimes depending on how the user is trying to print the object. There's a test for the new functionality.
* gdb/python: implement __repr__ methods for py-disasm.c typesAndrew Burgess2023-05-123-2/+84
| | | | | Add a __repr__ method for the DisassembleInfo and DisassemblerResult types, and add some tests for these new methods.
* gdb/doc: improve Python Disassembler API documentationAndrew Burgess2023-05-121-5/+12
| | | | | | | | | Some small improvements to the Python Disassembler API documentation: * Be consistent about using the package scope in the @deftp lines, * Rework the description of the DisassemblerResult class to include mention of builtin_disassemble.
* gdb/testsuite: extend special '^' handling to gdb_test_multipleAndrew Burgess2023-05-127-28/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The commit: commit 08ec06d6440745ef9204d39197aa1e732df41056 Date: Wed Mar 29 10:41:07 2023 +0100 gdb/testsuite: special case '^' in gdb_test pattern Added some special handling of '^' to gdb_test -- a leading '^' will cause the command regexp to automatically be included in the expected output pattern. It was pointed out that the '-wrap' flag of gdb_test_multiple is supposed to work in the same way as gdb_test, and that the recent changes for '^' had not been replicated for gdb_test_multiple. This patch addresses this issue. So, after this commit, the following two constructs should have the same meaning: gdb_test "command" "^output" "test name" gdb_test_multiple "command" "test name" { -re -wrap "^output" { pass $gdb_test_name } } In both cases the '^' will case gdb.exp to inject a regexp that matches 'command' after the '^' and before the 'output', this is in addition to adding the $gdb_prompt pattern after 'output' in the normal way. The special '^' handling is only applied when '-wrap' is used, as this is the only mode that aims to mimic gdb_test. While working on this patch I realised that I could actually improve the logic for the special '^' handling in the case where the expected output pattern is empty. I replicated these updates for both gdb_test and gdb_test_multiple in order to keep these two paths in sync. There were a small number of tests that needed adjustment after this change, mostly just removing command regexps that are now added automatically, but the gdb.base/settings.exp case was a little weird as it turns out trying to match a single blank line is probably harder now than it used to be -- still, I suspect this is a pretty rare case, so I think the benefits (improved anchoring) outweigh this small downside (IMHO).
* gdb: fix error message for $_gdb_maint_settingAndrew Burgess2023-05-122-2/+25
| | | | | | | | | | | | | | | | | I spotted this behaviour: (gdb) p $_gdb_maint_setting("xxx") First argument of $_gdb_maint_setting must be a valid setting of the 'show' command. Notice that GDB claims I need to use a setting from the 'show' command, which isn't correct for $_gdb_maint_setting, in this case I need to use a setting from 'maintenance show'. This same issue is present for $_gdb_maint_setting_str. This commit fixes this minor issue. Approved-By: Simon Marchi <simon.marchi@efficios.com>
* [gdb/testsuite] Fix gdb.dwarf2/opt-out-not-implptr.exp for -m32Tom de Vries2023-05-121-7/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running test-case gdb.dwarf2/opt-out-not-implptr.exp with target board unix/-m32 we have: ... (gdb) print noptr^M $1 = {0, <optimized out>, <optimized out>, <optimized out>}^M (gdb) FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr ... The problem happens when evaluating this dwarf expression: ... <45> DW_AT_location : 13 byte block: 10 86 ea d7 d0 96 8e cf 92 5c 9f 93 8 \ (DW_OP_constu: 6639779683436459270; DW_OP_stack_value; DW_OP_piece: 8) ... The DW_OP_constu pushes a value with "generic type" on to the DWARF stack, and the "generic type" has the size of an address on the target machine, which for target board unix/-m32 is 4 bytes. Consequently, the constant is abbreviated. Next, the DW_OP_piece declares that the resulting 4-byte value is 8 bytes large, and we hit this clause in rw_pieced_value: ... /* Use zeroes if piece reaches beyond stack value. */ if (p->offset + p->size > stack_value_size_bits) break; ... and consequently get a zero. We could just add require is_target_64 to the test-case, but instead, add a 32-bit case and require is_target_64 just for the 64-bit case. Tested on x86_64-linux.
* [gdb/testsuite] Make is_64_target more robustTom de Vries2023-05-121-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | I ran test-case gdb.dwarf2/opt-out-not-implptr.exp with make-check-all.sh, and with target board dwarf64 ran into: ... FAIL: gdb.dwarf2/opt-out-not-implptr.exp: print noptr ... due to is_target_64 failing because of: ... builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ -fdiagnostics-color=never -w -c -gdwarf64 -g -o is_64_target.o \ is_64_target.c^M gcc: error: '-gdwarf64' is ambiguous; use '-gdwarf-64' for DWARF version or \ '-gdwarf -g64' for debug level^M compiler exited with status 1 ... The FAIL is the same FAIL I run into with target board unix/-m32: is_target_64 fails for both cases. The reason that is_target_64 is failing for target board dwarf64, is because of using system compiler 7.5.0 which doesn't support -gdwarf64. Fix this by making is_target_64 use nodebug instead of debug for compilation. Tested on x86_64-linux.
* [gdb/cli] Fix wrapping for TERM=ansiTom de Vries2023-05-123-13/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I. Auto-detected width (xterm vs. ansi) Say we have a terminal with a width of 40 chars: ... $ echo $COLUMNS 40 ... With TERM=xterm, we report a width of 40 chars: ... $ TERM=xterm gdb (gdb) show width Number of characters gdb thinks are in a line is 40. ... And with TERM=ansi, a width of 39 chars: ... $ TERM=ansi gdb (gdb) show width Number of characters gdb thinks are in a line is 39. ... Gdb uses readline to auto-detect screen size, and readline decides in the TERM=ansi case that the terminal does not have reliable auto-wrap, and consequently decides to hide the last terminal column from the readline user (in other words GDB), hence we get 39 instead of 40. II. Types of wrapping Looking a bit more in detail inside gdb, it seems there are two types of wrapping: - readline wrapping (in other words, prompt edit wrapping), and - gdb output wrapping (can be observed by issuing "info sources"). This type of wrapping attempts to wrap some of the gdb output earlier than the indicated width, to not break lines in inconvenient places. III. Readline wrapping, auto-detected screen size Let's investigate readline wrapping with the auto-detected screen widths. First, let's try with xterm: ... $ TERM=xterm gdb (gdb) 7890123456789012345678901234567890 123 ... That looks as expected, wrapping occurs after 40 chars. Now, let's try with ansi: ... $ TERM=ansi gdb (gdb) 78901234567890123456789012345678 90123 ... It looks like wrapping occurred after 38, while readline should be capable of wrapping after 39 chars. This is caused by readline hiding the last column, twice. In more detail: - readline detects the screen width: 40, - readline hides the last column, setting the readline screen width to 39, - readline reports 39 to gdb as screen width, - gdb sets its width setting to 39, - gdb sets readline screen width to 39, - readline hides the last column, again, setting the readline screen width to 38. This is reported as PR cli/30346. IV. gdb output wrapping, auto-detected screen size Say we set the terminal width to 56. With TERM=xterm, we have: ... /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, /data/vries/hello.c, ... but with TERM=ansi: ... /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/elf-init.c, / data/vries/hello.c, ... So what happened here? With TERM=ansi, the width setting is auto-detected to 55, and gdb assumes the terminal inserts a line break there, which it doesn't because the terminal width is 56. This is reported as PR cli/30411. V. Fix PRs Fix both mentioned PRs by taking into account the hidden column when readline reports the screen width in init_page_info, and updating chars_per_line accordingly. Note that now we report the same width for both TERM=xterm and TERM=ansi, which is much clearer. The point where readline respectively expects or ensures wrapping is still indicated by "maint info screen", for xterm: ... Number of characters readline reports are in a line is 40. ... and ansi: ... Number of characters readline reports are in a line is 39. ... VI. Testing PR cli/30346 is covered by existing regression tests gdb.base/wrap-line.exp and gdb.tui/wrap-line.exp, so remove the KFAILs there. I didn't manage to come up with a regression test for PR cli/30411. Perhaps that would be easier if we had a maintenance command that echoes its arguments while applying gdb output wrapping. Tested on x86_64-linux. PR cli/30346 PR cli/30411 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30346 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30411
* x86: move a few more disassembler helper functionsJan Beulich2023-05-121-34/+29
| | | | | ... such that they wouldn't need forward declarations anymore. Note that append_seg() already was suitably placed.
* x86: move get<N>() disassembler helper functionsJan Beulich2023-05-121-75/+71
| | | | ... such that none of them would need forward declarations anymore.