aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-12-16Fix AVR assembler so that it creates relocs that will work with linker ↵Nick Clifton11-11/+60
relaxation. PR 28686 gas * config/tc-avr.h (tc_fix_adjustable): Define. * config/tc-avr.c (avr_fix_adjustable): New function. * testsuite/gas/all/gas.exp: Skip tests that need adjustable fixups. * testsuite/gas/elf/elf.exp: Likewise. * testsuite/gas/avr/diffreloc_withrelax.d: Adjust expected output. * testsuite/gas/avr/pc-relative-reloc.d: Adjust expected output. ld * testsuite/ld-avr/avr-prop-7.d: Adjust expected output. * testsuite/ld-avr/avr-prop-8.d: Likewise. * testsuite/ld-avr/pr13402.d: Likewise.
2021-12-16When loading separate debug info files, also attempt to locate a file based ↵Nick Clifton4-4/+131
upon the build-id. PR 28697 * dwarf.c (load_build_id_debug_file): New function. (try_build_id_prefix): New function. (check_for_and_load_links): Call load_build_id_debug_file. (debug_displays): Add entry for .note.gnu.build-id. * dwarf.h (enum dwarf_section_display_enum): Add note_gnu_build_id. * testsuite/binutils-all/debuginfod.exp (test_fetch_debuglink): Fix regexp for loads via debuglink section.
2021-12-16arm: Add support for Armv9.1-A to Armv9.3-ARichard Sandiford12-3/+101
This patch adds AArch32 support for -march=armv9.[123]-a. The behaviour of the new options can be expressed using a combination of existing feature flags and tables. The cpu_arch_ver entries for ARM_ARCH_V9_2A and ARM_ARCH_V9_3A are technically redundant but it seemed less surprising to include them anyway. include/ * opcode/arm.h (ARM_ARCH_V9_1A, ARM_ARCH_V9_2A): New macros. (ARM_ARCH_V9_3A): Likewise. gas/ * doc/c-arm.texi: Add armv9.1-a, armv9.2-a and armv9.3-a. * config/tc-arm.c (armv91a_ext_table, armv92a_ext_table): New macros. (armv93a_ext_table): Likewise. (arm_archs): Add armv9.1-a, armv9.2-a and armv9.3-a. (cpu_arch_ver): Add ARM_ARCH_V9_1A, ARM_ARCH_V9_2A and ARM_ARCH_V9_3A. * NEWS: Mention the above. * testsuite/gas/arm/attr-march-armv9_1-a.d: New test. * testsuite/gas/arm/attr-march-armv9_2-a.d: Likewise. * testsuite/gas/arm/attr-march-armv9_3-a.d: Likewise. * testsuite/gas/arm/bfloat16-armv9.1-a.d: Likewise. * testsuite/gas/arm/bfloat16-armv9.2-a.d: Likewise. * testsuite/gas/arm/bfloat16-armv9.3-a.d: Likewise. * testsuite/gas/arm/i8mm-armv9.1-a.d: Likewise. * testsuite/gas/arm/i8mm-armv9.2-a.d: Likewise. * testsuite/gas/arm/i8mm-armv9.3-a.d: Likewise.
2021-12-16arm: Add support for Armv8.7-A and Armv8.8-ARichard Sandiford10-1/+67
This patch adds AArch32 support for -march=armv8.[78]-a. The behaviour of the new options can be expressed using a combination of existing feature flags and tables. The cpu_arch_ver entries are technically redundant but it seemed less surprising to include them anyway. include/ * opcode/arm.h (ARM_ARCH_V8_7A, ARM_ARCH_V8_8A): New macros. gas/ * doc/c-arm.texi: Add armv8.7-a and armv8.8-a. * config/tc-arm.c (armv87a_ext_table, armv88a_ext_table): New macros. (arm_archs): Add armv8.7-a and armv8.8-a. (cpu_arch_ver): Add ARM_ARCH_V8_7A and ARM_ARCH_V8_8A. * NEWS: Mention the above. * testsuite/gas/arm/attr-march-armv8_7-a.d: New test. * testsuite/gas/arm/attr-march-armv8_8-a.d: Likewise. * testsuite/gas/arm/bfloat16-armv8.7-a.d: Likewise. * testsuite/gas/arm/bfloat16-armv8.8-a.d: Likewise. * testsuite/gas/arm/i8mm-armv8.7-a.d: Likewise. * testsuite/gas/arm/i8mm-armv8.8-a.d: Likewise.
2021-12-16aarch64: Add support for Armv9.1-A to Armv9.3-ARichard Sandiford19-42/+157
This patch adds AArch64 support for -march=armv9.[123]-a. The behaviour of the new options can be expressed using a combination of existing feature flags, so we don't need to eat into the vanishing number of spare AARCH64_FEATURE_* bits. Hoewver, it was more convenient to separate out the |s of feature flags so that Armv9.1-A could reuse the set for Armv8.6-A, and so on. include/ * opcode/aarch64.h (AARCH64_ARCH_V8_FEATURES): New macro, split out from... (AARCH64_ARCH_V8): ...here. (AARCH64_ARCH_V8_1_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_1): ...here. (AARCH64_ARCH_V8_2_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_2): ...here. (AARCH64_ARCH_V8_3_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_3): ...here. (AARCH64_ARCH_V8_4_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_4): ...here. (AARCH64_ARCH_V8_5_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_5): ...here. (AARCH64_ARCH_V8_6_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_6): ...here. (AARCH64_ARCH_V8_7_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_7): ...here. (AARCH64_ARCH_V8_8_FEATURES): New macro, split out from... (AARCH64_ARCH_V8_8): ...here. (AARCH64_ARCH_V9_FEATURES): New macro, split out from... (AARCH64_ARCH_V9): ...here. (AARCH64_ARCH_V9_1_FEATURES, AARCH64_ARCH_V9_1): New macros. (AARCH64_ARCH_V9_2_FEATURES, AARCH64_ARCH_V9_2): New macros. (AARCH64_ARCH_V9_3_FEATURES, AARCH64_ARCH_V9_3): New macros. gas/ * doc/c-aarch64.texi: Add armv9.1-a, armv9-2-a and armv9.3-a. * config/tc-aarch64.c (aarch64_archs): Likewise. * NEWS: Mention the above. * testsuite/gas/aarch64/armv9_invalid.d, testsuite/gas/aarch64/armv9_invalid.s, testsuite/gas/aarch64/armv9_invalid.l: New test. * testsuite/gas/aarch64/armv9_1.d, testsuite/gas/aarch64/armv9_1.s: Likewise. * testsuite/gas/aarch64/armv9_1_invalid.d, testsuite/gas/aarch64/armv9_1_invalid.s, testsuite/gas/aarch64/armv9_1_invalid.l: Likewise. * testsuite/gas/aarch64/armv9_2.d, testsuite/gas/aarch64/armv9_2.s: Likewise. * testsuite/gas/aarch64/armv9_2_invalid.d, testsuite/gas/aarch64/armv9_2_invalid.s, testsuite/gas/aarch64/armv9_2_invalid.l: Likewise. * testsuite/gas/aarch64/armv9_3.d, testsuite/gas/aarch64/armv9_3.s: Likewise.
2021-12-16RISC-V: Support svinval extension with frozen version 1.0.Nelson Chu6-0/+47
According to the privileged spec, there are five new instructions for svinval extension. Two of them (HINVAL.VVMA and HINVAL.GVMA) need to enable the hypervisor extension. But there is no implementation of hypervisor extension in mainline for now, so let's consider the related issues later. 31..25 24..20 19..15 14..12 11...7 6..2 1..0 sinval.vma 0001011 rs2 rs1 000 00000 11100 11 sfence.w.inval 0001100 00000 00000 000 00000 11100 11 sfence.inval.ir 0001100 00001 00000 000 00000 11100 11 hinval.vvma 0010011 rs2 rs1 000 00000 11100 11 hinval.gvma 0110011 rs2 rs1 000 00000 11100 11 This patch is cherry-picked from the riscv integration branch since the svinval extension is frozen for now. Besides, we fix the funct7 encodings of hinval.vvma and hinval.gvma, from 0x0011011 and 0x0111011 to 0x0010011 and 0x0110011. bfd/ * elfxx-riscv.c (riscv_supported_std_s_ext): Added svinval. (riscv_multi_subset_supports): Handle INSN_CLASS_SVINVAL. gas/ * testsuite/gas/riscv/svinval.d: New testcase. * testsuite/gas/riscv/svinval.s: Likewise. include/ * opcode/riscv-opc.h: Added encodings for svinval. * opcode/riscv.h (enum riscv_insn_class): Added INSN_CLASS_SVINVAL. opcodes/ * riscv-opc.c (riscv_opcodes): Added svinval instructions.
2021-12-16sim: mips/or1k: drop redundant arg to bitsize macroMike Frysinger4-6/+4
These are just using the default behavior for the 3rd arg, so drop it to make it more clear. This also makes them match all other ports that only use the first 2 arguments.
2021-12-16bfd: unify texi generation rulesMike Frysinger2-184/+74
The logic between these rules are extremely similar, so unify them into a single variable by leveraging make $@ and $< variables. Also add automake silent rule support while we're here.
2021-12-16sim: fix mingw builds with replacement gnulib openMike Frysinger1-2/+2
The header shuffling in here broke the workaround for gnulib defining "open". Move it back before the sim-specific includes to fix. This is because the callback struct in the headers has an "open" member and this file tries to call that.
2021-12-16Adjust compare_link_order for unstable qsortSandra Loosemore1-5/+6
In a cross toolchain for nios2-elf target and x86_64-w64-mingw32 host using binutils 2.37, we observed a failure that didn't show up on x86_64-linux-gnu host: testcase pr25490-5.s was failing with C:\path\to\nios2-elf-ld.exe: looping in map_segments FAIL: __patchable_function_entries section 5 * ldelfgen.c (compare_link_order): Don't use section id in sorting. Keep original ordering instead. Update comments.
2021-12-16Re: Fix an undefined behaviour in the BFD library's DWARF parserAlan Modra1-4/+4
Using an unsigned int cast (to 32 bits) on a pointer difference (of possibly 64 bits) is wrong. Even though it will work on all real object files, the fuzzers will eventually find this hole. PR 28687 * dwarf1.c (parse_die): Cast pointer difference to size_t. Catch another possible pointer overflow.
2021-12-15gdb: re-format with black 21.12b0Simon Marchi1-1/+0
Run black 21.12b0 on gdb/, there is a single whitespace change. I will update the wiki [1] in parallel to bump the version of black to 21.12b0. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards Change-Id: Ib3b859e3506c74a4f15d16f1e44ef402de3b98e2
2021-12-15gdb: re-format with black 21.9b0Simon Marchi3-11/+19
Run black 21.9b0 on gdb/ (this is the version currently mentioned on the wiki [1], the subsequent commit will bump that version). [1] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards Change-Id: I5ceaab42c42428e053e2572df172aa42a88f0f86
2021-12-16Automatic date update in version.inGDB Administrator1-1/+1
2021-12-16PR28691, validate dwarf attribute formAlan Modra1-56/+128
PR28691 is a fuzzing PR that triggers a non-problem of "output changes per run" with PIEs and/or different compilers. I've closed similar PRs before as wontfix, but I guess there will be no end of this type of PR. The trigger is an attribute that usually takes one of the offset/constant reference DW_FORMs being given an indexed string DW_FORM. The bfd reader doesn't support indexed strings and returns an error string instead. The address of the string varies with PIE runs and/or compiler, and we allow that address to appear in output. Fix this by validating integer attribute forms, as we do for string form attributes. PR 28691 * dwarf2.c (is_str_attr): Rename to.. (is_str_form): ..this. Change param type. Update calls. (is_int_form): New function. (read_attribute_value): Handle DW_FORM_addrx2. (find_abstract_instance): Validate form when using attr.u.val. (scan_unit_for_symbols, parse_comp_unit): Likewise.
2021-12-15New --enable-threading configure option to control use of threads in ↵Luis Machado5-6/+99
GDB/GDBserver Add the --enable-threading configure option so multithreading can be disabled at configure time. This is useful for statically-linked builds of GDB/GDBserver, since the thread library doesn't play well with that setup. If you try to run a statically-linked GDB built with threading, it will crash when setting up the number of worker threads. This new option is also convenient when debugging GDB in a system with lots of threads, where the thread discovery code in GDB will emit too many messages, like so: [New Thread 0xfffff74d3a50 (LWP 2625599)] If you have X threads, that message will be repeated X times. The default for --enable-threading is "yes".
2021-12-15Fix an undefined behaviour in the BFD library's DWARF parser.Nikita Popov2-4/+7
PR 28687 * dwarf1.c (parse_die): Fix undefined behaviour in range tests.
2021-12-15PR28694, Out-of-bounds write in stab_xcoff_builtin_typeAlan Modra1-44/+43
PR 28694 * stabs.c (stab_xcoff_builtin_type): Make typenum unsigned. Negate typenum earlier, simplifying bounds checking. Correct off-by-one indexing. Adjust switch cases.
2021-12-15Automatic date update in version.inGDB Administrator1-1/+1
2021-12-15loongarch32 build failure on 32-bit hostAlan Modra1-1/+1
gas/config/tc-loongarch.c: In function ‘assember_macro_helper’: gas/config/tc-loongarch.c:915:28: error: right shift count >= width of type [-Werror=shift-count-overflow] 915 | hi32 = insn->args[1] >> 32; | ^~ One possible fix is to make offsetT a 64-bit type for loongarch32. This also makes bfd/targmatch.h (generated from bfd/config.bfd) consistent since the loongarch32 match is inside #ifdef BFD64. * config.bfd (loongarch32-*): Set want64.
2021-12-15loongarch64 build failure on 32-bit hostAlan Modra1-6/+6
gas/config/tc-loongarch.c: In function ‘loongarch_args_parser_can_match_arg_helper’: gas/config/tc-loongarch.c:661:13: error: cast from pointer to integer of different size [-Werror=pointer -to-int-cast] 661 | imm = (offsetT) str_hash_find (r_htab, arg); | ^ Cast it to the correct size int, relying on normal integer promotions if offsetT is larger than a pointer. * config/tc-loongarch.c (loongarch_args_parser_can_match_arg_helper): Cast return from str_hash_find to intptr_t, not offsetT.
2021-12-15XCOFF C_STSYM test failure on 32-bit hostAlan Modra2-7/+8
This test was failing here and on another similar symbol: [ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x05d1745d11745d21 .bs where correct output is [ 4](sec 1)(fl 0x00)(ty 0)(scl 143) (nx 0) 0x000000000000000a .bs The problem is caused by a 32-bit host pointer being sign-extended when stored into a 64-bit bfd_vma, and then that value not being trimmed back to 32 bits when used. The following belt-and-braces patch fixes both the store and subsequent reads. * coffcode.h (coff_slurp_symbol_table): Do not sign extend when storing a host pointer to syment.n_value. * coffgen.c (coff_get_symbol_info): Cast syment.n_value to a bfd_hostptr_t before using in arithmetic. (coff_print_symbol): Likewise.
2021-12-14gdbserver/tracepoint.cc: use snprintf in gdb_agent_socket_initSimon Marchi1-2/+2
If we modify tracepoint.cc to try to use a too long unix socket name, for example by modifying SOCK_DIR to be: #define SOCK_DIR "/tmp/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut/salut" ... trying to start an application with libinproctrace.so loaded crashes: $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/common-utils.cc:69: A problem internal to GDBserver in-process agent has been detected. xsnprintf: Assertion `ret < size' failed. Looking at the rest of the socket initialization code, the intent seems to be that if something goes wrong, we warn but let the program execute. So crashing on this failed assertions seems against the intent. Commit 6cebaf6e1ae4 ("use xsnprintf instead of snprintf.") changed this code to use xsnprintf instead of snprintf, introducing this assertion. Before that, snprintf would return a value bigger that UNIX_PATH_MAX and the "if" after would catch it and emit a warning, which is exactly what we want. That change was done because LynxOS didn't have snprintf. Since LynxOS isn't supported anymore, we can simply revert to use snprintf there. With this patch, we get a warning (printed by the caller of gdb_agent_socket_init), but the program keeps executing: $ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6:./libinproctrace.so /bin/ls ipa: could not create sync socket ... Change-Id: I78bca52d5dc3145335abeae45a42052701e3f5dd
2021-12-14gdbserver/tracepoint.cc: work around -Wstringop-truncation errorSimon Marchi1-2/+7
When building gdb with on AArch64 with g++ 11.1.0 (and some preceding versions too), -O2 and -fsanitize=address, I get this error. CXX tracepoint-ipa.o cc1plus: warning: command-line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ In file included from /usr/include/string.h:519, from ../gnulib/import/string.h:41, from /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/common-defs.h:95, from /home/simark/src/binutils-gdb/gdbserver/server.h:22, from /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:19: In function ‘char* strncpy(char*, const char*, size_t)’, inlined from ‘int init_named_socket(const char*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6902:11, inlined from ‘int gdb_agent_socket_init()’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:6953:26, inlined from ‘void* gdb_agent_helper_thread(void*)’ at /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc:7204:41: /usr/include/bits/string_fortified.h:95:34: error: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ output may be truncated copying 107 bytes from a string of length 107 [-Werror=stringop-truncation] 95 | return __builtin___strncpy_chk (__dest, __src, __len, | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ 96 | __glibc_objsize (__dest)); | ~~~~~~~~~~~~~~~~~~~~~~~~~ Note that _FORTIFY_SOURCE changes the message a bit, but I get a similar error if I use -D_FORTIFY_SOURCE=0. I am pretty sure it's spurious and might be related to this GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780 From what I can see, we are copying from a static 108 bytes long buffer (the global array agent_socket_name) to a 108 bytes long array, sockaddr_un::sun_path. I don't see anything wrong. Still, it would make things easier if we didn't see this error. Change the code to check that the source string length is smaller than the destination buffer (including space for the NULL byte) and use strcpy. For anybody who would like to try to reproduce, the full command line is: g++ -I. -I/home/simark/src/binutils-gdb/gdbserver -I/home/simark/src/binutils-gdb/gdbserver/../gdb/regformats -I/home/simark/src/binutils-gdb/gdbserver/.. -I/home/simark/src/binutils-gdb/gdbserver/../include -I/home/simark/src/binutils-gdb/gdbserver/../gdb -I/home/simark/src/binutils-gdb/gdbserver/../gnulib/import -I../gnulib/import -I/home/simark/src/binutils-gdb/gdbserver/.. -I.. -pthread -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wmissing-prototypes -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -DGDBSERVER -DCONFIG_UST_GDB_INTEGRATION -Drpl_strerror_r=strerror_r -Drpl_free=free -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -g3 -O2 -fsanitize=address -c -o tracepoint-ipa.o -MT tracepoint-ipa.o -MMD -MP -MF ./.deps/tracepoint-ipa.Tpo /home/simark/src/binutils-gdb/gdbserver/tracepoint.cc Change-Id: I18e86c0487feead7e7677e69398405e7057cf464
2021-12-14bfd: fix -Wunused errors with clang 13+Simon Marchi12-87/+9
Clang 13 and 14 produce some -Wunused-but-set-{variable,parameter} for situations where gcc doesn't. In particular, when a variable is set and then used in a way to update its own value. For example, if `i` is only used in this way: int i = 2; i++; i = i + 1; gcc won't warn, but clang will. Fix all such errors found in an --enable-targets=all build. It would be important for somebody who knows what they're doing to just make sure that these variables can indeed be deleted, and that there a no cases where it's a bug, and the variable should actually be used. The first instance of this error fix by this patch is: CC elf32-score.lo /home/simark/src/binutils-gdb/bfd/elf32-score.c:450:11: error: variable 'relocation' set but not used [-Werror,-Wunused-but-set-variable] bfd_vma relocation; ^ Change-Id: I2f233ce20352645cf388aff3dfa08a651d21a6b6
2021-12-14gdb/mi: rename build_table to add_builtin_mi_commandsAndrew Burgess1-2/+2
Just give the function build_table a more descriptive name. There should be no user visible changes after this commit.
2021-12-14gdb/mi: rename mi_cmd to mi_commandJan Vrany4-23/+23
Just give this class a new name, more inline with the name of the sub-classes. I've also updated mi_cmd_up to mi_command_up in mi-cmds.c inline with this new naming scheme. There should be no user visible changes after this commit.
2021-12-14gdb/mi: use separate classes for different types of MI commandJan Vrany6-99/+181
This commit changes the infrastructure in mi-cmds.{c,h} to add new sub-classes for the different types of MI command. Instances of these sub-classes are then created and added into mi_cmd_table. The existing mi_cmd class becomes the abstract base class, this has an invoke method and takes care of the suppress notifications handling, before calling a do_invoke virtual method which is implemented by all of the sub-classes. There's currently two different sub-classes, one of pure MI commands, and a second for MI commands that delegate to CLI commands. There should be no user visible changes after this commit.
2021-12-14gdb/mi: int to bool conversion in mi_execute_cli_commandAndrew Burgess1-9/+13
Change an argument of mi_execute_cli_command from int to bool. Update the callers to take this into account. Within mi_execute_cli_command, update a comparison of a pointer to 0 with a comparison to nullptr, and add an assert, if we are not using the argument string then the string should be nullptr. Also removed a cryptic 'gdb_????' comment, which isn't really helpful. There should be no user visible changes after this commit.
2021-12-14gdb/mi: use std::map for MI commands in mi-cmds.cJan Vrany1-248/+230
This changes the hashmap used in mi-cmds.c from a custom structure to std::map. Not only is replacing a custom container with a standard one an improvement, but using std::map will make it easier to dynamically add commands; which is something that is planned for a later series, where we will allow MI commands to be implemented in Python. There should be no user visible changes after this commit.
2021-12-14gdb/mi: rename mi_lookup to mi_cmd_lookupJan Vrany4-6/+8
Lets give this function a more descriptive name. I've also improved the comments in the header and source files. There should be no user visible changes after this commit.
2021-12-14RISC-V: Added ld testcases for the medlow and medany code models.Nelson Chu20-0/+280
There are two linker scripts, code-model-01.ld and code-model-02.ld, which are corresponding to the two different memory layouts, * code-model-01.ld: the text section is in the 32-bit address range, but the data section is far away from the text section, which means the data section is over the 32-bit address range. * code-model-02.ld: the text section is over the 32-bit address range, but the data section is placed nearly zero address. We use the two linker scripts, to test the current medlow and medany behaviors of GNU ld, including the weak symbol references and the relaxations behaviors. Besides, these testcases also show the limits of the current medlow and medany code models, that is - we may get the truncated to fit errors when linking with the above two linker scripts. ld/ * testsuite/ld-riscv-elf/code-model-01.ld: New testcases to test the behaviors of the current medlow and medany code models. * testsuite/ld-riscv-elf/code-model-02.ld: Likewise. * testsuite/ld-riscv-elf/code-model-medany-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-medany-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-medany-weakref-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-medany-weakref-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-medlow-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-medlow-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-medlow-weakref-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-medlow-weakref-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medany-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medany-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medany-weakref-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medany-weakref-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medlow-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medlow-02.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-01.d: Likewise. * testsuite/ld-riscv-elf/code-model-relax-medlow-weakref-02.d: Likewise. * testsuite/ld-riscv-elf/code-model.s: Likewise. * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
2021-12-14Automatic date update in version.inGDB Administrator1-1/+1
2021-12-13x86: Adjust linker tests for --disable-separate-codeH.J. Lu8-15/+15
Adjust linker tests for linker configured with --disable-separate-code: 1. Update expected outputs. 2. Pass -z max-page-size=0x1000 -z separate-code" to linker. * testsuite/ld-i386/report-reloc-1.l: Updated. * testsuite/ld-x86-64/report-reloc-1.l: Likewise. * testsuite/ld-x86-64/pe-x86-64.exp: Pass "-z max-page-size=0x1000 -z separate-code" to linker. * testsuite/ld-x86-64/pr19609-4e.d: Likewise. * testsuite/ld-x86-64/pr19609-6a.d: Likewise. * testsuite/ld-x86-64/pr19609-6b.d: Likewise. * testsuite/ld-x86-64/pr19609-7b.d: Likewise. * testsuite/ld-x86-64/pr19609-7d.d: Likewise.
2021-12-13gdb: Powerpc mark xfail in gdb.base/catch-syscall.expCarl Love1-6/+31
Powerpc is not reporting the Catchpoint 1 (returned from syscall execve), .... as expected. The issue appears to be with the kernel not returning the expected result. This patch marks the test failure as an xfail. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28623
2021-12-13gdb: improve reuse of value contents when fetching array elementsAndrew Burgess3-9/+118
While working on a Python script, which was interacting with a remote target, I noticed some weird slowness in GDB. In my program I had a structure something like this: struct foo_t { int array[5]; }; struct foo_t global_foo; Then in the Python script I was fetching a complete copy of global foo, like: val = gdb.parse_and_eval('global_foo') val.fetch_lazy() Then I would work with items in foo_t.array, like: print(val['array'][1]) I called the fetch_lazy method specifically because I knew I was going to end up accessing almost all of the contents of val, and so I wanted GDB to do a single remote protocol call to fetch all the contents in one go, rather than trying to do lazy fetches for a couple of bytes at a time. What I observed was that, after the fetch_lazy call, GDB does, correctly, fetch the entire contents of global_foo, including all of the contents of array, however, when I access val.array[1], GDB still goes and fetches the value of this element from the remote target. What's going on is that in valarith.c, in value_subscript, for C like languages, we always end up treating the array value as a pointer, and then doing value_ptradd, and value_ind, the second of these calls always returns a lazy value. My guess is that this approach allows us to handle indexing off the end of an array, when working with zero element arrays, or when indexing a raw pointer as an array. And, I agree, that in these cases, where, even when the original value is non-lazy, we still will not have the content of the array loaded, we should be using the value_ind approach. However, for cases where we do have the array contents loaded, and we do know the bounds of the array, I think we should be using value_subscripted_rvalue, which is what we use for non C like languages. One problem I did run into, exposed by gdb.base/charset.exp, was that value_subscripted_rvalue stripped typedefs from the element type of the array, which means the value returned will not have the same type as an element of the array, but would be the raw, non-typedefed, type. In charset.exp we got back an 'int' instead of a 'wchar_t' (which is a typedef of 'int'), and this impacts how we print the value. Removing typedefs from the resulting value just seems wrong, so I got rid of that, and I don't see any test regressions. With this change in place, my original Python script is now doing no additional memory accesses, and its performance increases about 10x!
2021-12-13gdb: update gdb-gdb.py.in for latest changes to struct fieldAndrew Burgess3-20/+191
This commit updates uses of 'loc' and 'loc_kind' to 'm_loc' and 'm_loc_kind' respectively, in gdb-gdb.py.in, which is required after this commit: commit cd3f655cc7a55437a05aa8e7b1fcc9051b5fe404 Date: Thu Sep 30 22:38:29 2021 -0400 gdb: add accessors for field (and call site) location I have also incorporated this change: https://sourceware.org/pipermail/gdb-patches/2021-September/182171.html Which means we print 'm_name' instead of 'name' when displaying the 'm_name' member variable. Finally, I have also added support for the new TYPE_SPECIFIC_INT fields, which were added with this commit: commit 20a5fcbd5b28cca88511ac5a9ad5e54251e8fa6d Date: Wed Sep 23 09:39:24 2020 -0600 Handle bit offset and bit size in base types I updated the gdb.gdb/python-helper.exp test to cover all of these changes.
2021-12-13gdbserver/linux-low: replace direct assignment to current_threadTankut Baris Aktemur1-2/+5
Use scoped_restore_current_thread and switch_to_thread in linux_process_target::wait_for_sigstop.
2021-12-13gdbserver: replace direct assignments to current_threadTankut Baris Aktemur13-136/+77
Replace the direct assignments to current_thread with switch_to_thread. Use scoped_restore_current_thread when appropriate. There is one instance remaining in linux-low.cc's wait_for_sigstop. This will be handled in a separate patch. Regression-tested on X86-64 Linux using the native-gdbserver and native-extended-gdbserver board files.
2021-12-13gdbserver: introduce scoped_restore_current_thread and switch_to_threadTankut Baris Aktemur2-0/+43
Introduce a class for restoring the current thread and a function to switch to the given thread. This is a preparation for a refactoring that aims to remove direct assignments to 'current_thread'.
2021-12-13gdb: make post_startup_inferior a virtual method on inf_ptrace_targetAndrew Burgess19-67/+44
While working on a later patch that required me to understand how GDB starts up inferiors, I was confused by the target_ops::post_startup_inferior method. The post_startup_inferior target function is only called from inf_ptrace_target::create_inferior. Part of the target class hierarchy looks like this: inf_child_target | '-- inf_ptrace_target | |-- linux_nat_target | |-- fbsd_nat_target | |-- nbsd_nat_target | |-- obsd_nat_target | '-- rs6000_nat_target Every sub-class of inf_ptrace_target, except rs6000_nat_target, implements ::post_startup_inferior. The rs6000_nat_target picks up the implementation of ::post_startup_inferior not from inf_ptrace_target, but from inf_child_target. No descendent of inf_child_target, outside the inf_ptrace_target sub-tree, implements ::post_startup_inferior, which isn't really surprising, as they would never see the method called (remember, the method is only called from inf_ptrace_target::create_inferior). What I find confusing is the role inf_child_target plays in implementing, what is really a helper function for just one of its descendents. In this commit I propose that we formally make ::post_startup_inferior a helper function of inf_ptrace_target. To do this I will remove the ::post_startup_inferior from the target_ops API, and instead make this a protected, pure virtual function on inf_ptrace_target. I'll remove the empty implementation of ::post_startup_inferior from the inf_child_target class, and add a new empty implementation to the rs6000_nat_target class. All the other descendents of inf_ptrace_target already provide an implementation of this method and so don't need to change beyond making the method protected within their class declarations. To me, this makes much more sense now. The helper function, which is only called from within the inf_ptrace_target class, is now a part of the inf_ptrace_target class. The only way in which this change is visible to a user is if the user turns on 'set debug target 1'. With this debug flag on, prior to this patch the user would see something like: -> native->post_startup_inferior (...) <- native->post_startup_inferior (2588939) After this patch these lines are no longer present, as the post_startup_inferior is no longer a top level target method. For me, this is an acceptable change.
2021-12-13gdb: have mips_nbsd_nat_target inherit from nbsd_nat_targetAndrew Burgess1-1/+2
While working on another patch I had reason to look at mips-netbsd-nat.c, and noticed that the class mips_nbsd_nat_target inherits directly from inf_ptrace_target. This is a little strange as alpha_bsd_nat_target, arm_netbsd_nat_target, hppa_nbsd_nat_target, m68k_bsd_nat_target, ppc_nbsd_nat_target, sh_nbsd_nat_target, and vax_bsd_nat_target all inherit from nbsd_nat_target. Originally, in this commit: commit f6ac5f3d63e03a81c4ff3749aba234961cc9090e Date: Thu May 3 00:37:22 2018 +0100 Convert struct target_ops to C++ When the target tree was converted to C++, all of the above classes inherited from inf_ptrace_target except for hppa_nbsd_nat_target, which was the only class that originally inherited from nbsd_nat_target. Later on all the remaining targets (except mips) were converted to inherit from nbsd_nat_target, these are the commits: commit 4fed520be264b60893aa674071947890f8172915 Date: Sat Mar 14 16:05:24 2020 +0100 Inherit alpha_netbsd_nat_target from nbsd_nat_target commit 6018d381a00515933016c539d2fdc18ad0d304b8 Date: Sat Mar 14 14:50:51 2020 +0100 Inherit arm_netbsd_nat_target from nbsd_nat_target commit 01a801176ea15ddfc988cade2e3d84c3b0abfec3 Date: Sat Mar 14 16:54:42 2020 +0100 Inherit m68k_bsd_nat_target from nbsd_nat_target commit 9faa006d11a5e08264a007463435f84b77864c9c Date: Thu Mar 19 14:52:57 2020 +0100 Inherit ppc_nbsd_nat_target from nbsd_nat_target commit 9809762324491b851332ce600ae9bde8dd34f601 Date: Tue Mar 17 15:07:39 2020 +0100 Inherit sh_nbsd_nat_target from nbsd_nat_target commit d5be5fa4207da00d039a1d5a040ba316e7092cbd Date: Sat Mar 14 13:21:58 2020 +0100 Inherit vax_bsd_nat_target from nbsd_nat_target I could only find mailing list threads for ppc and sh in the archive , and unfortunately, none of the commits has any real detail that might explain why mips was missed out, the only extra context I could find was this message: https://sourceware.org/pipermail/gdb-patches/2020-March/166853.html Which says that "proper" OS support is going to be added to nbsd_nat_target, hence the need to inherit from that class. My guess is that leaving mips_nbsd_nat_target unchanged was an oversight, so, in this commit, I propose changing mips_nbsd_nat_target to inherit from nbsd_nat_target just like all the other nbsd targets. My motivation for this patch relates to the post_startup_inferior target method. In a future commit I want to change how this method is handled. Currently the mips_nbsd_nat_target will pick up the empty implementation of inf_child_target::post_startup_inferior rather than the version in netbsd-nat.c. This feels like a bug to me, as surely, enabling of proc events is something that would need to be done for all netbsd targets, regardless of architecture. In my future patch I have a choice then, either (a) add a new, empty implementation of post_startup_inferior to mips_nbsd_nat_target, or (b) this commit, have mips_nbsd_nat_target inherit from nbsd_nat_target. Option (b) seems like the right way to go, hence, this commit. I've done absolutely no testing for this change, not even building it, as that would require at least an environment in which I can x-build mips-netbsd applications, which I have no idea how to set up.
2021-12-13gdb: only include mips and riscv targets if building with 64-bit bfdAndrew Burgess1-11/+11
While testing another patch I was trying to build different configurations of GDB, and, during one test build I ran into a problem, I configured with `--enable-targets=all --host=i686-w64-mingw32` and saw this error while linking GDB: .../i686-w64-mingw32/bin/ld: mips-tdep.o: in function `mips_gdbarch_init': .../src/gdb/mips-tdep.c:8730: undefined reference to `disassembler_options_mips' .../i686-w64-mingw32/bin/ld: riscv-tdep.o: in function `riscv_gdbarch_init': .../src/gdb/riscv-tdep.c:3851: undefined reference to `disassembler_options_riscv' So the `disassembler_options_mips` and `disassembler_options_riscv` symbols are missing. This turns out to be because mips-dis.c and riscv-dis.c, in which these symbols are defined, are in the TARGET64_LIBOPCODES_CFILES list in opcodes/Makefile.am, these files are only built when we are building with a 64-bit bfd. If we look further, into bfd/Makefile.am, we can see that all the files matching elf*-riscv.lo are in the BFD64_BACKENDS list, as are the elf*-mips.lo files, and (I know because I tried), the two disassemblers do, not surprisingly, depend on features supplied from libbfd. So, though we can build most of GDB just fine for riscv and mips with a 32-bit bfd, if I understand correctly, the final GDB executable (assuming we could get it to link) would not understand these architectures at the bfd level, nor would there be any disassembler available. This sounds like a pretty useless GDB to me. So, in this commit, I move the riscv and mips targets into GDB's list of targets that require a 64-bit bfd. After this I can build GDB just fine with the configure options given above. This was discussed on the mailing list in a couple of threads: https://sourceware.org/pipermail/gdb-patches/2021-December/184365.html https://sourceware.org/pipermail/binutils/2021-November/118498.html and it is agreed, that it is unfortunate that the 32-bit riscv and 32-bit mips targets require a 64-bit bfd. If in the future this situation ever changes then it would be expected that some (or all) of this patch would be reverted. Until then though, this patch allows GDB to build when configured with --enable-targets=all, and when using a 32-bit libbfd.
2021-12-13Automatic date update in version.inGDB Administrator1-1/+1
2021-12-12C++-ify path substitution codeTom Tromey2-121/+54
I found some uses of xfree in the path substitution code in source.c. C++-ifying struct substitute_path_rule both simplifies the code and removes manual memory management. Regression tested on x86-64 Fedora 34.
2021-12-12Automatic date update in version.inGDB Administrator1-1/+1
2021-12-11[GOLD] PowerPC64 @notoc in non-power10 codeAlan Modra2-76/+223
Gold version of commit 7aba54da42. elfcpp/ * powerpc.h (R_PPC64_REL24_P9NOTOC): Define. gold/ * powerpc.cc (Target_powerpc::maybe_skip_tls_get_addr_call, is_branch_reloc, max_branch_delta): Handle R_PPC64_REL24_P9NOTOC. (Target_powerpc::Branch_info::make_stub): Likewise. (struct Plt_stub_ent): Add p9notoc_, p9off_, tsize_. (struct Branch_stub_ent): Add p9notoc_, p9off_. (Stub_table::add_plt_call_entry): Handle R_PPC64_REL24_P9NOTOC. (Stub_table::add_long_branch_entry): Likewise. (Stub_table::add_eh_frame): Likewise. (Stub_table::plt_call_size): Return aligned size. Adjust callers. Handle p9notoc_ sizing. (Stub_table::do_write): Write out p9notoc_ stubs. (Target_powerpc::Scan::get_reference_flags, local, global): Handle R_PPC64_REL24_P9NOTOC. (Target_powerpc::Relocate::relocate): Likewise.
2021-12-10Don't return the main file as the separate debug infoH.J. Lu1-1/+17
On Fedora 35, $ readelf -d /usr/bin/npc caused readelf to run out of stack since load_separate_debug_info returned the input main file as the separate debug info: (gdb) bt #0 load_separate_debug_info ( main_filename=main_filename@entry=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo", xlink=xlink@entry=0x4e5180 <debug_displays+4480>, parse_func=parse_func@entry=0x431550 <parse_gnu_debuglink>, check_func=check_func@entry=0x432ae0 <check_gnu_debuglink>, func_data=func_data@entry=0x7fffffffdb60, file=file@entry=0x51d430) at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11057 #1 0x000000000043328d in check_for_and_load_links (file=0x51d430, filename=0x510f50 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") at /export/gnu/import/git/sources/binutils-gdb/binutils/dwarf.c:11381 #2 0x00000000004332ae in check_for_and_load_links (file=0x51b070, filename=0x518dd0 "/export/home/hjl/.cache/debuginfod_client/dcc33c51c49e7dafc178fdb5cf8bd8946f965295/debuginfo") Return NULL if the separate debug info is the same as the input main file to avoid infinite recursion. PR binutils/28679 * dwarf.c (load_separate_debug_info): Don't return the input main file.
2021-12-11Don't edit bogus sh_link on reading relocatable objects (Oracle fix)Alan Modra1-34/+0
This reverts a 1995 fix to handle bogus object files. Presumably such object files have long gone. * elf.c (bfd_section_from_shdr): Remove old hack for Oracle libraries.
2021-12-11Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2025-09-23 17:43:41 +0000