aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-02section.c: Fix typo in comments (withe -> with)H.J. Lu3-2/+7
* bfd-in2.h: Regenerated. * section.c (SEC_ASSEMBLER_SECTION_ID): Fix a typo in comments.
2020-02-02ELF: Add support for unique section ID to assemblerH.J. Lu34-64/+551
Clang's integrated assembler supports multiple section with the same name: .section .text,"ax",@progbits,unique,1 nop .section .text,"ax",@progbits,unique,2 nop "unique,N" assigns the number, N, as the section ID, to a section. The valid values of the section ID are between 0 and 4294967295. It can be used to distinguish different sections with the same section name. This is useful with -fno-unique-section-names -ffunction-sections. -ffunction-sections by default generates .text.foo, .text.bar, etc. Using the same string can save lots of space in .strtab. This patch adds section_id to bfd_section and reuses the linker internal bit in BFD section flags, SEC_LINKER_CREATED, for assmebler internal use to mark valid section_id. It also updates objdump to compare section pointers if 2 sections comes from the same file since 2 different sections can have the same section name. bfd/ PR gas/25380 * bfd-in2.h: Regenerated. * ecoff.c (bfd_debug_section): Add section_id. * section.c (bfd_section): Add section_id. (SEC_ASSEMBLER_SECTION_ID): New. (BFD_FAKE_SECTION): Add section_id. binutils/ PR gas/25380 * objdump.c (sym_ok): Return FALSE if 2 sections are in the same file with different section pointers. gas/ PR gas/25380 * config/obj-elf.c (section_match): Removed. (get_section): Also match SEC_ASSEMBLER_SECTION_ID and section_id. (obj_elf_change_section): Replace info and group_name arguments with match_p. Also update the section ID and flags from match_p. (obj_elf_section): Handle "unique,N". Update call to obj_elf_change_section. * config/obj-elf.h (elf_section_match): New. (obj_elf_change_section): Updated. * config/tc-arm.c (start_unwind_section): Update call to obj_elf_change_section. * config/tc-ia64.c (obj_elf_vms_common): Likewise. * config/tc-microblaze.c (microblaze_s_data): Likewise. (microblaze_s_sdata): Likewise. (microblaze_s_rdata): Likewise. (microblaze_s_bss): Likewise. * config/tc-mips.c (s_change_section): Likewise. * config/tc-msp430.c (msp430_profiler): Likewise. * config/tc-rx.c (parse_rx_section): Likewise. * config/tc-tic6x.c (tic6x_start_unwind_section): Likewise. * doc/as.texi: Document "unique,N" in .section directive. * testsuite/gas/elf/elf.exp: Run "unique,N" tests. * testsuite/gas/elf/section15.d: New file. * testsuite/gas/elf/section15.s: Likewise. * testsuite/gas/elf/section16.s: Likewise. * testsuite/gas/elf/section16a.d: Likewise. * testsuite/gas/elf/section16b.d: Likewise. * testsuite/gas/elf/section17.d: Likewise. * testsuite/gas/elf/section17.l: Likewise. * testsuite/gas/elf/section17.s: Likewise. * testsuite/gas/i386/unique.d: Likewise. * testsuite/gas/i386/unique.s: Likewise. * testsuite/gas/i386/x86-64-unique.d: Likewise. * testsuite/gas/i386/i386.exp: Run unique and x86-64-unique. ld/ PR gas/25380 * testsuite/ld-i386/pr22001-1c.S: Use "unique,N" in .section directives. * testsuite/ld-i386/tls-gd1.S: Likewise. * testsuite/ld-x86-64/pr21481b.S: Likewise.
2020-02-03Automatic date update in version.inGDB Administrator1-1/+1
2020-02-02elf/section13.s: Replace @nobits with %nobitsH.J. Lu2-1/+5
* testsuite/gas/elf/section13.s: Replace @nobits with %nobits.
2020-02-01moxie: don't force big-endian modeGitea2-2/+4
2020-02-02Automatic date update in version.inGDB Administrator1-1/+1
2020-02-01Update release making documentationNick Clifton2-20/+48
2020-02-01Move pending obsolete targets onto the definitely obsolete listNick Clifton2-1/+6
2020-02-01ubsan: frv: left shift of negative valueAlan Modra4-7/+16
More non-bugs flagged by ubsan, unless you happen to be compiling for a 1's complement host. cpu/ * frv.cpu (f-u12): Multiply rather than left shift signed values. (f-label16, f-label24): Likewise. opcodes/ * frv-ibld.c: Regenerate.
2020-02-01gdb: Do not print empty-group regs when printing general onesShahab Vahedi2-5/+13
When the command "info registers" (same as "info registers general"), is issued, _all_ the registers from a tdesc XML are printed. This includes the registers with empty register groups (set as "") which are supposed to be only printed by "info registers all" (or "info all-registers"). This bug got introduced after all the overhauls that the tdesc_register_in_reggroup_p() went through. You can see that the logic of tdesc_register_in_reggroup_p() did NOT remain the same after all those changes: git difftool c9c895b9666..HEAD -- gdb/target-descriptions.c With the current implementation, when the reg->group is an empty string, this function returns -1, while in the working revision (c9c895b9666), it returned 0. This patch makes sure that the 0 is returned again. The old implementation of tdesc_register_in_reggroup_p() returned -1 when "reggroup" was set to "all_reggroups" at line 4 below: 1 tdesc_register_reggroup_p (...) 2 { 3 ... 4 ret = tdesc_register_in_reggroup_p (gdbarch, regno, reggroup); 5 if (ret != -1) 6 return ret; 7 8 return default_register_reggroup_p (gdbarch, regno, reggroup); 9 } As a result, the execution continued at line 8 and the default_register_reggroup_p(..., reggroup=all_reggroups) would return 1. However, with the current implementation of tdesc_register_in_reggroup_p() that allows checking against any arbitrary group name, it returns 0 when comparing the "reg->group" against the string "all" which is the group name for "all_reggroups". I have added a special check to cover this case and "info all-registers" works as expected. gdb/ChangeLog: * target-descriptions.c (tdesc_register_in_reggroup_p): Return 0 when reg->group is empty and reggroup is not. Change-Id: I9eaf9d7fb36410ed5684ae652fe4756b1b2e61a3
2020-02-01Automatic date update in version.inGDB Administrator1-1/+1
2020-02-01[gdb/testsuite] Fix typo in gdb.server/server-kill-python.expTom de Vries2-1/+5
Fix typo '$gdb_tst_name' -> '$gdb_test_name'. gdb/testsuite/ChangeLog: 2020-02-01 Tom de Vries <tdevries@suse.de> * gdb.server/server-kill-python.exp: Fix $gdb_tst_name typo. Change-Id: Iad050dab0e8aad2f2692e54e398021558250f1ac
2020-01-31nios2: Add BFD support for GOT-relative DW_EH_PE_datarel encodingsSandra Loosemore2-0/+6
There's already existing logic to handle this on other targets, so this patch just makes nios2 use it. 2020-01-31 Sandra Loosemore <sandra@codesourcery.com> bfd/ * elf-eh-frame.c (_bfd_elf_write_section_eh_frame): DW_EH_PE_datarel encodings are relative to the GOT on nios2, too.
2020-01-31nios2: recognize %gotoff relocation in assemblerSandra Loosemore2-10/+35
The nios2 ABI documentation lists %gotoff as assembler syntax for the R_NIOS2_GOTOFF relocation, used to represent a 32-bit GOT-relative offset in data sections. This was previously unimplemented in GAS. 2020-01-31 Sandra Loosemore <sandra@codesourcery.com> gas/ * config/tc-nios2.c (nios2_cons): Handle %gotoff as well as %tls_ldo.
2020-01-31Add missing ChangeLog for last patchAndre Vieira1-0/+8
2020-01-31arm: PR gas/25472 Enable DSP instructions with +mveAndre Vieira2-6/+148
We noticed +mve was not enabling DSP instructions as it should, reported in PR 25472. The MVE architecture extension for Armv8.1-M Mainline implies DSP extensions. This patch reflects that in the '+mve' command line option. gas/ChangeLog: 2020-01-31 Andre Vieira <andre.simoesdiasvieira@arm.com> PR gas/25472 * config/tc-arm.c (armv8m_main_ext_table): Refactored +dsp adding. (armv8_1m_main_ext_table): Refactored +dsp adding and enabled dsp for +mve. * testsuite/gas/arm/mve_dsp.d: New test.
2020-01-31Fix compile time build problem building the s390 assembler.Nick Clifton2-1/+6
* config/tc-s390.c (s390_elf_suffix): Return ELF_SUFFIX_NONE rather than BFD_RELOC_NONE.
2020-01-31[ARM]: Add support for vldmia/vldmdb/vstmia/vstmdb instructions in MVE.Srinath Parvathaneni4-4/+75
This patch adds support for assembly instructions vldmia, vldmdb, vstmia and vstmdb in MVE. This instructions are already supported for Armv8-M Floating-point Extension. gas/ChangeLog: 2020-01-31 Srinath Parvathaneni <srinath.parvathaneni@arm.com> * config/tc-arm.c (fldmias): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VLDMIA instruction for MVE. (fldmdbs): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VLDMDB instruction for MVE. (fstmias): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VSTMIA instruction for MVE. (fstmdbs): Moved inside "THUMB_VARIANT & arm_ext_v6t2" to support VSTMDB instruction for MVE. * testsuite/gas/arm/mve-ldst.d: New test. * testsuite/gas/arm/mve-ldst.s: Likewise.
2020-01-31Updated translations for some of the binutils sub-directoriesNick Clifton5-7835/+9961
2020-01-31x86: replace EXxmm_mdq by EXVexWdqScalarJan Beulich3-27/+29
There's no need to have two operand specifiers / enumerators for the same purpose. This then renders xmm_mdq_mode unused.
2020-01-31x86: drop unused EXVexWdq / vex_w_dq_modeJan Beulich2-7/+10
2020-01-31aarch64: Fix MOVPRFX markup for bf16 conversionsRichard Sandiford8-4/+102
bfcvt converts a .S input to a .H output, so any predicated movprfx needs to operate on .S rather than .H. In common with SVE2 narrowing top operations, bfcvtnt doesn't accept movprfx. 2020-01-31 Richard Sandiford <richard.sandiford@arm.com> opcodes/ * aarch64-tbl.h (aarch64_opcode): Set C_MAX_ELEM for SVE bfcvt. Remove C_SCAN_MOVPRFX for SVE bfcvtnt. gas/ * testsuite/gas/aarch64/sve-bfloat-movprfx.s: Use .h rather than .s for the movprfx. * testsuite/gas/aarch64/sve-bfloat-movprfx.d: Update accordingly. * testsuite/gas/aarch64/sve-movprfx_28.d, * testsuite/gas/aarch64/sve-movprfx_28.l, * testsuite/gas/aarch64/sve-movprfx_28.s: New test.
2020-01-31Fix ravenscar-thread.c for multi-targetTom Tromey2-1/+7
ravenscar-thread.c needed a change to adapt to multi-target: ravenscar_thread_target::mourn_inferior called the mourn_inferior method on the target beneat -- but when the target beneath was the remote target, this resulted in the ravenscar target being deleted. Switching the order of the calls to unpush_target and the beneath's mourn_inferior fixes this problem. gdb/ChangeLog 2020-01-31 Tom Tromey <tromey@adacore.com> * ravenscar-thread.c (ravenscar_thread_target::mourn_inferior): Call beneath target's mourn_inferior after unpushing. Change-Id: Ia80380515c403adc40505a6b3420c9cb35754370
2020-01-31gdb/tui: Disassembler scrolling of very small programsAndrew Burgess5-1/+87
In TUI mode, if the disassembly output for the program is less than one screen long, then currently if the user scrolls down until on the last assembly instruction is displayed and then tries to scroll up using Page-Up, the display doesn't update - they are stuck viewing the last line. If the user tries to scroll up using the Up-Arrow, then the display scrolls normally. What is happening is on the Page-Up we ask GDB to scroll backward the same number of lines as the height of the TUI ASM window. The back scanner, which looks for a good place to start disassembling, fails to find a starting address which will provide the requested number of new lines before we get back to the original starting address (which is not surprising, our whole program contains less than a screen height of instructions), as a result the back scanner gives up and returns the original starting address. When we scroll with Up-Arrow we only ask the back scanner to find 1 new instruction, which it manages to do, so this scroll works. The solution here is, when we fail to find enough instructions, to return the lowest address we did manage to find. This will ensure we jump to the lowest possible address in the disassembly output. gdb/ChangeLog: PR tui/9765 * tui/tui-disasm.c (tui_find_disassembly_address): If we don't have enough lines to fill the screen, still return the lowest address we found. gdb/testsuite/ChangeLog: PR tui/9765 * gdb.tui/tui-layout-asm-short-prog.S: New file. * gdb.tui/tui-layout-asm-short-prog.exp: New file. Change-Id: I6a6a7972c68a0559e9717fd8d82870b669a40af3
2020-01-31gdb/tui: Update help text for scroll commandsAndrew Burgess2-4/+17
GDB has some commands ('+', '-', '<', and '>') for scrolling the SRC and ASM TUI windows from the CMD window, however the help text for these commands lists the arguments in the wrong order. This commit updates the help text to match how GDB actually works, and also extends the text to describe what the arguments mean, and what the defaults are. There should be no change in GDBs functionality after this commit. gdb/ChangeLog: * tui/tui-win.c (_initialize_tui_win): Update help text for '+', '-', '<', and '>' commands. Change-Id: Ib2624891de1f4ba983838822206304e4c3ed982e
2020-01-31Tidy bfd.potAlan Modra3-74/+54
This patch removes the leak of Nick's source directory into bfd.pot, and emits #line for some generated files so that those files aren't referenced by comments in the .pot file. You can see both of these effects in the following diff. I've also removed use of an unnecessary temp file in the make rules. @@ -92,10 +92,8 @@ msgstr "" #: elf64-nfp.c:238 elf64-ppc.c:1014 elf64-ppc.c:1349 elf64-ppc.c:1358 #: elf64-s390.c:328 elf64-s390.c:378 elf64-x86-64.c:285 elfn32-mips.c:3786 #: elfxx-ia64.c:324 elfxx-riscv.c:955 elfxx-sparc.c:589 elfxx-sparc.c:639 -#: elfxx-tilegx.c:912 elfxx-tilegx.c:952 -#: /work/sources/binutils/current/bfd/elfnn-aarch64.c:2215 -#: /work/sources/binutils/current/bfd/elfnn-aarch64.c:2313 elf32-ia64.c:214 -#: elf32-ia64.c:3862 elf64-ia64.c:214 elf64-ia64.c:3862 +#: elfxx-tilegx.c:912 elfxx-tilegx.c:952 elfnn-aarch64.c:2215 +#: elfnn-aarch64.c:2313 elfnn-ia64.c:214 elfnn-ia64.c:3862 #, c-format msgid "%pB: unsupported relocation type %#x" msgstr "" * Makefile.am (elf32-target.h, elf64-target.h): Don't use a temp file. Use $< and $@ in rules. (elf32-aarch64.c, elf64-aarch64.c): Likewise. (elf32-ia64.c, elf64-ia64.c): Likewise. (elf32-riscv.c, elf64-riscv.c): Likewise. (peigen.c, pepigen.c, pex64igen.c): Likewise. (elf32-aarch64.c, elf64-aarch64.c): Don't emit $srcdir on #line. (elf32-riscv.c, elf64-riscv.c): Likewise, and use $(SED). (elf32-ia64.c, elf64-ia64.c): Do emit #line. (peigen.c, pepigen.c, pex64igen.c): Likewise. * Makefile.in: Regenerate.
2020-01-31OOM in setup_groupAlan Modra2-3/+10
We alloc, seek and read using section sizes in object files. Fuzzed objects can have silly sizes, but that's OK if the system supports memory over-commit. The read fails because we hit EOF and that usually results in a graceful exit. But if we memset before the read then the invalid size results in attempting to write to a huge number of memory pages, and an eventual Out Of Memory after probably swapping like crazy. So don't memset. There really isn't a need to clear the section contents anyway. All bytes are written with a good object file by the read and following loop converting section index in target order to ELF section header pointer, and the only untidy bytes are the 4 bytes past the group flags when pointers are 8 bytes. Those don't matter but the patch clears them for anyone poking around in a debugger. On error paths it's as good to free section contents as it is to clear them. Noticed when looking at PR4110 fourth test case. PR 4110 * elf.c (setup_group): Don't clear entire section contents, just the padding after group flags. Release alloc'd memory after a seek or read failure.
2020-01-31Automatic date update in version.inGDB Administrator1-1/+1
2020-01-30x86: prevent undue use of GOT32X and alike relocationsJan Beulich5-29/+68
Comparison of i.tm.base_opcode against particular but not sufficiently specific values needs to be accompanied by other qualification. Exclude VEX and alike encodings here, and also exclude all forms of prefixes explicitly specified in the opcodes table. While using @GOT with such insns may not be very useful, it also isn't with e.g. ADC and SBB, yet these get explicitly listed in comments as supported.
2020-01-30ld/doc: drop blank between @option and braceJan Beulich2-1/+5
Commit 9e7028aa1e78 ("PowerPC64 __tls_get_addr_desc") introduced a use of @option which apparently newer makeinfo tolerates, but older ones reject. Drop the unnecessary (a per all other uses of @option) blank.
2020-01-30ubsan: m32c: left shift of negative valueAlan Modra4-30/+46
More nonsense fixing "bugs" with left shifts of signed values. Yes, the C standard does say this is undefined (and right shifts of signed values are implementation defined BTW) but in practice there is no problem with current machines. 1's complement is a thing of the past. cpu/ * m32c.cpu (f-src32-rn-unprefixed-QI): Shift before inverting. (f-src32-rn-prefixed-QI, f-dst32-rn-unprefixed-QI): Likewise. (f-dst32-rn-prefixed-QI): Likewise. (f-dsp-32-s32): Mask before shifting left. (f-dsp-48-u32, f-dsp-48-s32): Likewise. (f-bitbase32-16-s11-unprefixed): Multiply signed field rather than shifting left. (f-bitbase32-24-s11-prefixed, f-bitbase32-24-s19-prefixed): Likewise. (h-gr-SI): Mask before shifting. opcodes/ * m32c-ibld.c: Regenerate.
2020-01-30Identify reproducible builds in 'objdump -p' output for PE filesJon Turney2-5/+86
These are produced by MSVC when the '/Brepro' flag is used. To quote from the PE specification [1]: "The presence of an entry of type IMAGE_DEBUG_TYPE_REPRO indicates the PE file is built in a way to achieve determinism or reproducibility. If the input does not change, the output PE file is guaranteed to be bit-for-bit identical no matter when or where the PE is produced. Various date/time stamp fields in the PE file are filled with part or all the bits from a calculated hash value that uses PE file content as input, and therefore no longer represent the actual date and time when a PE file or related specific data within the PE is produced. The raw data of this debug entry may be empty, or may contain a calculated hash value preceded by a four-byte value that represents the hash value length." [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format bfd/ChangeLog: 2020-01-16 Jon Turney <jon.turney@dronecode.org.uk> * peXXigen.c (pe_is_repro): New function. (_bfd_XX_print_private_bfd_data_common): Note timestamp is actually a build hash if PE_IMAGE_DEBUG_TYPE_REPRO is present.
2020-01-30Add some new PE_IMAGE_DEBUG_TYPE valuesJon Turney4-1/+22
IMAGE_DEBUG_TYPE_REPRO is defined in the latest version of the PE specification [1]. The others are defined in Windows SDK headers and/or reported by DUMPBIN. [1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format bfd/ChangeLog: 2020-01-16 Jon Turney <jon.turney@dronecode.org.uk> * peXXigen.c (debug_type_names): Add names for new debug data type values. include/ChangeLog: 2020-01-16 Jon Turney <jon.turney@dronecode.org.uk> * coff/internal.h (PE_IMAGE_DEBUG_TYPE_VC_FEATURE) (PE_IMAGE_DEBUG_TYPE_POGO, PE_IMAGE_DEBUG_TYPE_ILTCG) (PE_IMAGE_DEBUG_TYPE_MPX, PE_IMAGE_DEBUG_TYPE_REPRO): Add.
2020-01-30Bugfixes for pe_print_debugdata()Jon Turney2-3/+10
Use a separate iteration variable for inner loop (:blush:). This generally prevented any debug directory entries after a IMAGE_DEBUG_TYPE_CODEVIEW entry from being reported. Don't leak the memory allocated for the section containing the debug directory. bfd/ChangeLog: 2020-01-16 Jon Turney <jon.turney@dronecode.org.uk> * peXXigen.c (pe_print_debugdata): Fix the iteration variable for inner loop. Fix a memory leak.
2020-01-30cpu,opcodes,gas: fix neg and neg32 instructions in BPFJose E. Marchesi9-9/+26
This patch fixes the neg/neg32 BPF instructions, which have K (=0) instead of X (=1) in their header source bit, despite operating on registes. cpu/ChangeLog: 2020-01-30 Jose E. Marchesi <jose.marchesi@oracle.com> * bpf.cpu (define-alu-insn-un): The unary BPF instructions (neg and neg32) use OP_SRC_K even if they operate only in registers. opcodes/ChangeLog: 2020-01-30 Jose E. Marchesi <jose.marchesi@oracle.com> * bpf-opc.c: Regenerate. gas/ChangeLog: 2020-01-30 Jose E. Marchesi <jose.marchesi@oracle.com> * testsuite/gas/bpf/alu.d: Update expected opcode for `neg'. * testsuite/gas/bpf/alu-be.d: Likewise. * testsuite/gas/bpf/alu32.d: Likewise for `neg32'. * testsuite/gas/bpf/alu32-be.d: Likewise.
2020-01-30x86-64: honor vendor specifics for near RETJan Beulich12-28/+117
While vendors agree about default operand size (64 bits) and hence unavilability of a 32-bit form, AMD honors a 16-bit operand size override (0x66) while Intel doesn't.
2020-01-30x86-64: also diagnose far returns / IRET with ambiguous operand sizeJan Beulich17-46/+134
Other than near returns these default to 32-bit operand size, and hence it isn't really unlikely that 64-bit forms are meant. Hence these should have disambiguating suffixes. In Intel mode, however, don't error in these cases unconditionally - MASM accepts these without suffix _and_ without warning.
2020-01-30x86: drop further pointless/bogus DefaultSizeJan Beulich5-22/+34
- 64-bit CALL permitting just a single operand size doesn't need it. - FLDENV et al should never have had it. It remains suspicious that a number of 64-bit only insns continue to have the attribute, despite this being intended for .code16gcc handling only.
2020-01-30ubsan: tic4x: left shift cannot be represented in type 'int'Alan Modra2-1/+5
The patch also fixes a case where libopcodes built for a 64-bit bfd_vma may print different results to libopcodes built for a 32-bit bfd_vma. * tic4x-dis.c (tic4x_dp): Make unsigned.
2020-01-30Remove need to clear obj_coff_keep_syms in coff object_pAlan Modra3-15/+26
* coffgen.c (coff_real_object_p): Don't clear obj_coff_keep_syms or obj_coff_keep_strings here. (coff_get_normalized_symtab): Free external syms directly. * xcofflink.c (xcoff_link_input_bfd): Restore obj_coff_keep_syms on error exit path.
2020-01-30Automatic date update in version.inGDB Administrator1-1/+1
2020-01-29Fix -Werror-stringop error on infcmd.c:construct_inferior_argumentsPedro Alves2-0/+11
While testing a GCC 10 build of our git HEAD, Sergio noticed an error triggered by -Werror-stringop on infcmd.c:construct_inferior_arguments. One of the things the function does is calculate the length of the string that will hold the inferior's arguments. GCC warns us that 'length' can be 0, which can lead to undesired behaviour: ../../gdb/infcmd.c: In function 'char* construct_inferior_arguments(int, char**)': ../../gdb/infcmd.c:369:17: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 369 | result[0] = '\0'; | ~~~~~~~~~~^~~~~~ ../../gdb/infcmd.c:368:33: note: at offset 0 to an object with size 0 allocated by 'xmalloc' here 368 | result = (char *) xmalloc (length); | ~~~~~~~~^~~~~~~~ The solution here is to assert that 'argc' is greater than 0 on entry, which makes GCC understand that the loops always run at least once, and thus 'length' is always > 0. Tested by rebuilding. gdb/ChangeLog: 2020-01-29 Pedro Alves <palves@redhat.com> Sergio Durigan Junior <sergiodj@redhat.com> * infcmd.c (construct_inferior_arguments): Assert that 'argc' is greater than 0. Change-Id: Ide8407cbedcb4921de1843a6a15bbcb7676c7d26
2020-01-29Adjust src-release.sh's getver due to gdbsupport's move to toplevelSergio Durigan Junior2-2/+8
The move of gdbsupport to the top level directory requires a small change to src-release.sh's "getver" function, which is responsible for determining the version string that will be appended to the release tarball: now the create-version.sh script lives under ./gdbsupport, and not under gdb/gdbsupport anymore. This patch unbreaks the snapshot generation, which hasn't been working since January 14th. ChangeLog: 2020-01-29 Sergio Durigan Junior <sergiodj@redhat.com> * src-release.sh (getver): Look for gdbsupport's create-version.sh script at the current directory if tool is "gdb". Change-Id: Id3b8bed6583a1aaa120c07009366f6c94a62d5db
2020-01-29gdbserver: Fix whitespace configure.srv damage for `i[34567]86-*-mingw*'Maciej W. Rozycki2-1/+6
Fix fallout from commit 42cd72aa0279 ("gdbserver: Make `make TAGS' actually work") add a missing newline to configure.srv for `i[34567]86-*-mingw*'. gdb/gdbserver/ * configure.srv <i[34567]86-*-mingw*>: Fix whitespace damage.
2020-01-29Fix configure.srv error for Linux on PowerPCPedro Franco de Carvalho2-1/+6
An error in commit 42cd72aa0279520384327a1f6d0ebd2eb2200645 caused srv_tgtobj to be overwritten and linux-ppc-low.o to be missed when linking gdbserver for Linux on PowerPC. This patch fixes the error. gdb/gdbserver/ChangeLog: 2020-01-29 Pedro Franco de Carvalho <pedromfc@linux.ibm.com> * configure.srv (powerpc*-*-linux*): Use srv_tgtobj in second assignment instead of srv_linux_obj.
2020-01-29Test handling of additional brk instruction patternsLuis Machado3-0/+105
New in v5: - Use gdb_test_name for gdb_test_multiple. - Use gdb_assert. - Verify count matches the expected sigtraps exactly. New in v4: - Fix formatting nit in gdb/testsuite/gdb.arch/aarch64-brk-patterns.c. New in v3: - Minor formatting and code cleanups. - Added count check to validate number of brk SIGTRAP's. - Moved count to SIGTRAP check conditional block. This test exercises the previous patch's code and makes sure GDB can properly get a SIGTRAP from various brk instruction patterns. GDB needs to be able to see the program exiting normally. If GDB doesn't support the additional brk instructions, we will see timeouts. We bail out with the first timeout since we won't be able to step through the program breakpoint anyway, so it is no use carrying on. gdb/testsuite/ChangeLog: 2020-01-29 Luis Machado <luis.machado@linaro.org> * gdb.arch/aarch64-brk-patterns.c: New source file. * gdb.arch/aarch64-brk-patterns.exp: New test.
2020-01-29Recognize more program breakpoint patternsLuis Machado10-46/+140
New in v3: - Code cleanups based on reviews. New in v2: - Fixed misc problems based on reviews. - Switched to using gdbarch_program_breakpoint_here_p as opposed to gdbarch_insn_is_breakpoint. - Fixed matching of brk instructions. Previously the mask was incorrect, which was showing up as a few failures in the testsuite. Now it is clean. - New testcase (separate patch). - Moved program_breakpoint_here () to arch-utils.c and made it the default implementation of gdbarch_program_breakpoint_here_p. -- It was reported to me that program breakpoints (permanent ones inserted into the code itself) other than the one GDB uses for AArch64 (0xd4200000) do not generate visible stops when continuing, and GDB will continue spinning infinitely. This happens because GDB, upon hitting one of those program breakpoints, thinks the SIGTRAP came from a delayed breakpoint hit... (gdb) x/i $pc => 0x4005c0 <problem_function>: brk #0x90f (gdb) c Continuing. infrun: clear_proceed_status_thread (process 14198) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 14198 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0 infrun: infrun_async(1) infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 14198.14198.0 [process 14198], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: stop_pc = 0x4005c0 infrun: delayed software breakpoint trap, ignoring infrun: no stepping, continue infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0 infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 14198.14198.0 [process 14198], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: stop_pc = 0x4005c0 infrun: delayed software breakpoint trap, ignoring infrun: no stepping, continue infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0 infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 14198.14198.0 [process 14198], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: stop_pc = 0x4005c0 infrun: delayed software breakpoint trap, ignoring infrun: no stepping, continue infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0 infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 14198.14198.0 [process 14198], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: stop_pc = 0x4005c0 infrun: delayed software breakpoint trap, ignoring infrun: no stepping, continue infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14198] at 0x4005c0 infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 14198.14198.0 [process 14198], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP ... ... which is not the case. If the program breakpoint is one GDB recognizes, then it will stop when it hits it. (gdb) x/i $pc => 0x4005c0 <problem_function>: brk #0x0 (gdb) c Continuing. infrun: clear_proceed_status_thread (process 14193) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 14193 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 14193] at 0x4005c0 infrun: infrun_async(1) infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 14193.14193.0 [process 14193], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: stop_pc = 0x4005c0 infrun: random signal (GDB_SIGNAL_TRAP) infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 14193 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 14193 not executing infrun: stop_all_threads done Program received signal SIGTRAP, Trace/breakpoint trap. problem_function () at brk_0.c:7 7 asm("brk %0\n\t" ::"n"(0x0)); infrun: infrun_async(0) Otherwise GDB will keep trying to resume the inferior and will keep seeing the SIGTRAP's, without stopping. To the user it appears GDB has gone into an infinite loop, interruptible only by Ctrl-C. Also, windbg seems to use a different variation of AArch64 breakpoint compared to GDB. This causes problems when debugging Windows on ARM binaries, when program breakpoints are being used. The proposed patch creates a new gdbarch method (gdbarch_program_breakpoint_here_p) that tells GDB whether the underlying instruction is a breakpoint instruction or not. This is more general than only checking for the instruction GDB uses as breakpoint. The existing logic is still preserved for targets that do not implement this new gdbarch method. The end result is like so: (gdb) x/i $pc => 0x4005c0 <problem_function>: brk #0x90f (gdb) c Continuing. infrun: clear_proceed_status_thread (process 16417) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: proceed: resuming process 16417 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 16417] at 0x4005c0 infrun: infrun_async(1) infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 16417.16417.0 [process 16417], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: handle_inferior_event status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: stop_pc = 0x4005c0 infrun: random signal (GDB_SIGNAL_TRAP) infrun: stop_waiting infrun: stop_all_threads infrun: stop_all_threads, pass=0, iterations=0 infrun: process 16417 not executing infrun: stop_all_threads, pass=1, iterations=1 infrun: process 16417 not executing infrun: stop_all_threads done Program received signal SIGTRAP, Trace/breakpoint trap. problem_function () at brk.c:7 7 asm("brk %0\n\t" ::"n"(0x900 + 0xf)); infrun: infrun_async(0) gdb/ChangeLog: 2020-01-29 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (BRK_INSN_MASK): Define to 0xffe0001f. (BRK_INSN_MASK): Define to 0xd4200000. (aarch64_program_breakpoint_here_p): New function. (aarch64_gdbarch_init): Set gdbarch_program_breakpoint_here_p hook. * arch-utils.c (default_program_breakpoint_here_p): Moved from breakpoint.c. * arch-utils.h (default_program_breakpoint_here_p): Moved from breakpoint.h * breakpoint.c (bp_loc_is_permanent): Changed return type to bool and call gdbarch_program_breakpoint_here_p. (program_breakpoint_here): Moved to arch-utils.c, renamed to default_program_breakpoint_here_p, changed return type to bool and simplified. * breakpoint.h (program_breakpoint_here): Moved prototype to arch-utils.h, renamed to default_program_breakpoint_here_p and changed return type to bool. * gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh (program_breakpoint_here_p): New method. * infrun.c (handle_signal_stop): Call gdbarch_program_breakpoint_here_p.
2020-01-29testsuite, cp: add expected failures to pass-by-ref tests for certain compilersTankut Baris Aktemur3-0/+38
There exist expected failures in the pass-by-ref.exp and pass-by-ref-2.exp tests based on the GCC and Clang version. * GCC version <= 6 and Clang do not emit DW_AT_deleted and DW_AT_defaulted. * Clang version >= 7 emits DW_AT_calling_convention, which helps the debugger make the right calling convention decision in some cases despite lacking the 'defaulted' and 'deleted' attributes. Mark the related tests as XFAIL based on the compiler version. Tested on X86_64 using GCC 5.5.0, 6.5.0, 7.4.0, 8.3.0, 9.2.1; and Clang 5.0.1, 6.0.0, 7.0.0, 8.0.0, 9.0.1, 10.0.0. gdb/testsuite/ChangeLog: 2020-01-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.cp/pass-by-ref-2.exp: Mark some tests as XFAIL based on the GCC/Clang version. * gdb.cp/pass-by-ref.exp: Ditto. Change-Id: I1d8440aa438049f7c4da7f4f76f201c48550f1e4
2020-01-29[gdb/testsuite] Fix gdb.threads/watchpoint-fork.exp raceTom de Vries6-2/+31
I ran into: ... Thread 3.1 "watchpoint-fork" hit Breakpoint 3, marker () at \ watchpoint-fork-mt.c:42^M 42 }^M (gdb) parent2: 1945^M FAIL: gdb.threads/watchpoint-fork.exp: child: multithreaded: breakpoint (A) \ after the second fork (timeout) ... The problem is that the FAILing gdb_test expects '(gdb) ' to be the last thing printed, but the inferior prints something after that. A similar FAIL is described in the sources in watchpoint-fork-parent.c: ... printf ("child%d: %d\n", nr, (int) getpid ()); /* Delay to get both the "child%d" and "parent%d" message printed without a race breaking expect by its endless wait on `$gdb_prompt$': Breakpoint 3, marker () at watchpoint-fork.c:33 33 } (gdb) parent2: 14223 */ i = sleep (1); ... I noticed that while the executables print output, the output is not verified in the test-case, so it's merely debug output. Fix this by: - guarding the prints in the executables (as well as related sleep and setbuf calls) with #if DEBUG, and - compiling by default with DEBUG=0. gdb/testsuite/ChangeLog: 2020-01-29 Tom de Vries <tdevries@suse.de> * gdb.threads/watchpoint-fork-child.c: Guard prints with #if DEBUG. * gdb.threads/watchpoint-fork-mt.c: Same. * gdb.threads/watchpoint-fork-parent.c: Same. * gdb.threads/watchpoint-fork-st.c: Same. * gdb.threads/watchpoint-fork.exp: Compile with DEBUG=0. Change-Id: I63efd4c7771f96b5f5cd87ef2ab36795484ae2be
2020-01-29PR25477, ld 2.34 tries to load ${prefix}/etc/ld.so.confAlan Modra6-8/+20
PR 25477 * ldelf.c (ldelf_check_ld_so_conf): Add prefix parameter and correct concat. (ldelf_after_open): Add prefix parameter. * ldelf.h (ldelf_after_open): Update prototype. * emultempl/elf.em (gld${EMULATION_NAME}_after_open): Pass $prefix to ldelf_after_open. * Makefile.am: Correct z80 dependencies. * Makefile.in: Regenerate.
generated by cgit v1.1 at 2025-09-24 04:47:00 +0000