aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-03-16wipusers/roland/gprofng-zlibRoland McGrath2-8/+14
2022-03-16objcopy --weaken-symbol: apply to STB_GNU_UNIQUE symbolsFangrui Song5-2/+24
PR binutils/28926 * objcopy.c (filter_symbols): Apply weaken to STB_GNU_UNIQUE symbols * NEWS: Mention feature. * testsuite/binutils-all/objcopy.exp (objcopy_test_symbol_manipulation): New test. * testsuite/binutils-all/weaken-gnu-unique.s: New.
2022-03-16Reimplement array concatenation for Ada and DTom Tromey7-134/+131
This started as a patch to implement string concatenation for Ada. However, while working on this, I looked at how this code could possibly be called. It turns out there are only two users of concat_operation: Ada and D. So, in addition to implementing this for Ada, this patch rewrites value_concat, removing the odd "concatenate or repeat" semantics, which were completely unused. As Ada and D both seem to represent strings using TYPE_CODE_ARRAY, this removes the TYPE_CODE_STRING code from there as well.
2022-03-16Remove eval_op_concatTom Tromey3-18/+2
eval_op_concat has code to search for an operator overload of BINOP_CONCAT. However, the operator overloading code is specific to C++, which does not have this operator. And, binop_types_user_defined_p rejects this case right at the start, and value_x_binop does not handle this case. I think this code has been dead for a very long time. This patch removes it and hoists the remaining call into concatenation::evaluate, removing eval_op_concat entirely.
2022-03-16Ada support for wide stringsTom Tromey3-6/+63
This adds some basic support for Wide_String and Wide_Wide_String to the Ada expression evaluator. In particular, a string literal may be converted to a wide or wide-wide string depending on context. The patch updates an existing test case. Note that another test, namely something like: ptype Wide_Wide_String'("literal") ... would be nice to add, but when tested against a distro GNAT, this did not work (probably due to lack of debuginfo); so, I haven't included it here.
2022-03-16Remove eval_op_stringTom Tromey2-15/+11
eval_op_string is only used in a single place -- the implementation of string_operation. This patch turns it into the string_operation::evaluate method, removing a bit of extraneous code.
2022-03-16Powerpc fix for gdb.base/ending-run.expCarl Love1-0/+16
The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the system does not have the needed glibc debug-info files loaded. In this case, gdb is not able to determine where execution stopped. This behavior looks as follows for the test case: The next to the last test does a next command when the program is stopped at the closing bracket for main. The message printed is: 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6 which fails to match any of the test_multiple options. The test then does another next command. On Powerpc, the message printed it: Cannot find bounds of current function The test fails as the output does not match any of the options for the gdb_test_multiple. I checked the behavior on Powerpc to see if this is typical. I ran gdb on the following simple program as shown below. #include <stdio.h> int main(void) { printf("Hello, world!\n"); return 0; } gdb ./hello_world <snip the gdb start info> Type "apropos word" to search for commands related to "word"... Reading symbols from ./hello_world... (No debugging symbols found in ./hello_world) (gdb) break main Breakpoint 1 at 0x818 (gdb) r Starting program: /home/carll/hello_world [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1". Breakpoint 1, 0x0000000100000818 in main () (gdb) n Single stepping until exit from function main, which has no line number information. Hello, world! 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6 (gdb) n Cannot find bounds of current function So it would seem that the messages seen from the test case are "normal" output for Powerpc when the debug-info is not available. The following patch adds the output from Powerpc as an option to the gdb_test_multiple statement, identifying the output as the expected output on Powerpc without the needed debug-info files installed. The patch has been tested on a Power 10 system and an Intel 64-bit system. No additional regression failures were seen on either platform.
2022-03-16dlltool: Use the output name as basis for deterministic temp prefixesMartin Storsj?2-3/+10
PR 28885 * dlltool.c (main): use imp_name rather than dll_name when generating a temporary file name.
2022-03-16gdb/mi: consistently notify user when GDB/MI client uses -thread-selectJan Vrany8-69/+106
GDB notifies users about user selected thread changes somewhat inconsistently as mentioned on gdb-patches mailing list here: https://sourceware.org/pipermail/gdb-patches/2022-February/185989.html Consider GDB debugging a multi-threaded inferior with both CLI and GDB/MI interfaces connected to separate terminals. Assuming inferior is stopped and thread 1 is selected, when a thread 2 is selected using '-thread-select 2' command on GDB/MI terminal: -thread-select 2 ^done,new-thread-id="2",frame={level="0",addr="0x00005555555551cd",func="child_sub_function",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="30",arch="i386:x86-64"} (gdb) and on CLI terminal we get the notification (as expected): [Switching to thread 2 (Thread 0x7ffff7daa640 (LWP 389659))] #0 child_sub_function () at /home/uuu/gdb/gdb/testsuite/gdb.mi/user-selected-context-sync.c:30 30 volatile int dummy = 0; However, now that thread 2 is selected, if thread 1 is selected using 'thread-select --thread 1 1' command on GDB/MI terminal terminal: -thread-select --thread 1 1 ^done,new-thread-id="1",frame={level="0",addr="0x0000555555555294",func="main",args=[],file="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",fullname="/home/jv/Projects/gdb/users_jv_patches/gdb/testsuite/gdb.mi/user-selected-context-sync.c",line="66",arch="i386:x86-64"} (gdb) but no notification is printed on CLI terminal, despite the fact that user selected thread has changed. The problem is that when `-thread-select --thread 1 1` is executed then thread is switched to thread 1 before mi_cmd_thread_select () is called, therefore the condition "inferior_ptid != previous_ptid" there does not hold. To address this problem, we have to move notification logic up to mi_cmd_execute () where --thread option is processed and notify user selected contents observers there if context changes. However, this in itself breaks GDB/MI because it would cause context notification to be sent on MI channel. This is because by the time we notify, MI notification suppression is already restored (done in mi_command::invoke(). Therefore we had to lift notification suppression logic also up to mi_cmd_execute (). This change in made distinction between mi_command::invoke() and mi_command::do_invoke() unnecessary as all mi_command::invoke() did (after the change) was to call do_invoke(). So this patches removes do_invoke() and moves the command execution logic directly to invoke(). With this change, all gdb.mi tests pass, tested on x86_64-linux. Co-authored-by: Andrew Burgess <aburgess@redhat.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20631
2022-03-16gprofng: Use symver attribute if availableH.J. Lu6-86/+72
Use symver attribute if available, instead of asm statement, to support LTO build. PR gprof/28962 * libcollector/dispatcher.c (timer_create@@GLIBC_2.3.3): Use SYMVER_ATTRIBUTE. (timer_create@GLIBC_2.2): Likewise. (timer_create@GLIBC_2.2.5): Likewise. (pthread_create@@GLIBC_2.1): Likewise. (pthread_create@GLIBC_2.0): Likewise. * libcollector/iotrace.c (open64@@GLIBC_2.2): Likewise. (open64@GLIBC_2.1): Likewise. (fopen@@GLIBC_2.1): Likewise. (fopen@GLIBC_2.0): Likewise. (fclose@@GLIBC_2.1): Likewise. (fclose@GLIBC_2.0): Likewise. (fdopen@@GLIBC_2.1): Likewise. (fdopen@GLIBC_2.0): Likewise. (pread@@GLIBC_2.2): Likewise. (pread@GLIBC_2.1): Likewise. (pwrite@@GLIBC_2.2): Likewise. (pwrite@GLIBC_2.1): Likewise. (pwrite64@@GLIBC_2.2): Likewise. (pwrite64@GLIBC_2.1): Likewise. (fgetpos@@GLIBC_2.2): Likewise. (fgetpos@GLIBC_2.0): Likewise. (fgetpos64@@GLIBC_2.2): Likewise. (fgetpos64@GLIBC_2.1): Likewise. (fsetpos@@GLIBC_2.2): Likewise. (fsetpos@GLIBC_2.0): Likewise. (fsetpos64@@GLIBC_2.2): Likewise. (fsetpos64@GLIBC_2.1): Likewise. * libcollector/linetrace.c (posix_spawn@@GLIBC_2.15): Likewise. (posix_spawn@GLIBC_2.2): Likewise. (posix_spawn@GLIBC_2.2.5): Likewise. (posix_spawnp@@GLIBC_2.15): Likewise. (posix_spawnp@GLIBC_2.2): Likewise. (posix_spawnp@GLIBC_2.2.5): Likewise. (popen@@GLIBC_2.1): Likewise. (popen@GLIBC_2.0): Likewise. (_popen@@GLIBC_2.1): Likewise. (_popen@GLIBC_2.0): Likewise. * libcollector/mmaptrace.c (dlopen@@GLIBC_2.1): Likewise. (dlopen@GLIBC_2.0): Likewise. * libcollector/synctrace.c (pthread_cond_wait@@GLIBC_2.3.2): Likewise. (pthread_cond_wait@GLIBC_2.0): Likewise. (pthread_cond_wait@GLIBC_2.2.5): Likewise. (pthread_cond_wait@GLIBC_2.2): Likewise. (pthread_cond_timedwait@@GLIBC_2.3.2): Likewise. (pthread_cond_timedwait@GLIBC_2.0): Likewise. (pthread_cond_timedwait@GLIBC_2.2.5): Likewise. (pthread_cond_timedwait@GLIBC_2.2): Likewise. (sem_wait@@GLIBC_2.1): Likewise. (sem_wait@GLIBC_2.0): Likewise. * src/collector_module.h (SYMVER_ATTRIBUTE): New.
2022-03-16gprofng: Don't hardcode -Wno-format-truncation/-Wno-switchH.J. Lu5-6/+134
Use -Wno-format-truncation and -Wno-switch only if they are supported. PR gprof/28969 * configure.ac (GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS): New AC_SUBST for -Wno-format-truncation. (GPROFNG_NO_SWITCH_CFLAGS): New AC_SUBST for -Wno-switch. * Makefile.in: Regenerate. * configure: Likewise. * src/Makefile.am (AM_CFLAGS): Replace -Wno-format-truncation and -Wno-switch with GPROFNG_NO_FORMAT_TRUNCATION_CFLAGS and GPROFNG_NO_SWITCH_CFLAGS. * src/Makefile.in: Regenerate.
2022-03-16gprofng: Don't hardcode -Wno-nonnull-compareH.J. Lu5-4/+69
Use -Wno-nonnull-compare only if it is supported. PR gprof/28969 * libcollector/Makefile.am (AM_CFLAGS): Replace -Wno-nonnull-compare with GPROFNG_NO_NONNULL_COMPARE_CFLAGS. * libcollector/configure.ac (GPROFNG_NO_NONNULL_COMPARE_CFLAGS): New AC_SUBST for -Wno-nonnull-compare. * libcollector/Makefile.in: Regenerate. * libcollector/aclocal.m4: Likewise. * libcollector/configure: Likewise.
2022-03-16gprofng: Define ATTRIBUTE_FALLTHROUGHH.J. Lu2-1/+9
Define ATTRIBUTE_FALLTHROUGH to __attribute__ ((fallthrough)) only for GCC 7 or above. PR gprof/28969 * common/gp-defs.h (ATTRIBUTE_FALLTHROUGH): New. * src/gp-collect-app.cc (collect::check_args): Replace /* FALLTHROUGH */ with ATTRIBUTE_FALLTHROUGH.
2022-03-16binutils/readelf: handle AMDGPU relocation typesSimon Marchi4-0/+32
Make readelf recognize AMDGPU relocation types, as documented here: https://llvm.org/docs/AMDGPUUsage.html#amdgpu-relocation-records The user-visible change looks like: -000000000004 000400000001 unrecognized: 1 0000000000000000 SCRATCH_RSRC_DWORD0 -00000000000c 000500000001 unrecognized: 1 0000000000000000 SCRATCH_RSRC_DWORD1 -000000000014 000600000007 unrecognized: 7 0000000000000000 global_var0 -00000000001c 000700000008 unrecognized: 8 0000000000000000 global_var1 -000000000024 000800000009 unrecognized: 9 0000000000000000 global_var2 -00000000002c 00090000000a unrecognized: a 0000000000000000 global_var3 -000000000034 000a0000000b unrecognized: b 0000000000000000 global_var4 +000000000004 000400000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD0 +00000000000c 000500000001 R_AMDGPU_ABS32_LO 0000000000000000 SCRATCH_RSRC_DWORD1 +000000000014 000600000007 R_AMDGPU_GOTPCREL 0000000000000000 global_var0 +00000000001c 000700000008 R_AMDGPU_GOTPCREL 0000000000000000 global_var1 +000000000024 000800000009 R_AMDGPU_GOTPCREL 0000000000000000 global_var2 +00000000002c 00090000000a R_AMDGPU_REL32_LO 0000000000000000 global_var3 +000000000034 000a0000000b R_AMDGPU_REL32_HI 0000000000000000 global_var4 binutils/ChangeLog: * readelf.c (dump_relocations): Handle EM_AMDGPU. include/ChangeLog: * elf/amdgpu.h: Add relocation values. Change-Id: I2ed4589f4cd37ea11ad2e0cb38d4b682271e1334
2022-03-16binutils/readelf: build against msgpack, dump NT_AMDGPU_METADATA note contentsSimon Marchi7-19/+374
The AMDGPU HSA OS ABI (code object v3 and above) defines the NT_AMDGPU_METADATA ELF note [1]. The content is a msgpack object describing, among other things, the kernels present in the code object and how to call them. I think it would be useful for readelf to be able to display the content of those notes. msgpack is a structured format, a bit like JSON, except not text-based. It is therefore possible to dump the contents in human-readable form without knowledge of the specific layout of the note. Add configury to binutils to optionally check for the msgpack C library [2]. Add There is a new --with{,out}-msgpack configure flag, and the actual library lookup is done using pkg-config. If msgpack support is enabled, dumping a NT_AMDGPU_METADATA note looks like: $ readelf --notes amdgpu-code-object Displaying notes found in: .note Owner Data size Description AMDGPU 0x0000040d NT_AMDGPU_METADATA (code object metadata) { "amdhsa.kernels": [ { ".args": [ { ".address_space": "global", ".name": "out.coerce", ".offset": 0, ".size": 8, ".value_kind": "global_buffer", }, <snip> If msgpack support is disabled, dump the contents as hex, as is done with notes that are not handled in a special way. This allows one to decode the contents manually (maybe using a command-line msgpack decoder) if really needed. [1] https://llvm.org/docs/AMDGPUUsage.html#code-object-metadata [2] https://github.com/msgpack/msgpack-c/tree/c_master binutils/ChangeLog: * Makefile.am (readelf_CFLAGS): New. (readelf_LDADD): Add MSGPACK_LIBS. * Makefile.in: Re-generate. * config.in: Re-generate. * configure: Re-generate. * configure.ac: Add --with-msgpack flag and check for msgpack using pkg-config. * readelf.c: Include msgpack.h if HAVE_MSGPACK. (print_note_contents_hex): New. (print_indents): New. (dump_msgpack_obj): New. (dump_msgpack): New. (print_amdgpu_note): New. (process_note): Handle NT_AMDGPU_METADATA note contents. Use print_note_contents_hex. Change-Id: Ia60a654e620bc32dfdb1bccd845594e2af328b84
2022-03-16binutils/readelf: handle NT_AMDGPU_METADATA note nameSimon Marchi4-0/+33
Handle the NT_AMDGPU_METADATA note, which is described here: https://llvm.org/docs/AMDGPUUsage.html#code-object-v3-note-records As of this patch, just print out the name, not the contents, which is in the msgpack format. binutils/ChangeLog: * readelf.c (get_amdgpu_elf_note_type): New. (process_note): Handle "AMDGPU" notes. include/ChangeLog: * elf/amdgcn.h (NT_AMDGPU_METADATA): New. Change-Id: Id2dba2e2aeaa55ef7464fb35aee9c7d5f96ddb23
2022-03-16binutils/readelf: decode AMDGPU-specific e_flagsSimon Marchi4-0/+217
Decode and print the AMDGPU-specific fields of e_flags, as documented here: https://llvm.org/docs/AMDGPUUsage.html#header That is: - The specific GPU model - Whether the xnack and sramecc features are enabled The result looks like: - Flags: 0x52f + Flags: 0x52f, gfx906, xnack any, sramecc any The flags for the "HSA" OS ABI are properly versioned and documented on that page. But the NONE, PAL and MESA3D OS ABIs are not well documented nor versioned. Taking a peek at the LLVM source code, we see that they encode their flags the same way as HSA v3. For example, for PAL: https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601 So for those other OS ABIs, we read them the same as HSA v3. binutils/ChangeLog: * readelf.c: Include elf/amdgcn.h. (decode_AMDGPU_machine_flags): New. (get_machine_flags): Handle flags for EM_AMDGPU machine type. include/ChangeLog: * elf/amdgcn.h: Add EF_AMDGPU_MACH_AMDGCN_* and EF_AMDGPU_FEATURE_* defines. Change-Id: Ib5b94df7cae0719a22cf4e4fd0629330e9485c12
2022-03-16binutils/readelf: handle AMDGPU OS ABIsSimon Marchi4-0/+22
When the machine is EM_AMDGPU, handle the various OS ABIs described here: https://llvm.org/docs/AMDGPUUsage.html#header For a binary with the HSA OS ABI, the change looks like: - OS/ABI: <unknown: 40> + OS/ABI: AMD HSA binutils/ChangeLog: * readelf.c (get_osabi_name): Handle EM_AMDGPU OS ABIs. include/ChangeLog: * elf/common.h (ELFOSABI_AMDGPU_PAL, ELFOSABI_AMDGPU_MESA3D): New. Change-Id: I383590c390f7dc2fe0f902f50038735626d71863
2022-03-16opcodes: handle bfd_amdgcn_arch in configure scriptSimon Marchi3-0/+7
There isn't an actual opcodes implementation for the AMDGCN arch (yet), this is just the bare minimum to get $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas $ make all-binutils working later in this series. opcodes/ChangeLog: * configure.ac: Handle bfd_amdgcn_arch. * configure: Re-generate. Change-Id: Ib7d7c5533a803ed8b2a293e9275f667ed781ce79
2022-03-16bfd: add AMDGCN architectureSimon Marchi15-0/+253
Add support for the AMDGCN architecture to BFD. This is the bare minimum to get $ ./configure --target=amdgcn-hsa-amdhsa --disable-gas $ make all-binutils working later in this series. The specific AMDGCN models added here are a bit arbitrary, based on what we intend to initially support in GDB. This list will need to be updated in the future anyway. The complete up-to-date list of existing AMDGPU models can be found here: https://llvm.org/docs/AMDGPUUsage.html#processors The ELF format for this architecture is documented here: https://llvm.org/docs/AMDGPUUsage.html#elf-code-object The flags for the "HSA" OS ABI are properly versioned and documented on that page. But the NONE, PAL and MESA3D OS ABIs are not well documented nor versioned. Taking a peek at the LLVM source code, we see that they encode their flags the same way as HSA v3. For example, for PAL: https://github.com/llvm/llvm-project/blob/c8b614cd74a92d85936aed5ac7c642af75ffdc29/llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp#L601 So at least, we know that all AMDGPU objects (of which AMDGCN objects are a subset of) at the time of writing encode the specific GPU model in the EF_AMDGPU_MACH field of e_flags. bfd/ChangeLog: * Makefile.am (ALL_MACHINES, ALL_MACHINES_CFILES): Add cpu-amdgcn.c. (BFD64_BACKENDS): Add elf64-amdgcn.lo. (BFD64_BACKENDS_CFILES): Add elf64-amdgcn.c. * Makefile.in: Re-generate. * cpu-amdgcn.c: New. * elf64-amdgcn.c: New. * archures.c (bfd_architecture): Add bfd_arch_amdgcn and related mach defines. (bfd_amdgcn_arch): New. (bfd_archures_list): Add bfd_amdgcn_arch. * bfd-in2.h: Re-generate. * config.bfd: Handle amdgcn* target. * configure.ac: Handle amdgcn_elf64_le_vec. * configure: Re-generate. * elf-bfd.h (elf_target_id): Add AMDGCN_ELF_DATA. * targets.c (amdgcn_elf64_le_vec): New. (_bfd_target_vector): Add amdgcn_elf64_le_vec. include/ChangeLog: * elf/amdgpu.h: New. * elf/common.h (ELFOSABI_AMDGPU_HSA): Add. Change-Id: I969f7b14960797e88891c308749a6e341eece5b2
2022-03-16Updated Serbian (for binutils/) and Russian (for gprof/) translationsNick Clifton4-2058/+2451
2022-03-16Make gdb.fortran/{array-slices,lbound-ubound} work against gdbserverPedro Alves3-15/+45
gdb.fortran/array-slices.exp and gdb.fortran/lbound-ubound.exp were recently disabled unless testing with the native target, because they rely on inferior I/O. However, when testing against gdbserver using the native-gdbserver/native-extended-gdbserver boards, we do have access to inferior I/O. The right way to check whether the board can do I/O, is via checking the gdb,noinferiorio board variable. Switch to using that. And then, tweak the testcases to expect output to appear in inferior_spawn_id, instead of gdb_spawn_id. When testing against the native target, inferior_spawn_id is the same as gdb_spawn_id. When testing against gdbserver, it maps to gdbserver_spawn_id. This exposed a buglet in gdb.fortran/array-slices.f90's show_1d subroutine -- it was missing printing newline at the end of the "Expected GDB Output" text, leading to a test timeout. All other subroutines end with advance=yes, except this one. Fix it by using advance=yes here too. Change-Id: I4640729f334431cfc24b0917e7d3977b677c6ca5
2022-03-16Automatic date update in version.inGDB Administrator1-1/+1
2022-03-16Delete PowerPC macro insn supportAlan Modra3-155/+3
Let's hope this stays dead, but it's here as a patch separate from those that removed use of powerpc_macros just in case it needs to be resurrected. include/ * opcode/ppc.h (struct powerpc_macro): Delete declaration. (powerpc_macros, powerpc_num_macros): Likewise.. opcodes/ * ppc-opc.c (powerpc_macros, powerpc_num_macros): Delete. gas/ * config/tc-ppc.c (ppc_macro): Delete function. (ppc_macro_hash): Delete. (ppc_setup_opcodes, md_assemble): Delete macro support.
2022-03-16PowerPC SPE/SPE2 aliases in powerpc_macrosAlan Modra1-30/+27
* ppc-opc.c (powerpc_macros): Move "evsadd", "evssub", "evsabs", "evsnabs", "evsneg", "evsmul", "evsdiv", "evscmpgt", "evsgmplt", "evsgmpeq", "evscfui", "evscfsi", "evscfuf", "evscfsf", "evsctui", "evsctsi", "evsctuf", "evsctsf", "evsctuiz", "evsctsiz", "evststgt", "evststlt", "evststeq".. (powerpc_opcodes): ..to here. (powerpc_macros): Move "evdotphsssi", "evdotphsssia", "evdotpwsssi", and "evdotpwsssia".. (spe2_opcodes): ..to here.
2022-03-16PowerPC VLE extended instructions in powerpc_macrosAlan Modra2-18/+15
This moves VLE insn out of the macro table. "e_slwi" and "e_srwi" already exist in vle_opcodes as distinct instructions rather than encodings of e_rlwinm. opcodes/ * ppc-opc.c (vle_opcodes): Typo fix e_rlwinm operand. Add "e_inslwi", "e_insrwi", "e_rotlwi", "e_rotrwi", "e_clrlwi", "e_clrrwi", "e_extlwi", "e_extrwi", and "e_clrlslwi". (powerpc_macros): Delete same. Delete "e_slwi" and "e_srwi" too. gas/ * testsuite/gas/ppc/vle-simple-5.d: Update.
2022-03-16PowerPC32 extended instructions in powerpc_macrosAlan Modra3-42/+313
As for PowerPC64, move instructions to the main opcode table. opcodes/ * ppc-opc.c (insert_crwn, extract_crwn, insert_elwn, extract_elwn), (insert_erwn, extract_erwn, insert_erwb, extract_erwb), (insert_cslwn, extract_cslwb, insert_ilwb, extract_ilwn), (insert_irwb, extract_irwn, insert_rrwn, extract_rrwn), (insert_slwn, extract_slwn, insert_srwn, extract_srwn): New functions. (CRWn, ELWn, ERWn, ERWb, CSLWb, CSLWn, ILWn, ILWb, IRWn, IRWb), (RRWn, SLWn, SRWn): Define and add powerpc_operands entries. (MMB_MASK, MME_MASK, MSHMB_MASK): Define. (powerpc_opcodes): Add "inslwi", "insrwi", "rotrwi", "clrrwi", "slwi", "srwi", "extlwi", "extrwi", "sli", "sri" and corresponding record (ie. dot suffix) forms. (powerpc_macros): Delete same. gas/ * testsuite/gas/ppc/476.d: Update. * testsuite/gas/ppc/simpshft.d: Update.
2022-03-16PowerPC64 extended instructions in powerpc_macrosAlan Modra13-46/+274
The extended instructions implemented in powerpc_macros aren't used by the disassembler. That means instructions like "sldi r3,r3,2" appear in disassembly as "rldicr r3,r3,2,61", which is annoying since many other extended instructions are shown. Note that some of the instructions moved out of the macro table to the opcode table won't appear in disassembly, because they are aliases rather than a subset of the underlying raw instruction. If enabled, rotrdi, extrdi, extldi, clrlsldi, and insrdi would replace all occurrences of rotldi, rldicl, rldicr, rldic and rldimi. (Or many occurrences in the case of clrlsldi if n <= b was added to the extract functions.) The patch also fixes a small bug in opcode sanity checking. include/ * opcode/ppc.h (PPC_OPSHIFT_SH6): Define. opcodes/ * ppc-opc.c (insert_erdn, extract_erdn, insert_eldn, extract_eldn), (insert_crdn, extract_crdn, insert_rrdn, extract_rrdn), (insert_sldn, extract_sldn, insert_srdn, extract_srdn), (insert_erdb, extract_erdb, insert_csldn, extract_csldb), (insert_irdb, extract_irdn): New functions. (ELDn, ERDn, ERDn, RRDn, SRDn, ERDb, CSLDn, CSLDb, IRDn, IRDb): Define and add associated powerpc_operands entries. (powerpc_opcodes): Add "rotrdi", "srdi", "extrdi", "clrrdi", "sldi", "extldi", "clrlsldi", "insrdi" and corresponding record (ie. dot suffix) forms. (powerpc_macros): Delete same from here. gas/ * config/tc-ppc.c (insn_validate): Don't modify value passed to operand->insert for PPC_OPERAND_PLUS1 when calculating mask. Handle PPC_OPSHIFT_SH6. * testsuite/gas/ppc/prefix-reloc.d: Update. * testsuite/gas/ppc/simpshft.d: Update. ld/ * testsuite/ld-powerpc/elfv2so.d: Update. * testsuite/ld-powerpc/notoc.d: Update. * testsuite/ld-powerpc/notoc3.d: Update. * testsuite/ld-powerpc/tlsdesc2.d: Update. * testsuite/ld-powerpc/tlsget.d: Update. * testsuite/ld-powerpc/tlsget2.d: Update. * testsuite/ld-powerpc/tlsopt5.d: Update. * testsuite/ld-powerpc/tlsopt6.d: Update.
2022-03-15Do not capture updated 'pc' in add_local_symbolsTom Tromey1-2/+2
Simon pointed out that commit 13835d88 ("Use function view when iterating over block symbols") caused a regression. The bug is that the new closure captures 'pc' by reference, but later code updates this variable -- but the earlier code did not update the callback structure with the new value. This patch restores the old behavior by using a new varible name in an inner scope.
2022-03-15gprofng: avoid using `fallthrough' attributesJose E. Marchesi2-1/+6
gprofng didn't build with gcc 6.3 due to the usage of __attribute__ ((fallthrough)). This patch uses /* FALLTHROUGH */ instead. 2022-03-15 Jose E. Marchesi <jose.marchesi@oracle.com> * gprofng/src/gp-collect-app.cc (collect::check_args): Use fallthrough comment instead of attribute.
2022-03-15Fix bug in dwarf-mode.elTom Tromey2-4/+11
I noticed that, occasionally, dwarf-mode would think that the objdump subprocess was still running after it had clearly exited. I managed to reliably reproduce this today and learned that a process sentinel is not guaranteed to be run with the current buffer set to the process buffer. This patch fixes the problem. I've bumped the version number of dwarf-mode.el to make it easier to install for users who already have an earlier one installed. I'm checking this in. 2022-03-15 Tom Tromey <tromey@adacore.com> * dwarf-mode.el: Now 1.7. (dwarf--sentinel): Switch to the process buffer.
2022-03-15gdb/testsuite: rename a proc and fix a typoAndrew Burgess1-41/+41
Rename a proc in gdb.mi/user-selected-context-sync.exp, I think the old name was most likely a typo. The old name match_re_or_ensure_not_output seems (to me) to imply we're in some way checking that the regexp was not output. But that's not what we are doing, we're checking either for the regexp, or for no output, hence the new name match_re_or_ensure_no_output. Additionally, I found a definite typo in one of the comments that I've also fixed. I also updated some test names. These tests (probably due to copy & paste errors) has 'on MI' on their name, when they were actually checking CLI output. For these test I changed the name to use 'on CLI'. There should be no change in what is tested after this commit.
2022-03-15gprofng: Add a configure test for clock_gettime and a use of the test in ↵Nick Clifton8-16/+93
getthrtime.c
2022-03-15gprofng: Don't generate gprofng.info in sourceH.J. Lu2-20/+12
Add info-in-builddir to AUTOMAKE_OPTIONS. PR gprof/28967 * doc/Makefile.am (AUTOMAKE_OPTIONS): Add info-in-builddir. * doc/Makefile.in: Regenerate.
2022-03-15gdb: LoongArch: fix failed testcases in gdb.base/align-c.expTiezhu Yang1-0/+4
When execute the following command on LoongArch: make check-gdb TESTS="gdb.base/align-c.exp" there exist some failed testcases: ... FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_float) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_double) FAIL: gdb.base/align-c.exp: print _Alignof(struct align_pair_long_double_x_long_double) ... According to LoongArch ELF ABI specification [1], set the target data types of floating-point to fix the above failed testcases. [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-03-15Automatic date update in version.inGDB Administrator1-1/+1
2022-03-14gdb/python/mi: create MI commands using pythonAndrew Burgess12-18/+1553
This commit allows a user to create custom MI commands using Python similarly to what is possible for Python CLI commands. A new subclass of mi_command is defined for Python MI commands, mi_command_py. A new file, gdb/python/py-micmd.c contains the logic for Python MI commands. This commit is based on work linked too from this mailing list thread: https://sourceware.org/pipermail/gdb/2021-November/049774.html Which has also been previously posted to the mailing list here: https://sourceware.org/pipermail/gdb-patches/2019-May/158010.html And was recently reposted here: https://sourceware.org/pipermail/gdb-patches/2022-January/185190.html The version in this patch takes some core code from the previously posted patches, but also has some significant differences, especially after the feedback given here: https://sourceware.org/pipermail/gdb-patches/2022-February/185767.html A new MI command can be implemented in Python like this: class echo_args(gdb.MICommand): def invoke(self, args): return { 'args': args } echo_args("-echo-args") The 'args' parameter (to the invoke method) is a list containing (almost) all command line arguments passed to the MI command (--thread and --frame are handled before the Python code is called, and removed from the args list). This list can be empty if the MI command was passed no arguments. When used within gdb the above command produced output like this: (gdb) -echo-args a b c ^done,args=["a","b","c"] (gdb) The 'invoke' method of the new command must return a dictionary. The keys of this dictionary are then used as the field names in the mi command output (e.g. 'args' in the above). The values of the result returned by invoke can be dictionaries, lists, iterators, or an object that can be converted to a string. These are processed recursively to create the mi output. And so, this is valid: class new_command(gdb.MICommand): def invoke(self,args): return { 'result_one': { 'abc': 123, 'def': 'Hello' }, 'result_two': [ { 'a': 1, 'b': 2 }, { 'c': 3, 'd': 4 } ] } Which produces output like: (gdb) -new-command ^done,result_one={abc="123",def="Hello"},result_two=[{a="1",b="2"},{c="3",d="4"}] (gdb) I have required that the fields names used in mi result output must match the regexp: "^[a-zA-Z][-_a-zA-Z0-9]*$" (without the quotes). This restriction was never written down anywhere before, but seems sensible to me, and we can always loosen this rule later if it proves to be a problem. Much harder to try and add a restriction later, once people are already using the API. What follows are some details about how this implementation differs from the original patch that was posted to the mailing list. In this patch, I have changed how the lifetime of the Python gdb.MICommand objects is managed. In the original patch, these object were kept alive by an owned reference within the mi_command_py object. As such, the Python object would not be deleted until the mi_command_py object itself was deleted. This caused a problem, the mi_command_py were held in the global mi command table (in mi/mi-cmds.c), which, as a global, was not cleared until program shutdown. By this point the Python interpreter has already been shutdown. Attempting to delete the mi_command_py object at this point was causing GDB to try and invoke Python code after finalising the Python interpreter, and we would crash. To work around this problem, the original patch added code in python/python.c that would search the mi command table, and delete the mi_command_py objects before the Python environment was finalised. In contrast, in this patch, I have added a new global dictionary to the gdb module, gdb._mi_commands. We already have several such global data stores related to pretty printers, and frame unwinders. The MICommand objects are placed into the new gdb.mi_commands dictionary, and it is this reference that keeps the objects alive. When GDB's Python interpreter is shut down gdb._mi_commands is deleted, and any MICommand objects within it are deleted at this point. This change avoids having to make the mi_cmd_table global, and walk over it from within GDB's python related code. This patch handles command redefinition entirely within GDB's python code, though this does impose one small restriction which is not present in the original code (detailed below), I don't think this is a big issue. However, the original patch relied on being able to finish executing the mi_command::do_invoke member function after the mi_command object had been deleted. Though continuing to execute a member function after an object is deleted is well defined, it is also (IMHO) risky, its too easy for someone to later add a use of the object without realising that the object might sometimes, have been deleted. The new patch avoids this issue. The one restriction that is added to avoid this, is that an MICommand object can't be reinitialised with a different command name, so: (gdb) python cmd = MyMICommand("-abc") (gdb) python cmd.__init__("-def") can't reinitialize object with a different command name This feels like a pretty weird edge case, and I'm happy to live with this restriction. I have also changed how the memory is managed for the command name. In the most recently posted patch series, the command name is moved into a subclass of mi_command, the python mi_command_py, which inherits from mi_command is then free to use a smart pointer to manage the memory for the name. In this patch, I leave the mi_command class unchanged, and instead hold the memory for the name within the Python object, as the lifetime of the Python object always exceeds the c++ object stored in the mi_cmd_table. This adds a little more complexity in py-micmd.c, but leaves the mi_command class nice and simple. Next, this patch adds some extra functionality, there's a MICommand.name read-only attribute containing the name of the command, and a read-write MICommand.installed attribute that can be used to install (make the command available for use) and uninstall (remove the command from the mi_cmd_table so it can't be used) the command. This attribute will be automatically updated if a second command replaces an earlier command. This patch adds additional error handling, and makes more use the gdbpy_handle_exception function. Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
2022-03-14gdb/gdbarch: compare some fields against 0 verify_gdbarchAndrew Burgess3-6/+27
After the previous commit, which removes the predicate function gdbarch_register_type_p, I noticed that the gdbarch->register_type field was not checked at in the verify_gdbarch function. More than not being checked, the field wasn't mentioned at all. I find this strange, I would expect that every field would at least be mentioned - we already generate comments for some fields saying that this field is _not_ being checked, so the fact that this field isn't being checked looks (to me), like this field is somehow slipping through the cracks. The comment at the top of gdbarch-components.py tries to explain how the validation is done. I didn't understand this comment completely, but, I think this final sentence: "Otherwise, the check is done against 0 (really NULL for function pointers, but same idea)." Means that, if non of the other cases apply, then the field should be checked against 0, with 0 indicating that the field is invalid (was not set by the tdep code). However, this is clearly not being done. Looking in gdbarch.py at the code to generate verify_gdbarch we do find that there is a case that is not handled, the case where the 'invalid' field is set true True, but non of the other cases apply. In this commit I propose two changes: 1. Handle the case where the 'invalid' field of a property is set to True, this should perform a check for the field of gdbarch still being set to 0, and 2. If the if/else series that generates verify_gdbarch doesn't handle a property then we should raise an exception. This means that if a property is added which isn't handled, we should no longer silently ignore it. After doing this, I re-generated the gdbarch files and saw that the following gdbarch fields now had new validation checks: register_type believe_pcc_promotion register_to_value value_to_register frame_red_zone_size displaced_step_restore_all_in_ptid solib_symbols_extension Looking at how these are currently set in the various -tdep.c files, I believe the only one of these that is required to be set for all architectures is the register_type field. And so, for all of the other fields, I've changed the property definition on gdbarch-components.py, setting the 'invalid' field to False. Now, after re-generation, the register_type field is checked against 0, thus an architecture that doesn't set_gdbarch_register_type will now fail during validation. For all the other fields we skip the validation, in which case, it is find for an architecture to not set this field. My expectation is that there should be no user visible changes after this commit. Certainly for all fields except register_type, all I've really done is cause some extra comments to be generated, so I think that's clearly fine. For the register_type field, my claim is that any architecture that didn't provide this would fail when creating its register cache, and I couldn't spot an architecture that doesn't provide this hook. As such, I think this change should be fine too.
2022-03-14gdb/gdbarch: remove the predicate function for gdbarch_register_typeAndrew Burgess3-14/+0
I don't believe that the gdbarch_register_type_p predicate is called anywhere in GDB, and the gdbarch_register_type function is called without checking the gdbarch_register_type_p predicate function everywhere it is used, for example in init_regcache_descr (regcache.c). My claim is that the gdbarch_register_type function is required for every architecture, and GDB will not work if this function is not supplied. And so, in this commit, I remove the 'predicate=True' from gdbarch-components.py for the 'register_type' field, and regenerate the gdbarch files. There should be no user visible changes after this commit.
2022-03-14Replace deprecated_target_wait_hook by observersPatrick Monnerat7-24/+26
Commit b60cea7 (Make target_wait options use enum flags) broke deprecated_target_wait_hook usage: there's a commit comment telling this hook has not been converted. Rather than trying to mend it, this patch replaces the hook by two target_wait observers: target_pre_wait (ptid_t ptid) target_post_wait (ptid_t event_ptid) Upon target_wait entry, target_pre_wait is notified with the ptid passed to target_wait. Upon exit, target_post_wait is notified with the event ptid returned by target_wait. Should an exception occur, event_ptid is null_ptid. This change benefits to Insight (out-of-tree): there's no real use of the late hook in gdb itself.
2022-03-14Correctly print subrange types in generic_value_printTom Tromey2-1/+86
I noticed that generic_value_print assumes that a subrange type is always a subrange of an integer type. However, this isn't necessarily the case. In Ada, for example, one has subranges of character and enumeration types. This code isn't often exercised, I think, because languages with real subrange types tend to implement their own printers. However, it still seemed worth fixing.
2022-03-14[aarch64/arm] Properly extract the return value returned in memoryLuis Machado4-5/+130
When running gdb.cp/non-trivial-retval.exp, the following shows up for both aarch64-linux and armhf-linux: Breakpoint 3, f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 35 A a; (gdb) finish Run till exit from #0 f1 (i1=23, i2=100) at src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:35 main () at /src/gdb/testsuite/gdb.cp/non-trivial-retval.cc:163 163 B b = f2 (i1, i2); Value returned is $6 = {a = -11952} (gdb) The return value should be {a = 123} instead. This happens because the backends don't extract the return value from the correct location. GDB should fetch a pointer to the memory location from X8 for aarch64 and r0 for armhf. With the patch, gdb.cp/non-trivial-retval.exp has full passes on aarch64-linux and armhf-linux on Ubuntu 20.04/18.04. The problem only shows up with the "finish" command. The "call" command works correctly and displays the correct return value. This is also related to PR gdb/28681 (https://sourceware.org/bugzilla/show_bug.cgi?id=28681) and fixes FAIL's in gdb.ada/mi_var_array.exp. A new testcase is provided, and it exercises GDB's ability to "finish" a function that returns a large struct (> 16 bytes) and display the contents of this struct correctly. This has always been incorrect for these backends, but no testcase exercised this particular scenario.
2022-03-14Automatic date update in version.inGDB Administrator1-1/+1
2022-03-14PR28959, obdump doesn't disassemble mftb instructionAlan Modra1-2/+3
Without a -M cpu option given, powerpc objdump defaults currently to -Mpower10 but -Many is also given. Commit 1ff6a3b8e562 regressed -Many disassembly of instructions that are encoded differently depending on cpu, such as mftb which has pre- and post-power4 encodings. PR 28959 * ppc-dis.c (lookup_powerpc): Revert 2021-05-28 change. Instead only look at deprecated PPC_OPCODE_RAW bit when -Many.
2022-03-13Automatic date update in version.inGDB Administrator1-1/+1
2022-03-12Relax regexp in gdb.rust/unsized.expTom Tromey1-2/+1
With nightly rustc, gdb.rust/unsized.exp fails: (gdb) ptype *us Structure has no component named operator*. rustc changed to emit a bit more debug info for unsized types. Because the original test is just to make sure that ptype of an unsized array looks right, this patch relaxes the regexp and changes the expression. I think this keeps the original test meaning, but also works with nightly. I also tested stable and 1.48.
2022-03-12Automatic date update in version.inGDB Administrator1-1/+1
2022-03-11Avoid crash with cross-linux core fileTom Tromey1-4/+4
An internal test case creates a core file using gcore, then restarts gdb with that core. When run with a cross-linux gdb (in this case, x86-64 host with ppc64-linux target), the test fails: | (gdb) core core | [New LWP 18437] | warning: `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64. | warning: Could not load shared library symbols for /lib64/ld64.so.1. | Do you need "set solib-search-path" or "set sysroot"? | ../../src/gdb/gdbarch.c:3388: internal-error: int gdbarch_elf_make_msymbol_special_p(gdbarch*): Assertion `gdbarch != NULL' failed. | A problem internal to GDB has been detected, | further debugging may prove unreliable. | Quit this debugging session? (y or n) y What's happening here is that the core file lists some shared libraries. These aren't available via the solib search path, and so gdb finds the local (x86-64) libraries. This is not ideal, but on the other hand, it is what was asked for -- while the test does set solib-search-path, it does not set the sysroot. But, because gdb isn't configured to handle these libraries, it crashes. It seems to me that it's better to avoid the crash by having solib_bfd_open fail in the case where a library is incompatible. That is what this patch does. Now it looks like: | [New LWP 15488] | Error while mapping shared library sections: | `/lib64/libc.so.6': Shared library architecture unknown is not compatible with target architecture powerpc:common64. ... and does not crash gdb. I don't have a good setup for testing this using dejagnu, so I don't know whether an existing gdb test covers this scenario.
2022-03-11gdb/testsuite: remove duplicates from gdb.base/stap-probe.expAndrew Burgess1-6/+11
Remove the duplicate test names from gdb.base/stap-probe.exp, this is done by actually passing a unique test name in a couple of places (rather than using the command as the test name), and in another couple of places, a test has a duplicate name due to a cut & paste error, which I've fixed. There's no change in what is actually being tested after this commit.
2022-03-11gprofng: a new GNU profilerVladimir Mezentsev319-8/+222979
top-level * Makefile.def: Add gprofng module. * configure.ac: Add --enable-gprofng option. * src-release.sh: Add gprofng. * Makefile.in: Regenerate. * configure: Regenerate. * gprofng: New directory. binutils * MAINTAINERS: Add gprofng maintainer. * README-how-to-make-a-release: Add gprofng. include. * collectorAPI.h: New file. * libcollector.h: New file. * libfcollector.h: New file.
generated by cgit v1.1 at 2025-04-02 11:57:46 +0000