summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-02Fix disabling of year 2038 support on 32-bit hosts by defaultfix-arm-mtimeThiago Jung Bauermann
2024-02-02x86: Disallow instructions with length > 15 bytesH.J. Lu
It is a hard error when an instruction length exceeds the limit of 15 bytes: [hjl@gnu-cfl-3 tmp]$ cat x.s .text xacquire lock addq $0x11223344, %fs:(,%eax) [hjl@gnu-cfl-3 tmp]$ gcc -c x.s x.s: Assembler messages: x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15 [hjl@gnu-cfl-3 tmp]$ objdump -dw x.o x.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <.text>: 0: 64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22 xacquire lock (bad) f: 11 .byte 0x11 [hjl@gnu-cfl-3 tmp]$ and [hjl@gnu-cfl-3 tmp]$ cat z.s addq $0xe0, %fs:0, %rdx [hjl@gnu-cfl-3 tmp]$ as -o z.o z.s z.s: Assembler messages: z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15 [hjl@gnu-cfl-3 tmp]$ objdump -dw z.o z.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <.text>: 0: 64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00 (bad) ... [hjl@gnu-cfl-3 pr31323]$ Instructions with length > 15 bytes are always invalid. It is quite easy to generate invalid instructions with AVX now. We should issue an error when instruction length exceeds the limit of 15 bytes. PR gas/31323 * config/tc-i386.c (output_insn): Issue an error when instruction length exceeds the limit of 15 bytes. * testsuite/gas/i386/oversized16.l: Updated. * testsuite/gas/i386/oversized64.l: Likewise. * testsuite/gas/i386/x86-64-apx-inval.l: New file. * testsuite/gas/i386/x86-64-apx-inval.s: Likewise.
2024-02-02gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointersNils-Christian Kempke
For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like <2><17d>: Abbrev Number: 22 (DW_TAG_variable) <180> DW_AT_name : (indirect string, offset: 0x1f1): fptr <184> DW_AT_type : <0x214> ... <1><219>: Abbrev Number: 27 (DW_TAG_array_type) <21a> DW_AT_type : <0x10e> <216> DW_AT_associated : ... The 'pointer property' in Fortran is implicitly modeled by adding a DW_AT_associated to the type of the variable (see also the DW_AT_associated description in DWARF 5). A Fortran pointer is more than an address and thus different from a C pointer. It is a self contained type having additional fields such as, e.g., the rank of its underlying array. This motivates the intended DWARF modeling of Fortran pointers via the DW_AT_associated attribute. This patch adds support for the sizeof intrinsic by simply dereferencing pointer types when encountered during a sizeof evaluation. The patch also adds a test for the sizeof intrinsic which was not tested before. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>
2024-02-02gdb, types: Resolve pointer types dynamicallyBernhard Heckel
This commit allows pointers to be dynamic types (on the outmost level). Similar to references, a pointer is considered a dynamic type if its target type is a dynamic type and it is on the outmost level. Also this commit removes the redundant code inside function "value_check_printable" for handling of DW_AT_associated type. The pointer resolution follows the one of references. This change generally makes the GDB output more verbose. We are able to print more details about a pointer's target like the dimension of an array. In Fortran, if we have a pointer to a dynamic type type buffer real, dimension(:), pointer :: ptr end type buffer type(buffer), pointer :: buffer_ptr allocate (buffer_ptr) allocate (buffer_ptr%ptr (5)) which then gets allocated, we now resolve the dynamic type before printing the pointer's type: Before: (gdb) ptype buffer_ptr type = PTR TO -> ( Type buffer real(kind=4) :: alpha(:) End Type buffer ) After: (gdb) ptype buffer_ptr type = PTR TO -> ( Type buffer real(kind=4) :: alpha(5) End Type buffer ) Similarly in C++ we can dynamically resolve e.g. pointers to arrays: int len = 3; int arr[len]; int (*ptr)[len]; int ptr = &arr; Once the pointer is assigned one gets: Before: (gdb) p ptr $1 = (int (*)[variable length]) 0x123456 (gdb) ptype ptr type = int (*)[variable length] After: (gdb) p ptr $1 = (int (*)[3]) 0x123456 (gdb) ptype ptr type = int (*)[3] For more examples see the modified/added test cases. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>
2024-02-02gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.expIjaz, Abdul B
Improve indentation in the test file by replacing 10 spaces at second level with 4 spaces. This helps to update the test using the right indentation in future. Approved-By: Tom Tromey <tom@tromey.com>
2024-02-02x86: move Q-suffix-to-REX.W translation logicJan Beulich
By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a part of another conditional there. While moving, also drop a pointless check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily have both been 64-bit ones.
2024-02-02x86: actually implement .nooptJan Beulich
For quite some time we've had support for -O command line options. With that ignoring at least .noopt isn't really a good idea. Re-purpose the optimize-3 test for testing this directive's effect as well. As to the doc addition - this uses the same text as is there for the {nooptimize} pseudo-prefix, despite me not being convinced of the "size" part being fully accurate there (and hence also here).
2024-02-01MAINTAINERS: Update my e-mail address.Sandra Loosemore
2024-02-02Automatic date update in version.inGDB Administrator
2024-02-01gas: x86: ginsn: adjust ginsns for certain lea opsIndu Bhagat
A review comment on the SCFI V4 series was to handle ginsn creation for certain lea opcodes more precisely. Specifically, we should preferably handle the following two cases of lea opcodes similarly: - #1 lea with "index register and scale factor of 1, but no base register", - #2 lea with "no index register, but base register present". Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the case of #1 above. For #2, however, the lea insn is translated to either a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate for displacement is non-zero or not respectively. Change the handling in x86_ginsn_lea so that both of the above lea manifestations are handled similarly. While at it, remove the code paths creating GINSN_TYPE_OTHER altogether from the function. It makes sense to piggy back on the x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the destination register is interesting. This was also suggested in one of the previous review rounds; the other functions already follow that model, so this keeps functions symmetrical looking. gas/ * gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with no base register similar to the case of no index register. Remove creation of GINSN_TYPE_OTHER from the function. gas/testsuite/ * gas/scfi/x86_64/ginsn-lea-1.l: New test. * gas/scfi/x86_64/ginsn-lea-1.s: Likewise. * gas/scfi/x86_64/scfi-x86-64.exp: Add new test.
2024-02-01gprofng: Remove unused macrosVladimir Mezentsev
gprofng/ChangeLog 2024-02-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION. * common/hwctable.c: Remove DBG_LT* macros. * libcollector/envmgmt.c: Likewise. * libcollector/hwprofile.c: Likewise. * libcollector/iolib.c: Likewise. * libcollector/jprofile.c: Likewise. * libcollector/memmgr.c: Likewise. * libcollector/profile.c: Likewise. * libcollector/tsd.c: Likewise. * libcollector/unwind.c: Likewise.
2024-02-01Fix "objstack" typoTom Tromey
I noticed some comments that mentions "objstack". The type is actually "obstack". This patch fixes the typos.
2024-02-01Rename SEARCH_ALLTom Tromey
The constant SEARCH_ALL conflicts with a define in a Windows header. This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the conflict. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307
2024-02-01gdb/testsuite: fix some duplicate test names in gdb.trace/Andrew Burgess
This commit fixes some of the easier duplicate test names in the gdb.trace/ directory. All of these duplicates are resolved by either given tests a name, or by extended the existing name to make it more descriptive. There should be no change in what is tested after this commit.
2024-02-01gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.expAndrew Burgess
Fix some duplicate test names in gdb.base/cond-eval-mode.exp when running with native-gdbserver or native-extended-gdbserver board files. I've just added some 'with_test_prefix' blocks to make the test names unique, there should be no change in what is tested after this commit.
2024-01-31Fix AIX build break.Aditya Vidyadhar Kamath
A recent commit broke AIX build. The thread_local type defined functions were being considered a weak symbol and hence while creating the binary these symbols were not visible. This patch is a fix for the same.
2024-02-01Automatic date update in version.inGDB Administrator
2024-01-31gdb: remove some unnecessary frame_info_ptr resetsSimon Marchi
This code was probably needed before we had reinflatable frame_info_ptrs, it's not necessary anymore. Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5 Approved-By: Tom Tromey <tom@tromey.com>
2024-01-31Mention support for AMD/znver5 in GASNick Clifton
2024-01-31PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap.Georg-Johann Lay
Supply these symbols as computed by the linker scripts, even when there are weak definitions. PR 31124 * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE.
2024-01-31Automatic date update in version.inGDB Administrator
2024-01-30Really fix Windows gdbserver segment registersTom Tromey
My earlier attempt to mask the segment registers in gdbserver for Windows introduced some bugs. That patch is here: https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html The problem turned out to be that these fields in the Windows 'CONTEXT' type are just 16 bits, so while masking the values on read is fine, writing the truncated values back then causes zeros to be written to some subsequent field. This patch cleans this up by arranging never to write too much data to a field. I also noticed that two register numbers here were never updated for the 64-bit port. This patch fixes this as well, and renames the "FCS" register to follow gdb. Finally, this patch applies the same treatment to windows-nat.c. Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2024-01-30Automatic date update in version.inGDB Administrator
2024-01-30PR31314, chew crashing on use of uninitialized valueAlan Modra
The "drop" call in wrap_comment already increments pc. Defining DOCDD in proto.str is a warning fix. PR 31314 * chew.c (wrap_comment): Don't increment pc. * proto.str (DOCDD): Define.
2024-01-29sim: bpf: remove support for ldinddw and ldabsdw instructionsJose E. Marchesi
This patch removes support for the two instructions above from the GNU simulator, including the corresponding tests. These instructions do not really exist in BPF and are not recognized as such by the kernel verifier. This has now been pointed out during the standardization of the BPF ISA. Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>
2024-01-29gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.defLancelot SIX
Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the sym-domains.def file has been introduced, and requires the user to define the DOMAIN(x) macro. On older systems (centos-7 with glibc-2.17 for example), this DOMAIN macro conflicts with another macro defined in /usr/include/math.h. Fix this conflict by changing sym-domains.def to use a macro named SYM_DOMAIN instead of DOMAIN. Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3 Approved-By: Tom Tromey <tom@tromey.com>
2024-01-29bfd: restore Threading menu entry in bfd.texiJose E. Marchesi
I mistakenly vandalized bfd.texi in the commit 0c45feb159a14ca4cb50cfbf45eacaf5a6cecf2b by removing an entry in the manual menu. This commit reverts that thunk.
2024-01-29bpf: there is no ldinddw nor ldabsdw instructionsJose E. Marchesi
There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW. For some reason we were (incorrectly) supporting these. This patch updates the opcodes so the instructions get removed and modifies the GAS manual and testsuite accordingly. See discussion at https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev Tested in bpf-uknonwn-none target, x86-64-linux-gnu host. include/ChangeLog: 2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com> * opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and BPF_INSN_LDABSDW instructions. opcodes/ChangeLog: 2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com> * bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and BPF_INSN_LDABSDW instructions. gas/ChangeLog: 2024-01-29 Jose E. Marchesi <jose.marchesi@oracle.com> * doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit load instruction. (BPF Instructions): There is no absolute 64-bit load instruction. * testsuite/gas/bpf/mem.s: Update test accordingly. * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise. * testsuite/gas/bpf/mem-be.d: Likewise. * testsuite/gas/bpf/mem-pseudoc.d: Likewise. * testsuite/gas/bpf/mem-pseudoc.s: Likewise. * testsuite/gas/bpf/mem.d: Likewise. * testsuite/gas/bpf/mem.s: Likewise.
2024-01-29Update release making documentation after 2.42 releaseNick Clifton
2024-01-29Remove support for the beos file formatNick Clifton
2024-01-29Fix backtrace limit stopping on inline frameHannes Domani
If you have set up a backtrace limit, and the backtrace stops because of this in an inline frame with arguments, you get an assertion failure: ``` (gdb) bt (gdb) set backtrace limit 2 (gdb) bt C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed. ``` And if this one is fixed, there is another one as well: ``` (gdb) bt C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed. ``` The reason for both of them is this kind of loop: ``` while (get_frame_type (frame) == INLINE_FRAME) frame = get_prev_frame (frame); ``` Since get_prev_frame respects the backtrace limit, it will return NULL, and from there on you can't continue. This changes these loops to use get_prev_frame_always instead, so you always get a non-inline frame in the end. With this backtrace works: ``` (gdb) bt (gdb) ``` Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29865 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-01-29Updated French translations for GOLD and LDNick Clifton
2024-01-29Automatic date update in version.inGDB Administrator
2024-01-28Document new Python and Guile constantsTom Tromey
This documents the new Python and Guile constants introduced earlier in this series. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-01-28Refine search in cp_search_static_and_baseclassesTom Tromey
This changes cp_search_static_and_baseclasses to only search for types, functions, and modules. The latter two cases were discovered by regression testing. I found it somewhat surprising the Fortran name lookup ends up in this code, but did not attempt to change this.
2024-01-28Only search for functions in rust_structop::evaluate_funcallTom Tromey
This changes rust_structop::evaluate_funcall to only search for functions.
2024-01-28Only search types in lookup_typenameTom Tromey
This changes lookup_typename to only look for types. The check for LOC_TYPEDEF can now also be removed, because only types will appear in TYPE_DOMAIN. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24870
2024-01-28Only search types in cp_lookup_rtti_typeTom Tromey
This changes cp_lookup_rtti_type to only search for types -- not functions or variables. Due to the symbol-matching hack, this could just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also I hold on to some hope that perhaps the hack can someday be removed.
2024-01-28Use a function-domain search in inside_main_funcTom Tromey
This changes inside_main_func to search only for functions.
2024-01-28Only look for functions in expand_symtabs_for_functionTom Tromey
This changes expand_symtabs_for_function to only look in the function domain.
2024-01-28Only search for "main" as a functionTom Tromey
This changes find_main_name to restrict its search to the function domain.
2024-01-28Simplify some symbol searches in linespec.cTom Tromey
This simplifies some symbol searches in linespec.c. In particular, two separate searches here can now be combined into one, due to the new use of flags. Arguably the STRUCT_DOMAIN searches should perhaps not even be done. Only C really has these, and C doesn't have member functions. However, it seems relatively harmless -- and clearly compatible -- to leave this in.
2024-01-28Simplify some symbol searches in Ada codeTom Tromey
This changes some of the Ada code to simplify symbol searches. For example, if a function is being looked for, the search is narrowed to use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a search of the "struct" domain is removed, because Ada does not have a tag domain.
2024-01-28Use the new symbol domainsTom Tromey
This patch changes the DWARF reader to use the new symbol domains. It also adjusts many bits of associated code to adapt to this change. The non-DWARF readers are updated on a best-effort basis. This is somewhat simpler since most of them only support C and C++. I have no way to test a few of these. I went back and forth a few times on how to handle the "tag" situation. The basic problem is that C has a special namespace for tags, which is separate from the type namespace. Other languages don't do this. So, the question is, should a DW_TAG_structure_type end up in the tag domain, or the type domain, or should it be language-dependent? I settled on making it language-dependent using a thought experiment. Suppose there was a Rust compiler that only emitted nameless DW_TAG_structure_type objects, and specified all structure type names using DW_TAG_typedef. This DWARF would be correct, in that it faithfully represents the source language -- but would not work with a purely struct-domain implementation in gdb. Therefore gdb would be wrong. Now, this approach is a little tricky for C++, which uses tags but also enters a typedef for them. I notice that some other readers -- like stabsread -- actually emit a typedef symbol as well. And, I think this is a reasonable approach. It uses more memory, but it makes the internals simpler. However, DWARF never did this for whatever reason, and so in the interest of keeping the series slightly shorter, I've left some C++-specific hacks in place here. Note that this patch includes language_minimal as a language that uses tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, which doesn't specify the language for a type unit. Arguably this test case is wrong. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
2024-01-28Remove old symbol_matches_domainTom Tromey
Nothing calls the variant of symbol_matches_domain that accepts a domain_enum for searching, so this patch removes it and the corresponding symbol::matches.
2024-01-28Remove some obsolete Python constantsTom Tromey
The Python code has exported some constants, but they are no longer documented, and were never useful. This patch removes them.
2024-01-28Use domain_search_flags in lookup_symbol et alTom Tromey
This changes lookup_symbol and associated APIs to accept domain_search_flags rather than a domain_enum. Note that this introduces some new constants to Python and Guile. I chose to break out the documentation patch for this, because the internals here do not change until a later patch, and it seemed simpler to patch the docs just once, rather than twice.
2024-01-28Use domain_search_flags in lookup_global_symbol_languageTom Tromey
This changes quick_symbol_functions::lookup_global_symbol_language to accept domain_search_flags rather than just a domain_enum, and fixes up the fallout. To avoid introducing any regressions, any code passing VAR_DOMAIN now uses SEARCH_VFT. That is, no visible changes should result from this patch. However, it sets the stage to refine some searches later on.
2024-01-28Introduce "scripting" domainsTom Tromey
The Python and Guile code exposed the internal domain constants both as attributes of symbols and as values to pass to lookup functions. Now, perfect backward compatibility here can't be achieved: some symbols are going to have domain changes by the end of this series. However, it seemed to me that we can preserve lookups using the basic domain values. This patch implements this by exporting the "or"-able search constants with an extra bit set. Then it introduces some functions to convert such constants to domain_search_flags. This will be used by the Python and Guile code, so that both old- and new-style lookups will work properly; and while preserving the idea that the domain constants can be compared to a symbol's domain.
2024-01-28Remove a check of VAR_DOMAINTom Tromey
completion_list_add_symbol checks that the returned symbol has VAR_DOMAIN, but also checks that its address class is LOC_BLOCK. The domain check is redundant -- only functions can possibly be LOC_BLOCK -- and leaving this in place will cause a regression when combined with a later patch in this series. This patch preemptively removes the redundant check.