summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* sim/testsuite/cris/c/stat3.c: Fix formatting nitHans-Peter Nilsson2022-02-161-1/+1
| | | | * c/stat3.c (main): Fix formatting nit.
* sim: testsuite: cleanup the istarget * logicMike Frysinger2022-02-1646-467/+332
| | | | | Now that the multitarget testing has settled, clean up the cases where istarget * is used. This ends up being mostly style unindenting.
* Automatic date update in version.inGDB Administrator2022-02-161-1/+1
|
* i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTRELH.J. Lu2022-02-154-0/+12
| | | | | | | | | | | | | | | | | Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation in read-only section. bfd/ PR ld/28894 * elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow R_386_TLS_IE. ld/ PR ld/28894 * testsuite/ld-i386/i386.exp: Run pr28894. * testsuite/ld-i386/pr28894.d: New file. * testsuite/ld-i386/pr28894.s: Likewise.
* sim/testsuite: Default global_cc_os and global_cc_works properlyHans-Peter Nilsson2022-02-151-4/+2
| | | | | | | | | | | | | | | | | | There was an omission on 3e6dc39ed7a8 "sim/testsuite: Set global_cc_os also when no compiler is found"; global_cc_os wasn't set for other than the primary target, which means that the "unguarded" use of global_cc_os in testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read "global_cc_os": no such variable" when e.g. configuring for pru-elf and doing "make check-sim". Better initializing both variables at the top to default values, rather than adding another single 'set global_cc_os ""', to reduce the risk of not setting them properly if or when that if-statement-chain is made longer. sim/testsuite: * lib/sim-defs.exp (sim_init_toolchain): Default global_cc_os and global_cc_works properly, before if-chain.
* x86: Add has_sib to struct instr_infoH.J. Lu2022-02-151-8/+9
| | | | | | | | | | | Add has_sib to struct instr_info and use SIB info only if ins->has_sib is true. PR binutils/28892 * i386-dis.c (instr_info): Add has_sib. (get_sib): Set has_sib. (OP_E_memory): Replace havesib with ins->has_sib. (OP_VEX): Use ins->sib.index only if ins->has_sib is true.
* gdb: Respect the DW_CC_nocall attributeLancelot SIX2022-02-157-3/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It is possible for a compiler to optimize a function in a such ways that the function does not follow the calling convention of the target. In such situation, the compiler can use the DW_AT_calling_convention attribute with the value DW_CC_nocall to tell the debugger that it is unsafe to call the function. The DWARF5 standard states, in 3.3.1.1: > If the value of the calling convention attribute is the constant > DW_CC_nocall, the subroutine does not obey standard calling > conventions, and it may not be safe for the debugger to call this > subroutine. Non standard calling convention can affect GDB's assumptions in multiple ways, including how arguments are passed to the function, how values are returned, and so on. For this reason, it is unsafe for GDB to try to do the following operations on a function with marked with DW_CC_nocall: - call / print an expression requiring the function to be evaluated, - inspect the value a function returns using the 'finish' command, - force the value returned by a function using the 'return' command. This patch ensures that if a command which relies on GDB's knowledge of the target's calling convention is used on a function marked nocall, GDB prints an appropriate message to the user and does not proceed with the operation which is unreliable. Note that it is still possible for someone to use a vendor specific value for the DW_AT_calling_convention attribute for example to indicate the use of an alternative calling convention. This commit does not prevent this, and target dependent code can be adjusted if one wanted to support multiple calling conventions. Tested on x86_64-Linux, with no regression observed. Change-Id: I72970dae68234cb83edbc0cf71aa3d6002a4a540
* gdb: add a symbol* argument to get_return_valueLancelot SIX2022-02-153-34/+44
| | | | | | | | | | | | | | | | Add an argument to the get_return_value function to indicate the symbol of the function the debuggee is returning from. This will be used by the following patch. Since the function return type can be deduced from the symbol remove the value_type argument which becomes redundant. No user visible change after this patch. Tested on x86_64-linux. Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
* x86-64: Use MAXPAGESIZE for the relro segment alignmentH.J. Lu2022-02-1415-59/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjust x86-64 linker tests after reverting commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be Author: Alan Modra <amodra@gmail.com> Date: Thu Feb 3 08:57:47 2022 +1030 PR28824, relro security issues, x86 keep COMMONPAGESIZE relro to use MAXPAGESIZE for the end of the relro segment alignment, like other ELF targets. * testsuite/ld-x86-64/plt-main-bnd.dd: Updated. * testsuite/ld-x86-64/plt-main-ibt-x32.dd: Likewise. * testsuite/ld-x86-64/plt-main-ibt.dd: Likewise. * testsuite/ld-x86-64/pr14207.d: Likewise. * testsuite/ld-x86-64/pr18176.d: Likewise. * testsuite/ld-x86-64/pr20830a-now.d: Likewise. * testsuite/ld-x86-64/pr20830a.d: Likewise. * testsuite/ld-x86-64/pr20830b-now.d: Likewise. * testsuite/ld-x86-64/pr20830b.d: Likewise. * testsuite/ld-x86-64/pr21038a-now.d: Likewise. * testsuite/ld-x86-64/pr21038a.d: Likewise. * testsuite/ld-x86-64/pr21038b-now.d: Likewise. * testsuite/ld-x86-64/pr21038b.d: Likewise. * testsuite/ld-x86-64/pr21038c-now.d: Likewise. * testsuite/ld-x86-64/pr21038c.d: Likewise.
* Revert "PR28824, relro security issues, x86 keep COMMONPAGESIZE relro"H.J. Lu2022-02-144-10/+1
| | | | This reverts commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be.
* Automatic date update in version.inGDB Administrator2022-02-151-1/+1
|
* sim/testsuite/cris: If failing compilation, mark C tests as errorsHans-Peter Nilsson2022-02-141-1/+1
| | | | | | | | | ...when we know we have a working compiler. This will reduce the risk of faulty edits by exposing them rather than hiding them as "unresolved". It also harmonizes behavior with that of run_sim_test. * c/c.exp: Mark C tests failing compilation test errors.
* sim/testsuite/cris: Remove faulty use of basename in C testsHans-Peter Nilsson2022-02-142-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calls to basename were added here as part of commit e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that commit missed adding "#include <libgen.h>" or the equivalent GNU extension, see basename(3). Fixing that shows a logical error in the change to openpf1.c; the non-/-prefixed code-path was changed instead of the "/"-prefixed code-path, which is the one executed after that commit. For "newlib" these tests failed linking after that commit. Recent newlib has the (asm-renamed) GNU-extension-variant of basename, but we're better off not using it at all. Unfortunately, compilation failures for C tests run by the machinery in c.exp are currently just marked "unresolved", in contrast to C and assembler tests run by calling run_sim_test. The interaction of calling with the full program-path vs. use of --sysroot exposes a consistency problem: when --sysroot is used, argv[0] isn't the path by which the program can find itself. It's undecided whether argv[0] for the program running in the simulator should be edited (related to the naked argument to the simulator before passing on to the simulated program) to remove a leading --sysroot. Either way, such a change would be out of scope for this commit. * c/stat3.c (mybasename): New macro. Use it instead of basename. * c/openpf1.c: Correct basename-related change and update related comment.
* sim: Add sim_dump_memory for debuggingHans-Peter Nilsson2022-02-141-0/+10
| | | | | | | Intended to be called from the debugger tool. sim/common: * sim-memopt.c (sim_dump_memory): New function.
* sim: Fix use of out-of-tree assembler and linker when testingHans-Peter Nilsson2022-02-143-106/+278
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With commit 7a259895bb2d "sim: testsuite: expand arch specific toolchain settings", trying to use out-of-tree ld and as at test-time broke for the "primary target", like when testing a release-tarball. Subsequent to that commit, all assembler tests without in-tree-built tools FAIL, getting errors when trying to call $(abs_builddir)/../gas/as-new. But, that isn't the actual culprint; it's actually it's its immediate predecessor, commit 8996c21067373 "sim: testsuite: setup per-port toolchain settings for multitarget build", which hardcodes in-tree-paths to those tools instead of considering e.g. $(<X>_FOR_TARGET), the preferred overridable variable for single-target builds, as set up by the toplevel Makefile. This commit calls GCC_TARGET_TOOL (a deceptive name; gcc-specific features aren't used) from toplev/config/acx.m4, somewhat like calls in toplev/configure.ac but without the NCN_STRICT_CHECK_TARGET_TOOLS step, for each X to find a value for $(<X>_FOR_TARGET). N.B.: in-tree tools still override any ${target}-${tool} found in $PATH, i.e. only previously broken builds are affected. The variables $(<X>_FOR_TARGET) are usually overridden by the toplevel Makefile to the same value or better, but has to be set here too, as automake "wants" Makefiles to be self-contained (you get an error pointing out that the variable may be empty). If it hadn't been for that, SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET would not be needed. This detail should only (positively) affect users invoking "make check" in sim/ instead of "make check-sim" (or "make check") at the toplevel. Now the output from "configure" matches the target tools actually used by sim at test-time, for the "primary target". Using $(CC) for "example-" targets CC_FOR_TARGET is not changed, as that appears to be a deliberate special-case. Note that all tools still have to be installed and present in $PATH at configure-time to be properly used at test-time. sim: * m4/sim_ac_toolchain.m4 (SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET): New defun. (SIM_TOOLCHAIN_VARS): Call it using AC_REQUIRE, and use variables AS_FOR_TARGET, LD_FOR_TARGET and CC_FOR_TARGET instead of hard-coded values. * Makefile.in, configure: Regenerate.
* sim cris: Unbreak --disable-sim-hardware buildsHans-Peter Nilsson2022-02-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | With --disable-sim-hardware (--enable-sim-hardware=no), whose default was changed to --enable-sim-hardware(=yes) in commit 34cf51120683, building for cris-elf fails as sim_hw_parse then doesn't exist. A cris-elf simulator configured for --enable-sim-hardware (or the default after to the mentioned commit) runs about 2.5x slower than one configured --disable-sim-hardware. A further 2-5% performance regression was not investigated. When sim_hw_parse doesn't exist, --cris-900000xx can't be supported. The best action here is to remove it completely, so its absence can be identified through --help, but avoiding littering the code with "#if WITH_HW". sim/cris: * sim-if.c (cris_options) [WITH_HW]: Conditionalize support of option --cris-900000xx. (sim_open) [WITH_HW]: Conditionalize sim_hw_parse call.
* sim/testsuite/cris: As applicable, require simoption --cris-900000xxHans-Peter Nilsson2022-02-145-0/+5
| | | | | | | | | | | | Apply the new run_sim_test option "require" as in "#require simoption --cris-900000xx" for all tests using that option. This allows a clean test-suite-run for a build with --disable-sim-hardware, where that option is not supported, by skipping those tests as "untested". sim/testsuite/cris: * asm/io1.ms, asm/io2.ms, asm/io3.ms, asm/io6.ms, asm/io7.ms: Call "#require: simoption --cris-900000xx".
* sim/testsuite: Support "requires: simoption <--name-of-option>"Hans-Peter Nilsson2022-02-141-0/+60
| | | | | | | | | | | | | | | | | | | | | | | | | Simulator features can be present or not, typically depending on different-valued configure options, like --enable-sim-hardware[=off|=on]. To avoid failures in test-suite-runs when testing such configurations, a new predicate is needed, as neither "target", "progos" nor "mach" fits cleanly. The immediate need was to check for presence of a simulator option, but rather than a specialized "requires-simoption:" predicate I thought I'd handle the general (parametrized) need, so here's a generic predicate machinery and a (first) predicate to use together with it; checking whether a particular option is supported, by looking at "run --help" output. This was inspired by the check_effective_target_ machinery in the gcc test-suite. Multiple "requires: <requirement> <parameter>" form a list of predicates (with parameters), to be used as a conjunction. sim/testsuite: * lib/sim-defs.exp (sim_check_requires_simoption): New function. (run_sim_test): Support "requires: <requirement> <parameter>".
* sim/testsuite/cris/hw/rv-n-cris/irq1.ms: Disable due to randomnessHans-Peter Nilsson2022-02-141-0/+1
| | | | | | | | | | | | | | For reasons that remain largely to be investigated (besides the apparent lack of synchronization between two processes), this test fails randomly, with two different sets of common outputs. Curiously, that doesn't happen for the other similar tests. There's a comment that mentions this, though that doesn't make it a sustainable part of a test-suite. (Known-blinking tests should be disabled until fixed.) sim/testsuite/cris: * hw/rv-n-cris/irq1.ms: Disable by use of a never-matched "progos" value.
* sim/testsuite/cris/c: Use -sim3 but only for newlib targetsHans-Peter Nilsson2022-02-141-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a39487c6685f "sim: cris: use -sim with C tests for cris-elf targets" caused " -sim" to be appended to CFLAGS_FOR_TARGET for cris*-*-elf, where testing had until then relied on "RUNTESTFLAGS=--target_board=cris-sim" being passed when running "make check-sim", adding the right options. While "-sim" happens to work, the baseboard-file cris-sim.exp uses "-sim3" so for consistency use that instead. Then commit b42f20d2ac72 "sim: testsuite: drop most specific istarget checks" caused " -sim" to be appended for *all* targets, which just doesn't work. For example, for crisv32-linux-gnu, that's not a recognized option and will cause a dejagnu error and further testing in c.exp will be aborted. While cris-sim.exp appends "-static" for *-linux-gnu, further changes in the test-suite have caused "linux"-specific tests to break, so that part will be tended to separately. But, save and restore CFLAGS_FOR_TARGET around the modification and use where needed, to not have the CRIS-specific modification affect a continuing test-run (possibly for other targets). sim/testsuite/cris: * c/c.exp (CFLAGS_FOR_TARGET): Replace appended option " -sim" with " -sim3", but do it conditionally for newlib targets. Save and restore CFLAGS_FOR_TARGET in saved_CFLAGS_FOR_TARGET such that it doesn't affect the value of CFLAGS_FOR_TARGET outside c.exp.
* sim/testsuite: Set global_cc_os also when no compiler is foundHans-Peter Nilsson2022-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we don't set this variable, it doesn't exist, and using "#progos:" in an assembler-file will cause an error rather than just skipping the test, viz: Running /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp ... ERROR: tcl error sourcing /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp. ERROR: can't read "global_cc_os": no such variable while executing "if { $opts(progos) != "" && $opts(progos) != $global_cc_os } { untested $subdir/$name return }" (procedure "run_sim_test" line 102) Neither the commit introducing progos, nor the top comment in run_sim_test, mentions progos as intended only for C tests, or that its use must be gated on $global_cc_works != 0, so (not) setting it in the no-working-compiler path seems just overlooked. Allowing it to be used for assembler tests makes it usable for e.g. an always-false predicate and in expressions in .exp files without gating on $global_cc_works != 0. With this patch, global_cc_os is set to "", just as for "unknown OS". sim/testsuite: * lib/sim-defs.exp (sim_init_toolchain): Set global_cc_os also when no working target C compiler is found.
* sim/testsuite/cris: Assembler testcase for PRIx32 usage bugHans-Peter Nilsson2022-02-141-0/+47
| | | | | | | Several C test-cases exposed the bug, but let's have one for people who test using just the assembler and linker. * asm/endmem1.ms: New test.
* sim cris: Correct PRIu32 to PRIx32Hans-Peter Nilsson2022-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 5ee0bc23a68f "sim: clean up bfd_vma printing" there was an additional introduction of PRIx32 and PRIu32 but just in sim/cris/sim-if.c. One type of bug was fixed in commit d16ce6e4d581 "sim: cris: fix memory setup typos" but one remained; the PRIu32 usage is wrong, as hex output is desired; note the 0x prefix. Without this fix, you'll see output like: memory map 0:0x4000..0x5fff (8192 bytes) overlaps 0:0x0..0x16383 (91012 bytes) program stopped with signal 6 (Aborted). for some C programs, like some of the ones in the sim/cris/c testsuite from where the example is taken (freopen2.c). The bug behavior was with memory allocation. With an attempt to allocate memory using the brk syscall such that the room up to the next 8192-byte "page boundary" wasn't sufficient, the simulator memory allocation machinery horked on a consistency error when trying to allocate a memory block to raise the "end of the data segment": there was already memory allocated at that address. Unfortunately, none of the programs in sim/cris/asm exposed this bug at the time, but an assembler test-case is committed after this fix. sim/cris: * sim-if.c (sim_open): Correct PRIu32 to PRIx32.
* microblaze: fix fsqrt collicion to build on glibc-2.35Sergei Trofimovich2022-02-143-2/+8
| | | | | * microblaze-opcm.h: Renamed 'fsqrt' to 'microblaze_fsqrt'. * microblaze-opc.h: Follow 'fsqrt' rename.
* Remove LA_PRINT_STRINGTom Tromey2022-02-144-18/+8
| | | | | | | | This removes the LA_PRINT_STRING macro, in favor of using ordinary method calls.
* Remove LA_PRINT_CHARTom Tromey2022-02-145-6/+5
| | | | | | | | This removes the LA_PRINT_CHAR macro, in favor of using ordinary method calls.
* Remove LA_PRINT_TYPETom Tromey2022-02-145-17/+17
| | | | | | | | This removes the LA_PRINT_TYPE macro, in favor of using ordinary method calls.
* gdb/python: move styling support to gdb.stylingAndrew Burgess2022-02-144-39/+69
| | | | | | | | | | | | | | | | | | | | | | | This commit moves the two Python functions that are used for styling into a new module, gdb.styling, there's then a small update in python.c so GDB can find the functions in their new location. The motivation for this change is purely to try and reduce the clutter in the top-level gdb module, and encapsulate related functions into modules. I did ponder documenting these functions as part of the Python API, however, doing so would effectively "fix" the API, and I'm still wondering if there's improvements that could be made, also, the colorize function is only called in some cases now that GDB prefers libsource-highlight, so it's not entirely sure how this would work as part of a user facing API. Still, despite these functions never having been part of a documented API, it is possible that a user out there has overridden these to, in some way, customize how GDB performs styling. Moving the function as I propose in this patch could break things for that user, however, fixing this breakage is trivial, and, as these functions were never documented, I don't think we should be obliged to not break user code that relies on them.
* gdb: use python to colorize disassembler outputAndrew Burgess2022-02-1413-3/+352
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds styling support to the disassembler output, as such two new commands are added to GDB: set style disassembler enabled on|off show style disassembler enabled In this commit I make use of the Python Pygments package to provide the styling. I did investigate making use of libsource-highlight, however, I found the highlighting results to be inferior to those of Pygments; only some mnemonics were highlighted, and highlighting of register names such as r9d and r8d (on x86-64) was incorrect. To enable disassembler highlighting via Pygments, I've added a new extension language hook, which is then implemented for Python. This hook is very similar to the existing hook for source code colorization. One possibly odd choice I made with the new hook is to pass a gdb.Architecture through, even though this is currently unused. The reason this argument is not used is that, currently, styling is performed identically for all architectures. However, even though the Python function used to perform styling of disassembly output is not part of any documented API, I don't want to close the door on a user overriding this function to provide architecture specific styling. To do this, the user would inevitably require access to the gdb.Architecture, and so I decided to add this field now. The styling is applied within gdb_disassembler::print_insn, to achieve this, gdb_disassembler now writes its output into a temporary buffer, styling is then applied to the contents of this buffer. Finally the gdb_disassembler buffer is copied out to its final destination stream. There's a new test to check that the disassembler output includes some escape sequences, though I don't check for specific colours; the precise colors will depend on which instructions are in the disassembler output, and, I guess, how pygments is configured. The only negative change with this commit is how we currently style addresses in GDB. Currently, when the disassembler wants to print an address, we call back into GDB, and GDB prints the address value using the `address` styling, and the symbol name using `function` styling. After this commit, if pygments is used, then all disassembler styling is done through pygments, and this include the address and symbol name parts of the disassembler output. I don't know how much of an issue this will be for people. There's already some precedent for this in GDB when we look at source styling. For example, function names in styled source listings are not styled using the `function` style, but instead, either GNU Source Highlight, or pygments gets to decide how the function name should be styled. If the Python pygments library is not present then GDB will continue to behave as it always has, the disassembler output is mostly unstyled, but the address and symbols are styled using the `address` and `function` styles, as they are today. However, if the user does `set style disassembler enabled off`, then all disassembler styling is switched off. This obviously covers the use of pygments, but also includes the minimal styling done by GDB when pygments is not available.
* ld: Keep indirect symbol from IR if referenced from shared objectH.J. Lu2022-02-134-3/+43
| | | | | | | | | | | | | | | | | | | Don't change indirect symbol defined in IR to undefined if it is referenced from shared object. bfd/ PR ld/28879 * elflink.c (_bfd_elf_merge_symbol): Don't change indirect symbol defined in IR to undefined if it is referenced from shared object. ld/ PR ld/28879 * testsuite/ld-plugin/lto.exp: Run PR ld/28879 tests. * testsuite/ld-plugin/pr28879a.cc: New file. * testsuite/ld-plugin/pr28879b.cc: Likewise.
* Automatic date update in version.inGDB Administrator2022-02-141-1/+1
|
* PR28882, build failure with gcc-4.2 due to use of 0b literalsAlan Modra2022-02-131-8/+8
| | | | | PR 28882 * elf/loongarch.h: Replace binary literals with hex.
* Don't pass around expld.dataseg pointerAlan Modra2022-02-132-20/+28
| | | | | | | | | The better to see any code that accesses expld.dataseg. * ldexp.c (fold_segment_end): Remove seg parameter. Adjust calls. (fold_segment_align, fold_segment_relro_end): Likewise. * ldlang.c (lang_size_segment): Likewise. (lang_size_relro_segment_1, lang_find_relro_sections_1): Likewise.
* Remove bfd ELF_RELROPAGESIZEAlan Modra2022-02-137-25/+5
| | | | | | | | | | | | | | | | | Now that ld properly aligns the end of the relro segment, the hack to make relro work on powerpc can disappear. bfd/ * bfd.c (bfd_emul_get_commonpagesize): Remove relro param. Don't return bed->relropagesize. * elf-bfd.h (struct elf_backend_data): Remove relropagesize. * elfxx-target.h (ELF_RELROPAGESIZE): Remove. * elf32-ppc.c (ELF_RELROPAGESIZE): Don't define. * elf64-ppc.c: Likewise. * bfd-in2.h: Regenerate. ld/ * ldemul.c (after_parse_default): Adjust bfd_emul_get_commonpagesize call.
* PR28824, relro security issues, x86 keep COMMONPAGESIZE relroAlan Modra2022-02-134-1/+10
| | | | | | | | | | | | | | | | | | | | x86 treats MAXPAGESIZE as a memory optimisation parameter, actual hardware paging is always COMMPAGESIZE of 4k. Use COMMONPAGESIZE for the end of the relro segment alignment. The previous patch regresses pr18176, increasing the testcase file size from 322208 to 2099872 bytes. Fixing this on x86 will require introducing a gap after the end of the relro segment (of up to relropagesize-1 bytes). PR 28824 PR 18176 * ld.h (ld_config_type): Add relro_use_commonpagesize field. * ldexp.c (fold_segment_align): Set relropagesize depending on relro_use_commonpagesize. * emultempl/elf-x86.em (elf_x86_create_output_section_statements): Set relro_use_commonpagesize. * testsuite/ld-x86-64/pr18176.d: xfail.
* PR28824, relro security issuesAlan Modra2022-02-133-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Background ========== There are constraints on layout of binaries to meet demand paging and memory protection requirements. Demand paged binaries must have file offset mod pagesize equal to vma mod pagesize. Memory protection (executable, read, write status) can only change at page boundaries. The linker's MAXPAGESIZE variable gives the page size for these layout constraints. In a typical basic executable with two memory segments, text (RE) and data (RW), the data segment must start on a different page to the last text segment page. For example, with 64k pages and a small executable of 48k text and 1k data, the text segment might start at address 0x10000 and data at 0x20000 for a total of two 64k memory pages. Demand paging would require the image on disk to be 64k+1k in size. We can do better than that. If the data segment instead starts at 0x2c000 (the end of the text segment plus one 64k page) then there are still only two memory pages, but the disk image is now smaller, 48k+1k in size. This is why the linker normally starts the data segment at the end of the text segment plus one page. That simple heuristic isn't ideal in all cases. Changing our simple example to one with 64k-1 text size, following that heuristic would result in data starting at 0x2ffff. Now we have two 64k memory data pages for a data segment of 1k! If the data segment instead started at 0x30000 we'd get a single data segment page at the cost of 1 byte extra in the disk image, which is likely a good trade-off. So the linker does adjust the simple heuristic. Just how much disk image size increase is allowed is controlled by the linker's COMMONPAGESIZE variable. A PT_GNU_RELRO segment overlays the initial part of the data segment, saying that those pages should be made read-only after relocation by the dynamic loader. Page granularity for memory protection means that the end of the relro segment must be at a page boundary. The problem =========== Unfortunately most targets currently only align the end of the relro segment to COMMONPAGESIZE. That results in only partial relro protection if an executable is running with MAXPAGESIZE pages, since any part of the relro segment past the last MAXPAGESIZE boundary can't be made read-only without also affecting sections past the end of the relro segment. I believe this problem arose because x86 always runs with 4k (COMMPAGESIZE) memory pages, and therefore using a larger MAXPAGESIZE on x86 is for reasons other than the demand paging and memory page protection boundary requirements. The solution ============ Always end the relro segment on a MAXPAGESIZE boundary, except for x86. Note that the relro segment, comprising of sections at the start of the data segment, is sized according to how those sections are laid out. That means the start of the relro segment is fixed relative to its end. Which also means the start of the data segment must be at a fixed address mod MAXPAGESIZE. So for relro the linker can't play games with the start of the data segment to save disk space. At least, not without introducing gaps between the relro sections. In fact, because the linker was starting layout using its simple heuristic of starting the data segment at the end of the text segment plus one page, it was sometimes introducing page gaps for no reason. See pr28743. PR 28824 PR 28734 * ldexp.c (fold_segment_align): When relro, don't adjust up by offset within page. Set relropagesize. (fold_segment_relro_end): Align to relropagesize. * ldexp.h (seg_align_type): Rename pagesize to commonpagesize. Add relropagesize. Comment. * ldlang.c (lang_size_segment): Adjust to suit field renaming. (lang_size_relro_segment_1): Align relro_end using relropagesize.
* Automatic date update in version.inGDB Administrator2022-02-131-1/+1
|
* Automatic date update in version.inGDB Administrator2022-02-121-1/+1
|
* x86: Disallow invalid relocation against protected symbolH.J. Lu2022-02-1114-25/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am checking this into master and will backport it to 2.38 branch. H.J ---- On x86, GCC 12 supports -mno-direct-extern-access to enable canonical reference to protected function and disable copy relocation. With -mno-direct-extern-access, the canonical protected function symbols must be accessed via canonical reference and the protected data symbols in shared libraries are non-copyable. Under glibc 2.35, non-canonical reference to the canonical protected function will get the run-time error: ./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function and copy relocations against the non-copyable protected symbols will get the run-time error: ./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol Update x86 linker to disallow non-canonical reference to the canonical protected function: ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so ld: failed to set dynamic section sizes: bad value and copy relocation against the non-copyable protected symbol: ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so at link-time. bfd/ PR ld/28875 * elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS. * elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical reference to canonical protected function. * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. * elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy relocation against non-copyable protected symbol. ld/ PR ld/28875 * testsuite/ld-i386/i386.exp: Check non-canonical reference to canonical protected function and check copy relocation against non-copyable protected symbol. * testsuite/ld-i386/pr21997-1.err: New file. * testsuite/ld-i386/pr28875.err: Likewise. * testsuite/ld-i386/pr28875a.c: Likewise. * testsuite/ld-i386/pr28875b.c: Likewise. * testsuite/ld-x86-64/pr21997-1a.err: Updated. * testsuite/ld-x86-64/pr21997-1b.err: Likewise. * testsuite/ld-x86-64/pr28875-data.err: New file. * testsuite/ld-x86-64/pr28875-func.err: Likewise. * testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference to canonical protected function and check copy relocation against non-copyable protected symbol.
* Add initializers to bound_minimal_symbolTom Tromey2022-02-114-12/+4
| | | | | | | This adds initializers to bound_minimal_symbol, allowing for the removal of some calls to memset.
* gdb/fortran: support ptype and print commands for namelist variablesBhuvanendra Kumar N2022-02-117-16/+155
| | | | | | | | | | | | | | | | | | | | | | | | | Gfortran supports namelists (a Fortran feature); it emits DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not process these dies and does not support 'print' or 'ptype' commands on namelist variables. An attempt to print namelist variables results in gdb bailing out with the error message as shown below. (gdb) print nml No symbol "nml" in current context. This commit is to make the print and ptype commands work for namelist variables and its items. Sample output of these commands is shared below, with fixed gdb. (gdb) ptype nml type = Type nml integer(kind=4) :: a integer(kind=4) :: b End Type nml (gdb) print nml $1 = ( a = 10, b = 20 )
* gdb: fix until behavior with trailing !is_stmt linesBruno Larsen2022-02-113-0/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using the command "until", it is expected that GDB will exit a loop if the current instruction is the last one related to that loop. However, if there were trailing non-statement instructions, "until" would just behave as "next". This was noticeable in clang-compiled code, but might happen with gcc-compiled as well. PR gdb/17315 relates to this problem, as running gdb.base/watchpoint.exp with clang would fail for this reason. To better understand this issue, consider the following source code, with line numbers marked on the left: 10: for (i = 0; i < 10; ++i) 11: loop_body (); 12: other_stuff (); If we transform this to pseudo-assembler, and generate a line table, we could end up with something like this: Address | Pseudo-Assembler | Line | Is-Statement? 0x100 | i = 0 | 10 | Yes 0x104 | loop_body () | 11 | Yes 0x108 | i = i + 1 | 10 | Yes 0x10c | if (i < 10): | 10 | No 0x110 | goto 0x104 | 10 | No 0x114 | other_stuff () | 12 | Yes Notice the two non-statement instructions at the end of the loop. The problem is that when we reach address 0x108 and use 'until', hoping to leave the loop, GDB sets up a stepping range that runs from the start of the function (0x100 in our example) to the end of the current line table entry, that is 0x10c in our example. GDB then starts stepping forward. When 0x10c is reached GDB spots that we have left the stepping range, that the new location is not a statement, and that the new location is associated with the same source line number as the previous stepping range. GDB then sets up a new stepping range that runs from 0x10c to 0x114, and continues stepping forward. Within that stepping range the inferior hits the goto (at 0x110) and loops back to address 0x104. At 0x104 GDB spots that we have left the previous stepping range, that the new address is marked as a statement, and that the new address is for a different source line. As a result, GDB stops and returns control to the user. This is not what the user was expecting, they expected GDB to exit the loop. The fix proposed in this patch, is that, when the user issues the 'until' command, and GDB sets up the initial stepping range, GDB will check subsequent SALs (symtab_and_lines) to see if they are non-statements associated with the same line number. If they are then the end of the initial stepping range is extended to the end of the non-statement SALs. In our example above, the user is at 0x108 and uses 'until', GDB now sets up a stepping range from the start of the function 0x100 to 0x114, the first address associated with a different line. Now as GDB steps around the loop it never leaves the initial stepping range. It is only when GDB exits the loop that we leave the stepping range, and the stepping finishes at address 0x114. This patch also adds a test case that can be run with gcc to test that this functionality is not broken in the future. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17315
* gas/doc: Fix "a true results" typoRichard Sandiford2022-02-111-1/+1
|
* gdb: extend the information printed by 'maint info jit'Jan Vrany2022-02-113-14/+78
| | | | | | | | | | | | | | | | | | This commit updates the output of 'maint info jit' to print not just the jit_code_entry address, but also the symfile address, and the symfile size. The new information could be obtained by looking into target memory at the contents of the jit_code_entry, but, by storing this information within gdb at the time the jit object is loaded, it is now possible to check if the jit_code_entry has been modified in target memory behind gdb's back. Additionally, the symfile address is the same address that is now used in the objfile names after commit 4a620b7e. One test that relies on the output of 'maint info jit' was updated to allow for the new output format.
* bfd: Remove return with expression in void functionMichael Forney2022-02-112-1/+6
| | | | | * bfd.c (bfd_set_gp_value): Remove return with expression in void function.
* gdb: LoongArch: Add Makefile, configure and NEWSTiezhu Yang2022-02-116-0/+33
| | | | | | | | | This commit adds Makefile, configure and NEWS for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
* gdb: LoongArch: Add initial native Linux supportTiezhu Yang2022-02-111-0/+184
| | | | | | | | | This commit adds initial native Linux support for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
* gdb: LoongArch: Add initial Linux target supportTiezhu Yang2022-02-111-0/+151
| | | | | | | | | This commit adds initial Linux target support for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
* gdb: LoongArch: Add initial baremetal supportTiezhu Yang2022-02-112-0/+365
| | | | | | | | | This commit adds initial baremetal support for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
* gdb: LoongArch: Add initial target description supportTiezhu Yang2022-02-117-0/+353
| | | | | | | | | This commit adds initial target description support for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
View Lorry Controller Status