aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-01-15Fix gdb.texinfo moreSzabolcs Nagy2-0/+5
Add incorrectly removed @pindex back. gdb/doc/ChangeLog: * gdb.texinfo (gdb-add-index man): Add pindex.
2018-01-15Update Ukranian translations for bfd, binutils, gas, gold, ld and opcodesNick Clifton12-7548/+9404
2018-01-15Fix gdb.texinfo for old makeinfo (again)Szabolcs Nagy2-4/+8
With old makeinfo (version 4.13) the changes introduced in commit ba643918cf869fa0d064d733f69b453b6fe642ea Author: Sergio Durigan Junior <sergiodj@redhat.com> Install and generate docs for gdb-add-index fail to build with gdb/doc/gdb.texinfo:2498: warning: `.' or `,' must follow @xref, not `@'. gdb/doc/gdb.texinfo:2517: warning: `.' or `,' must follow @xref, not `@'. gdb/doc/gdb.texinfo:43443: Node `gdb-add-index man' requires a sectioning command (e.g., @unnumberedsubsec). gdb/doc/gdb.texinfo:43443: `gdb-add-index man' has no Up field (perhaps incorrect sectioning?). gdb/doc/gdb.texinfo:43350: Next field of node `gdbinit man' not pointed to (perhaps incorrect sectioning?). gdb/doc/gdb.texinfo:43443: This node (gdb-add-index man) has the bad Prev. This patch fixes the warnings too. gdb/doc/ChangeLog: * gdb.texinfo (set cwd): Add period. (gdb-add-index man): Move anchor.
2018-01-15Automatic date update in version.inGDB Administrator1-1/+1
2018-01-14Automatic date update in version.inGDB Administrator1-1/+1
2018-01-13Update notes on how to make a releaseNick Clifton4-14/+17
2018-01-13Update pot filesNick Clifton14-6537/+8036
2018-01-13Bump version number to 2.30.51Nick Clifton14-61/+87
bfd/ * version.m4: Bump version to 2.30.51 * configure: Regenerate. binutils/ * configure: Regenerate. gas/ * configure: Regenerate. gprof/ * configure: Regenerate. ld/ * configure: Regenerate. opcodes/ * configure: Regenerate.
2018-01-13Add note about 2.30 branch creation to changelogsNick Clifton11-0/+32
2018-01-13Add 2.30 markers to NEWS files.Nick Clifton8-3/+26
binutils/ * NEWS: Add marker for 2.30. gas/ * NEWS: Add marker for 2.30. ld/ * NEWS: Add marker for 2.30.
2018-01-12Update gold version number to 1.15.Cary Coutant3-2/+20
gold/ * NEWS: Add new features in 1.15. * version.cc (version_string): Bump to 1.15.
2018-01-13Automatic date update in version.inGDB Administrator1-1/+1
2018-01-12gdb/testsuite: Don't attempt tests if they fail to compileAndrew Burgess2-3/+12
In the gdb.base/whatis-ptype-typedefs.exp test, if the test program fails to compile, don't run the tests. gdb/testsuite/ChangeLog: * gdb.base/whatis-ptype-typedefs.exp: Don't run tests if we failed to prepare. (prepare): Return 0 on error, 1 on success.
2018-01-12Install and generate docs for gdb-add-indexSergio Durigan Junior5-1/+100
The "gdb-add-index" script has been resurrected on: commit caf26be91a584ef141ac5d3cb31007731af8b8e3 Author: Samuel Bronson <naesten@gmail.com> Date: Fri Nov 15 16:09:33 2013 -0500 Resurrect gdb-add-index as a contrib script However, for some reason (I couldn't find it in the archives), only the script has been checked-in; the Makefile parts responsible for installing it in the system were left out. This commit fixes that, by also resurrecting the Makefile and documentation bits. This commit is part of our effort to upstream the local Fedora GDB changes. With this commit, we'll only carry a very small Fedora-specific modification to the script. gdb/ChangeLog: 2017-01-12 Tom Tromey <tom@tromey.com> Sergio Durigan Junior <sergiodj@redhat.com> * Makefile.in (install-only): Install gdb-add-index. gdb/doc/ChangeLog: 2017-01-12 Tom Tromey <tom@tromey.com> Sergio Durigan Junior <sergiodj@redhat.com> * gdb.texinfo (Index Files): Mention gdb-add-index. (gdb-add-index man): New section. * Makefile.in (gdb-add-index.1): New rule to generate manpage from gdb.texinfo.
2018-01-12Use the correct value for the offset of 'kve_protection'.John Baldwin2-1/+5
I had forgotten to convert the decimal output of 'ptype /o' to hex (but still used a 0x prefix) for the KVE_PROTECTION constant defining the offset of the 'kve_protection' field in the 'kinfo_vmentry' structure. This resulted in garbage permissions for entries in 'info proc mappings' for FreeBSD core dumps. gdb/ChangeLog: * fbsd-tdep.c (KVE_PROTECTION): Correct value.
2018-01-12Apply:Eric Christopher2-1/+10
2018-01-12 Sterling Augustine <saugustine@google.com> * cref.cc (Cref_inputs::Cref_table_compare::operator): Add conditionals and calls to is_forwarder.
2018-01-12Add testcase for GDB hang fixed by previous commitPedro Alves3-0/+121
This adds a testcase for the previous commit. The regression was related to in-line step overs. The reason we didn't see it on native x86-64/s390 GNU/Linux testing is that native debugging uses displaced stepping by default (because native debugging defaults to "maint set target-non-stop on"), unlike remote debugging. So in order to trigger the bug with native debugging as well, the testcase disables displaced stepping explicitly. Also, instead of using watchpoints to trigger the regression, the testcase uses a breakpoint at address 0, which should be more portable. gdb/testsuite/ChangeLog: 2018-01-12 Pedro Alves <palves@redhat.com> * gdb.base/continue-after-aborted-step-over.c: New. * gdb.base/continue-after-aborted-step-over.exp: New.
2018-01-12Fix GDB hang with remote after error from resumeAndreas Arnez2-0/+6
Since this commit -- Fix PR18360 - internal error when using "interrupt -a" (https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=c65d6b55) -- the testsuite shows long delays on s390 with native-gdbserver when executing certain tests, such as watchpoints.exp. These hangs have been discussed before in the context of buildbot problems, see here: https://sourceware.org/ml/gdb-patches/2017-12/msg00413.html The problem can easily be triggered by stopping on a breakpoint, then setting impossible watchpoints, and finally doing "continue". Then, after having set the step-over state (in keep_going_pass_signal in infrun.c), GDB tries to insert breakpoints and watchpoints into the inferior. This fails, and the "continue" command is aborted. But the step-over state is not cleared in this case, which causes future step-over attempts to be skipped since GDB thinks that "we already have an in-line step-over operation ongoing" (see start_step_over in infrun.c). Thus the next "continue" just goes on to wait for events from the remote, which will never occur. The problem can also be reproduced on amd64 with native-gdbserver, using the following change to watchpoints.exp: -- >8 -- --- a/gdb/testsuite/gdb.base/watchpoints.exp +++ b/gdb/testsuite/gdb.base/watchpoints.exp @@ -61,2 +61,3 @@ with_test_prefix "before inferior start" { gdb_test "watch ival3" ".*" "" + gdb_test "watch *(char \[256\] *) main" -- >8 -- To fix the hang, this patch clears the step-over info when insert_breakpoints has failed. Of course, with native-gdbserver the watchpoints.exp test case still causes many FAILs on s390, because gdbserver does not support watchpoints for that target. This is a separate issue. gdb/ChangeLog: 2018-01-12 Andreas Arnez <arnez@linux.vnet.ibm.com> * infrun.c (keep_going_pass_signal): Clear step-over info when insert_breakpoints fails.
2018-01-12Add notes on how to make a branch and a pre-release snapshot.Nick Clifton3-0/+80
* README-how-to-make-a-release: Add notes on how to make the branch and prelease snapshot. * BRANCHES: Add binutils-2_29-branch.
2018-01-12Optimize the performance of the group_setup function.Jens Widell3-3/+18
When processing a section that is a member of a group, the group that contains it is looked up using a linear search. The resulting O(n^2) complexity causes significant performance issues when dealing with object files with very many groups. By remembering the index of the last found group and restarting the next search from that index, the search instead becomes O(n) in common cases. * elf.c (setup_group): Optimize search for group by remembering last found group and restarting search at that index. * elf-bfd.h (struct elf_obj_tdata): Add group_search_offset field.
2018-01-12Fix compile time warning building aout targeted architectures.Gunther Nikl2-3/+10
Occasionally I build an out-of-tree a.out target (m68k-amigaos). After a system upgrade which included a newer compiler (clang 4) the build produces warnings like this: warning: macro expansion producing 'defined' has undefined behavior [-Wexpansion-to-defined] This is caused by the macro gas/config/aout_gnu.h:USE_EXTENDED_RELOC. Since it is in a header file, the warning triggers for several files. I am unsure what solution is preferable, thus I am suggesting two patches: a) keep the offending macro but define it explicitly to 0 and 1 b) replace the macro usage with its value where it is used. Either patch removes the warning for clang. I did not check with a recent GCC. * gas/config/aout_gnu.h (USE_EXTENDED_RELOC): Explicitly define to 0 and 1. Remove a dangling reference to "AMD 29000" in a comment.
2018-01-12pr22374 function pointer initializationAlan Modra2-0/+20
When I added this test I said I'd look at fixing more targets. That hasn't happened yet, so xfail to tidy results. * testsuite/ld-elf/elf.exp: xfail "pr22374 function pointer initialization" for currently failing targets.
2018-01-12Fix override of common symbols for a.outAlan Modra2-1/+7
The default should be bfd_link_common_skip_none, as in the original patch at https://sourceware.org/ml/binutils/2002-07/msg00717.html * aoutx.h (aout_link_check_ar_symbols): Remove default and handle bfd_link_common_skip_none in switch.
2018-01-12Fixes for "Ignore dynamic references on forced local symbols"Alan Modra5-37/+57
PowerPC64 has its own mark_dynamic_ref, which needs the same change as made by d664fd41e1 to the generic ELF version. Some other targets discard more than just .data, so allow for that too in expected ld messages. bfd/ PR ld/22649 * elf64-ppc.c (ppc64_elf_gc_mark_dynamic_ref): Ignore dynamic references on forced local symbols. ld/ PR ld/22649 * testsuite/ld-elf/pr22649.msg: Allow other messages. * testsuite/ld-elf/shared.exp: Check that --gc-sections is supported before running ld/22649 tests.
2018-01-12_bfd_mips_elf_final_link: Notify user about wrong .reginfo sizeVlad Ivanov2-1/+14
One of assertions in _bfd_mips_elf_final_link could be triggered by a combination of input files and a linker script. This happens when either the input doesn't contain .reginfo section or when this section is oversized. This patch replaces the assertion with a more useful error message. * elfxx-mips.c (_bfd_mips_elf_final_link): Notify user when .reginfo section has wrong size.
2018-01-12Add -z undefs option to the ELF linker.Nick Clifton4-2/+26
Currently we have no obvious way to revert the action of the "-z defs" command line option. The "--unresolved-symbols=ignore-in-object-files" does pretty much what is needed, but it is non-obvious and it also touches the setting for reporting unresolved symbol references from shared libraries. So I am proposing adding a "-z undefs" option to be the inverse of "-z defs". (I thought that "-z nodefs" might be confusing since it implies banning all definitions, rather than allowing them). In addition the description of the "-z defs" option in the linker documentation is misleading in one place, where it says: 'defs' Disallows undefined symbols in object files. Undefined symbols in shared libraries are still allowed. whereas later on it gets it right: '-z defs' Report unresolved symbol references from regular object files. This is done even if the linker is creating a non-symbolic shared library. The switch '--[no-]allow-shlib-undefined' controls the behaviour for reporting unresolved references found in shared libraries being linked in. * emultempl/elf32.em (_handle_option): Add support for "-z undefs" as the opposite of "-z defs". * ld.texinfo: Document the new option. Update the description of the -z defs option to make it clear that it does generate an error if an undefined symbol reference is found in an object file whilst creating a shared library. * NEWS: Document this new feature.
2018-01-11ld: Replace "-z textonly" with "-z separate-code"H.J. Lu5-4/+12
Although they aren't passed to linker, we should get it right. * testsuite/ld-elf/pr22393-2a.rd: Replace "-z textonly" with "-z separate-code". * testsuite/ld-elf/pr22393-2b.rd: Likewise. * testsuite/ld-x86-64/pr22393-3a.rd: Likewise. * testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
2018-01-11x86-64: Add tests for -z separate-code -z max-page-size=0x1000H.J. Lu6-0/+113
PR ld/22393 * testsuite/ld-x86-64/pr22393-3a.c: New file. * testsuite/ld-x86-64/pr22393-3a.rd: Likewise. * testsuite/ld-x86-64/pr22393-3b.c: Likewise. * testsuite/ld-x86-64/pr22393-3b.rd: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run tests for -z separate-code -z max-page-size=0x1000.
2018-01-11ld: Add tests for -z separate-code and -z noseparate-codeH.J. Lu14-1/+196
Verify that -z separate-code works and -z noseparate-code doesn't disable -z relro. PR ld/22393 * testsuite/ld-elf/pr16322.d: Add -z noseparate-code. * testsuite/ld-elf/pr22393-1.s: New file. * testsuite/ld-elf/pr22393-1a.d: Likewise. * testsuite/ld-elf/pr22393-1b.d: Likewise. * testsuite/ld-elf/pr22393-1c.d: Likewise. * testsuite/ld-elf/pr22393-1d.d: Likewise. * testsuite/ld-elf/pr22393-1e.d: Likewise. * testsuite/ld-elf/pr22393-1f.d: Likewise. * testsuite/ld-elf/pr22393-2a.c: Likewise. * testsuite/ld-elf/pr22393-2a.rd: Likewise. * testsuite/ld-elf/pr22393-2b.c: Likewise. * testsuite/ld-elf/pr22393-2b.rd: Likewise. * testsuite/ld-elf/shared.exp: Run tests for -z separate-code.
2018-01-11ld: Create a new LOAD segment for separate code segmentH.J. Lu2-7/+34
When generating separate code LOAD segment, create a new LOAD segment if the previous section contains text and the current section doesn't or vice versa: Elf file type is DYN (Shared object file) Entry point 0x200020 There are 7 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x00000000 0x00000000 0x00200 0x00200 R 0x200000 LOAD 0x200000 0x00200000 0x00200000 0x00036 0x00036 R E 0x200000 LOAD 0x400000 0x00400000 0x00400000 0x00064 0x00064 R 0x200000 LOAD 0x400f80 0x00600f80 0x00600f80 0x000a0 0x000a0 RW 0x200000 DYNAMIC 0x400f80 0x00600f80 0x00600f80 0x00080 0x00080 RW 0x4 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10 GNU_RELRO 0x400f80 0x00600f80 0x00600f80 0x00080 0x00080 R 0x1 Section to Segment mapping: Segment Sections... 00 .hash .gnu.hash .dynsym .dynstr .rela.plt 01 .plt .text 02 .rodata .eh_frame 03 .dynamic .got.plt 04 .dynamic 05 06 .dynamic to prevent fetching or executing data in code pages as instructions. Also don't put a writable section in a read-only segment if there is a RELRO segment. Since code segment is aligned and padded to the maximum page size on disk, the minimum file size is bigger than the maximum page size which is 2MB (0x200000): -rwxr-xr-x 1 hjl hjl 4201932 Jan 10 10:41 libfoo.so "-z max-page-size=0x1000" can be used to reduce the maximum page size to 4KB (0x1000): -rwxr-xr-x 1 hjl hjl 15820 Jan 10 10:44 libfoo.so PR ld/22393 * elf.c (_bfd_elf_map_sections_to_segments): When generating separate code and read-only data LOAD segments, create a new LOAD segment if the previous section contains text and the current section doesn't or vice versa. Don't put a writable section in a read-only segment if there is a RELRO segment.
2018-01-11ld: Add "-z separate-code" option to ELF linkerH.J. Lu9-20/+218
The new "-z separate-code" option will generate separate code LOAD segment which must be in wholly disjoint pages from any other data. include/ PR ld/22393 * bfdlink.h (bfd_link_info): Add separate_code. ld/ PR ld/22393 * NEWS: Mention "-z separate-code". * emultempl/elf32.em (gld${EMULATION_NAME}_get_script): Get builtin linker scripts and return linker scripts from disk for "-z separate-code". (gld${EMULATION_NAME}_handle_option): Handle "-z separate-code" and "-z noseparate-code". * genscripts.sh: Generate linker scripts for "-z separate-code". (LD_FLAG): Set to *textonly for "-z separate-code". * ld.texinfo: Document "-z separate-code". * lexsup.c (elf_shlib_list_options): Add linker help messsages for "-z separate-code" and "-z noseparate-code". * scripttempl/elf.sc (SEPARATE_TEXT): New (TEXT_SEGMENT_ALIGN): Likewise. Use ${TEXT_SEGMENT_ALIGN} to align and pad text segment to ${MAXPAGESIZE}.
2018-01-11gdb_compile_shlib: Only consider shlib= options when building executablesSimon Marchi2-2/+8
Trying to use gdb_compile_shlib with the shlib= option to build a shared library that depends on another shared library does not work as of today. See: https://sourceware.org/ml/gdb-patches/2017-10/msg00733.html The problem is that building the lib is done in two steps, compilation (.c -> .o) and linking (.o -> .so) and the shlib= options are passed to both steps. When compiling the object file (.o), it results in gcc complaining: gcc: warning: .../solib-vanish-lib2.so: linker input file unused because linking not done The first solution I came up with was to filter the options inside gdb_compile_shlib to remove the shlib= options from the options we pass when compiling the .o file. I then thought it would be simpler to ignore the shlib= options in gdb_compile when not building an executable (the executable category includes the shared libraries). For other compilation types (object file, preprocess and generate assembly), it doesn't make sense to add shared libraries to the source file list. Regtested on the buildbot. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_compile): Ignore shlib= and shlib_load options when not creating an executable.
2018-01-12Automatic date update in version.inGDB Administrator1-1/+1
2018-01-11Ignore dynamic references on forced local symbolsH.J. Lu8-1/+81
We should ignore dynamic references on forced local symbols during garbage collection since they can never be referenced dynamically. bfd/ PR ld/22649 * elflink.c (bfd_elf_gc_mark_dynamic_ref_symbol): Ignore dynamic references on forced local symbols. ld/ PR ld/22649 * testsuite/ld-elf/pr22649-1.s: New file. * testsuite/ld-elf/pr22649-2a.s: Likewise. * testsuite/ld-elf/pr22649-2b.s: Likewise. * testsuite/ld-elf/pr22649.msg: Likewise. * testsuite/ld-elf/shared.exp: Run ld/22649 tests.
2018-01-11gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)Pedro Alves2-3/+37
As Maciej reported at <https://sourceware.org/ml/gdb-patches/2017-12/msg00212.html>, this commit: commit d930703d68ae160ddfe8ebe5fdcf416fb6090e1e Date: Thu Nov 16 18:44:43 2017 +0000 Subject: Don't ever Quit out of resume caused regressions on software single-set targets, specifically: FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw on: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: step in ro region (cannot insert hw break) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw off: single-step breakpoint is not left behind FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted on: auto-hw on: single-step breakpoint is not left behind and indeed detailed logs indicate a breakpoint is left lingering, e.g.: (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break) maint info breakpoints 0 Num Type Disp Enb Address What 0 sw single-step keep y 0x00400774 in main at [...]/gdb/testsuite/gdb.base/breakpoint-in-ro-region.c:24 inf 1 thread 1 stop only in thread 1 (gdb) FAIL: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind vs: (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: step in ro region (cannot insert sw break) maint info breakpoints 0 No breakpoint or watchpoint matching '0'. (gdb) PASS: gdb.base/breakpoint-in-ro-region.exp: always-inserted off: auto-hw off: single-step breakpoint is not left behind as at commit d930703d68ae^. Before commit d930703d68ae, we had a cleanup installed in 'resume' that would delete single-step breakpoints on error: /* Resuming. */ /* Things to clean up if we QUIT out of resume (). */ static void resume_cleanups (void *ignore) { if (!ptid_equal (inferior_ptid, null_ptid)) delete_single_step_breakpoints (inferior_thread ()); normal_stop (); } That whole function was removed by d930703d68ae mainly to eliminate the normal_stop call: ~~~~ Note that the exception called from within resume ends up calling normal_stop via resume_cleanups. That's very borked though, because normal_stop is going to re-handle whatever was the last reported event, possibly even re-running a hook stop... ~~~~ But as the regression shows, removing resume_cleanups completely went a bit too far, as the delete_single_step_breakpoints call is still necessary. So fix the regression by reinstating the delete_single_step_breakpoints call on error. However, since we're trying to eliminate cleanups, restore it in a different form (using TRY/CATCH). Tested on x86-64 GNU/Linux both top of master and on top of a series that implements software single-step on x86. gdb/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR gdb/22583 * infrun.c (resume): Rename to ... (resume_1): ... this. (resume): Reimplement as wrapper around resume_1.
2018-01-11ld: Keep PREINIT_ARRAY/INIT_ARRAY/FINI_ARRAY sections for -r --gc-sectionsH.J. Lu6-7/+64
We must keep all PREINIT_ARRAY, INIT_ARRAY as well as FINI_ARRAY sections for ld -r --gc-sections. bfd/ PR ld/22677 * elflink.c (bfd_elf_gc_sections): Keep all PREINIT_ARRAY, INIT_ARRAY as well as FINI_ARRAY sections for ld -r --gc-sections. ld/ PR ld/22677 * scripttempl/elf.sc (PREINIT_ARRAY): New. Don't add .preinit_array for ld -r. * testsuite/ld-elf/pr22677.d: New file. * testsuite/ld-elf/pr22677.s: Likewise.
2018-01-11ld: Remove unused expression stateAndrew Burgess3-6/+12
Previous commit removed all uses of the defsym field within the linker expression union. This commit cleans up the now redundant state. ld/ChangeLog: * ldexp.h (union etree_union): Remove defsym field. * ldexp.c (exp_assop): Remove defsym parameter, and use of defsym parameter. (exp_assign): Remove passing of defsym parameter. (exp_defsym): Likewise. (exp_provide): Likewise.
2018-01-11ld: Fix issue where PROVIDE overrides defined symbolAndrew Burgess9-42/+121
In a linker script, a sequence like this: foo = ADDR (.some_section); bar = foo; PROVIDE (foo = 0); will result in 'bar = ADDR (.some_section)' and 'foo = 0', which seems like incorrect behaviour, foo is clearly defined elsewhere, and so the PROVIDE should not trigger. The problem is that an expression like this: foo = ADDR (.some_section); can't be evaluated until a late phase of the linker, due to the need for the section '.some_section' to have been placed, then the PROVIDE was being marked as being used during an earlier phase. At the end of the link, both lines: foo = ADDR (.some_section); PROVIDE (foo = 0); are active, and this causes the final value of 'foo' to be 0. The solution proposed in this commit is that, during earlier phases of the linker, when we see the expression 'foo = ADDR (.some_section);', instead of ignoring the expression, we create a "fake" definition of 'foo'. The existence of this "fake" definition prevents the PROVIDE from being marked used, and during the final phase the real definition of 'foo' will replace the "fake" definition. The new test provide-6 covers the exact case described above. The provide-7 test is similar to the above, but using constant expressions, this was never broken, but is added here to increase coverage. The provide-8 case also didn't fail before this commit, but I did manage to break this case during development of this patch. This case was only covered by a mmix test before, so I've added this here to increase coverage. ld/ChangeLog: * ldexp.c (exp_fold_tree_1): Rework condition underwhich provide nodes are ignored in the tree walk, and move the location at which we change provide nodes into provided nodes. (exp_init_os): Add etree_provided. * testsuite/ld-scripts/provide-6.d: New file. * testsuite/ld-scripts/provide-6.t: New file. * testsuite/ld-scripts/provide-7.d: New file. * testsuite/ld-scripts/provide-7.t: New file. * testsuite/ld-scripts/provide-8.d: New file. * testsuite/ld-scripts/provide-8.t: New file.
2018-01-11ld: Find and run some tests using a wildcard patternAndrew Burgess7-8/+21
Find the ld-script/provide-*.d tests using a wildcard, then run them in a loop. This will make it easier to add more tests in the future. Some associated clean up is required. ld/ChangeLog: * testsuite/ld-scripts/provide-3.d: Add xfail directive. * testsuite/ld-scripts/provide-4.d: Use new map file name. * testsuite/ld-scripts/provide-5.d: Use new map file name. * testsuite/ld-scripts/provide-4-map.d: Renamed to... * testsuite/ld-scripts/provide-4.map: ...this. * testsuite/ld-scripts/provide-5-map.d: Renamed to... * testsuite/ld-scripts/provide-5.map: ...this. * testsuite/ld-scripts/provide.exp: Move xfail into provide-3.d file, and run tests in a loop.
2018-01-11ld: In map file use '=' in PROVIDE statementsAndrew Burgess4-8/+15
Currently when recording a PROVIDE statement in a linker map file we display something like: PROVIDE (SYMBOL, VALUE) However, in a linker script we write these statements like this: PROVIDE (SYMBOL = VALUE); This commit changes the output in the map file to be closer to linker script format, the map file now contains: PROVIDE (SYMBOL = VALUE) The ';' is still missing from the end, but map files are not intended to be valid linker script input, so adding the ';' just seems like clutter. ld/ChangeLog: * ldexp.c (exp_print_tree): Use '=' instead of ',' when printing PROVIDE statements. * testsuite/ld-scripts/provide-4.map: Update expected output. * testsuite/ld-scripts/provide-5.map: Likewise.
2018-01-11Fix the order of SHLIB_RODATA_ADDR in elf.scH.J. Lu2-1/+6
elf.sc has if test -n "${RODATA_ADDR}"; then RODATA_ADDR="\ SEGMENT_START(\"rodata-segment\", ${RODATA_ADDR}) + SIZEOF_HEADERS" else RODATA_ADDR="ALIGN(${SEGMENT_SIZE}) + (. & (${MAXPAGESIZE} - 1))" ^^^^^^^^^^ Set RODATA_ADDR RODATA_ADDR="SEGMENT_START(\"rodata-segment\", ${RODATA_ADDR})" ^^^^^^^^^^ Set RODATA_ADDR with ${RODATA_ADDR} fi if test -n "${SHLIB_RODATA_ADDR}"; then SHLIB_RODATA_ADDR="\ SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR}) + SIZEOF_HEADERS" else SHLIB_RODATA_ADDR="SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR})" ^^^^^^^^^^ Set SHLIB_RODATA_ADDR SHLIB_RODATA_ADDR="ALIGN(${SEGMENT_SIZE}) + (. & (${MAXPAGESIZE} - 1))" ^^^^^^^^^^ Override SHLIB_RODATA_ADDR fi The order should be: if test -n "${SHLIB_RODATA_ADDR}"; then SHLIB_RODATA_ADDR="\ SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR}) + SIZEOF_HEADERS" else SHLIB_RODATA_ADDR="ALIGN(${SEGMENT_SIZE}) + (. & (${MAXPAGESIZE} - 1))" SHLIB_RODATA_ADDR="SEGMENT_START(\"rodata-segment\", ${SHLIB_RODATA_ADDR})" fi PR ld/22696 * scripttempl/elf.sc: Fix the order of SHLIB_RODATA_ADDR.
2018-01-11Fix gdb.texinfo for old makeinfoSzabolcs Nagy2-1/+5
With old makeinfo (version 4.13) the changes introduced in commit 2d97a5d9d33aea87c3bd02fd1fa417f5d4e1fa05 Author: John Baldwin <jhb@FreeBSD.org> Document support for 'info proc' on FreeBSD. fail to build. gdb/doc/ChangeLog: * gdb.texinfo (pwd): Fix whitespace.
2018-01-11Fix backwards compatibility with old GDBservers (PR remote/22597)Pedro Alves5-1/+115
At <https://sourceware.org/ml/gdb-patches/2017-12/msg00285.html>, Maciej reported that commit: commit 5cd63fda035d4ba949e6478406162c4673b3c9ef Date: Wed Oct 4 18:21:10 2017 +0100 Subject: Fix "Remote 'g' packet reply is too long" problems with multiple inferiors made GDB stop working with older stubs. Any attempt to continue execution after the initial connection fails with: [...] Process .../gdb/testsuite/outputs/gdb.base/advance/advance created; pid = 2670 Listening on port 2346 target remote [...]:2346 Remote debugging using [...]:2346 Reading symbols from .../lib64/ld.so.1...done. [Switching to Thread <main>] (gdb) continue Cannot execute this command without a live selected thread. (gdb) The problem is: (gdb) c Cannot execute this command without a live selected thread. (gdb) info threads Id Target Id Frame 1 Thread 14917 0x00007f341cd98ed0 in _start () from /lib64/ld-linux-x86-64.so.2 The current thread <Thread ID 2> has terminated. See `help thread'. ^^^^^^^^^^^ (gdb) Note, thread _2_. There's really only one thread in the inferior (it's still at the entry point), but still GDB added a bogus second thread. The reason GDB started adding a second thread after 5cd63fda035d is this hunk: + if (event->ptid == null_ptid) + { + const char *thr = strstr (p1 + 1, ";thread:"); + if (thr != NULL) + event->ptid = read_ptid (thr + strlen (";thread:"), + NULL); + else + event->ptid = magic_null_ptid; + } Note the else branch that falls back to magic_null_ptid. We reach that when we process the initial stop reply sent back in response to the the "?" (status) packet early in the connection setup: Sending packet: $?#3f...Ack Packet received: T0506:0000000000000000;07:40a510f4fd7f0000;10:d0fe1201577f0000; And note that that response does not include a ";thread:XXX" part. This stop reply is processed after listing threads with qfThreadInfo / qsThreadInfo : Sending packet: $qfThreadInfo#bb...Ack Packet received: m3915 Sending packet: $qsThreadInfo#c8...Ack Packet received: l meaning, when we process that stop reply, we treat the event as coming from a thread with ptid == magic_null_ptid, which is not yet in the thread list, so we add it then: (top-gdb) p ptid $1 = {m_pid = 42000, m_lwp = -1, m_tid = 1} (top-gdb) bt #0 0x0000000000840a8c in add_thread_silent(ptid_t) (ptid=...) at src/gdb/thread.c:269 #1 0x00000000007ad61d in remote_add_thread(ptid_t, int, int) (ptid=..., running=0, executing=0) at src/gdb/remote.c:1838 #2 0x00000000007ad8de in remote_notice_new_inferior(ptid_t, int) (currthread=..., executing=0) at src/gdb/remote.c:1921 #3 0x00000000007b758b in process_stop_reply(stop_reply*, target_waitstatus*) (stop_reply=0x1158860, status=0x7fffffffcc00) at src/gdb/remote.c:7217 #4 0x00000000007b7a38 in remote_wait_as(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7380 #5 0x00000000007b7cd1 in remote_wait(target_ops*, ptid_t, target_waitstatus*, int) (ops=0x102fac0 <remote_ops>, ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/remote.c:7446 #6 0x000000000081587b in delegate_wait(target_ops*, ptid_t, target_waitstatus*, int) (self=0x102fac0 <remote_ops>, arg1=..., arg2=0x7fffffffcc00, arg3=0) at src/gdb/target-delegates.c:138 #7 0x0000000000827d77 in target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/target.c:2179 #8 0x0000000000715fda in do_target_wait(ptid_t, target_waitstatus*, int) (ptid=..., status=0x7fffffffcc00, options=0) at src/gdb/infrun.c:3589 #9 0x0000000000716351 in wait_for_inferior() () at src/gdb/infrun.c:3707 #10 0x0000000000715435 in start_remote(int) (from_tty=1) at src/gdb/infrun.c:3212 things go downhill from this. We don't see the problem with current master gdbserver, because that version always sends the ";thread:" part in the initial stop reply: Sending packet: $?#3f...Packet received: T0506:0000000000000000;07:a0d4ffffff7f0000;10:d05eddf7ff7f0000;thread:p3cea.3cea;core:3; Years ago I had added a "--disable-packet=" command line option to gdbserver which comes in handy for testing this, since the existing "--disable-packet=Tthread" precisely makes gdbserver not send that ";thread:" part in stop replies. The testcase added by this commit emulates old gdbserver making use of that. I've compared a testrun at 5cd63fda035d^ (before regression) with 'current master+patch', against old gdbserver at f8b73d13b7ca^. I hacked out --once, and "monitor exit" to be able to test. The results are a bit too unstable to tell accurately, but it looked like there were no regressions. Maciej confirmed this worked for him as well. No regressions on master (against master gdbserver). gdb/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR remote/22597 * remote.c (remote_parse_stop_reply): Default to the last-set general thread instead of to 'magic_null_ptid'. gdb/testsuite/ChangeLog: 2018-01-11 Pedro Alves <palves@redhat.com> PR remote/22597 * gdb.server/stop-reply-no-thread.c: New file. * gdb.server/stop-reply-no-thread.exp: New file.
2018-01-11Remove VL variants for 4FMAPS and 4VNNIW insns.Igor Tsimbalist23-1202/+41
AVX512_4FMAPS and AVX512_4VNNIW insns are marked as having AVX512VL variants. That is wrong as SDM doesn't define such instructions. The patch removes these VL variants. gas/ * testsuite/gas/i386/avx512_4fmaps-warn.l: Change xmm to zmm. * testsuite/gas/i386/avx512_4fmaps-warn.s: Likewise. * testsuite/gas/i386/avx512_4fmaps_vl-intel.d: Delete. * testsuite/gas/i386/avx512_4fmaps_vl-warn.l: Likewise. * testsuite/gas/i386/avx512_4fmaps_vl-warn.s: Likewise. * testsuite/gas/i386/avx512_4fmaps_vl.d: Likewise. * testsuite/gas/i386/avx512_4fmaps_vl.s: Likewise. * testsuite/gas/i386/avx512_4vnniw_vl-intel.d: Likewise. * testsuite/gas/i386/avx512_4vnniw_vl.d: Likewise. * testsuite/gas/i386/avx512_4vnniw_vl.s: Likewise. * testsuite/gas/i386/i386.exp: Delete _vl tests for 4fmaps an 4vnniw tests. * testsuite/gas/i386/x86-64-avx512_4fmaps_vl-intel.d: Delete. * testsuite/gas/i386/x86-64-avx512_4fmaps_vl-warn.l: Likewise. * testsuite/gas/i386/x86-64-avx512_4fmaps_vl-warn.s: Likewise. * testsuite/gas/i386/x86-64-avx512_4fmaps_vl.d: Likewise. * testsuite/gas/i386/x86-64-avx512_4fmaps_vl.s: Likewise. * testsuite/gas/i386/x86-64-avx512_4vnniw_vl-intel.d: Likewise. * testsuite/gas/i386/x86-64-avx512_4vnniw_vl.d: Likewise. * testsuite/gas/i386/x86-64-avx512_4vnniw_vl.s: Likewise. opcodes/ * i386-opc.tbl: Remove VL variants for 4FMAPS and 4VNNIW insns. * i386-tbl.h: Regenerate.
2018-01-11Automatic date update in version.inGDB Administrator1-1/+1
2018-01-11gas tc-arm.c warning fixAlan Modra2-1/+6
* config/tc-arm.c (aeabi_set_public_attributes): Avoid false positive "‘profile’ may be used uninitialized".
2018-01-10language_get_symbol_name_matcher -> get_symbol_name_matcherPedro Alves9-15/+22
Rename language_get_symbol_name_matcher -> get_symbol_name_matcher, since the function is no longer a straight "language method". gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> * language.h (language_get_symbol_name_matcher): Rename ... (get_symbol_name_matcher): ... this. * language.c (language_get_symbol_name_matcher): Ditto. * dictionary.c, linespec.c, minsyms.c, psymtab.c, symtab.c: All callers adjusted.
2018-01-10Ada: make verbatim matcher override other language matchers (PR gdb/22670)Pedro Alves9-21/+131
A previous patch fixed verbatim matching in the lookup at the minimal symbol level, but we should also be finding that same symbol through the partial/full symtab search. For example, this is what happens if we use "print" instead of "break": (gdb) p <MixedCaseFunc> $1 = {<text variable, no debug info>} 0x4024dc <MixedCaseFunc> Before the C++ wildmatching series, GDB knows that MixedCaseFunc is a function without parameters, and the expression above means calling it. If you try it before having started the inferior, you'd get the following (expected) error: (gdb) print <MixedCaseFunc> You can't do that without a process to debug. The main idea behind making the name matcher be determined by the symbol's language is so that C++ (etc.) wildmatching in linespecs works even if the current language is not C++, as e.g., when you step through C or assembly code. Ada's verbatim matching syntax however ("<...>") isn't quite the same. It is more a property of the current language than of a particular symbol's language. We want to support this syntax when debugging an Ada program, but it's reason of existence is to find non-Ada symbols. This suggests going back to enabling it depending on current language instead of language of the symbol being matched. I'm not entirely happy with the "current_language" reference (though I think that it's harmless). I think we could try storing the current language in the lookup_name_info object, and then convert a bunch of functions more to pass around lookup_name_info objects instead of "const char *" names. I.e., build the lookup_name_info higher up. I'm not sure about that, I'll have to think more about it. Maybe something different will be better. Meanwhile, this gets us going. I've extended the testcase to also exercise a no-debug-info function, for extra coverage of the minsyms-only paths. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * dwarf2read.c (gdb_index_symbol_name_matcher::gdb_index_symbol_name_matcher): Adjust to use language_get_symbol_name_matcher instead of language_defn::la_get_symbol_name_matcher. * language.c (language_get_symbol_name_matcher): If in Ada mode and the lookup name is a verbatim match, return Ada's matcher. * language.h (language_get_symbol_name_matcher): Adjust comment. (ada_lookup_name_info::verbatim_p):: New method. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Add intro comment. Test printing C functions too. Test setting breakpoints and printing C functions with no debug info too. * gdb.ada/bp_c_mixed_case/qux.c: New file.
2018-01-10Fix gdb.ada/complete.exp's "complete break ada" test (PR gdb/22670)Pedro Alves5-18/+35
This patch fixes the regression covered by the test added by: commit 344420da6beac1e0b2f7964e7101f8dcdb509b0d Date: Thu Jan 4 03:30:37 2018 -0500 Subject: Add "complete break ada" test to gdb.ada/complete.exp The regression had been introduced by: commit b5ec771e60c1a0863e51eb491c85c674097e9e13 Date: Wed Nov 8 14:22:32 2017 +0000 Subject: Introduce lookup_name_info and generalize Ada's FULL/WILD name matching The gist of it is that linespec completion in Ada mode is generating additional matches that should not appear in the match list (internally generated symbols, or symbols that should be enclosed between "<...>"). These extraneous entries have uppercase characters, such as: break ada__stringsS break ada__strings__R11s [etc] These matches come from minimal symbols. The problem is that Ada minsyms end up with no language set (language_auto), and thus we end up using the generic symbol name matcher for those instead of Ada's. We already had a special case for in compare_symbol_name to handle this, but it was limited to expressions, while the case at hand is completing a linespec. Fix this by applying the special case to linespec completion as well. I.e., remove the EXPRESSION check from compare_symbol_name. That alone turns out to not be sufficient still -- GDB would still show a couple entries that shouldn't be there: ~~ break ada__exceptions__exception_data__append_info_exception_name__2Xn break ada__exceptions__exception_data__exception_name_length__2Xn ~~ The reason is that these minimal symbols end up with their language set to language_cplus / C++, because those encoded names manage to demangle successfully as C++ symbols (using an old C++ mangling scheme): $ echo ada__exceptions__exception_data__append_info_exception_name__2Xn | c++filt Xn::ada__exceptions__exception_data__append_info_exception_name(void) It's unfortunate that Ada's encoding scheme doesn't start with some unique prefix like "_Z" in the C++ Itanium ABI mangling scheme. For now, paper over that by treating C++ minsyms as Ada minsyms. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * ada-lang.c (ada_collect_symbol_completion_matches): If the minsym's language is language_auto or language_cplus, pass down language_ada instead. * symtab.c (compare_symbol_name): Don't frob symbol language here. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/complete.exp ("complete break ada"): Replace kfail with a fail.
2018-01-10Fix gdb.ada/bp_c_mixed_case.exp (PR gdb/22670)Pedro Alves4-4/+32
The problem here is that we are using the user-provided lookup name literally for name comparisons. I.e., "<MixedCase>" with the "<>"s included. This commit fixes the minsym lookup case. psymbol/symbol lookup will be fixed in a follow up. In the minsym case, we're using using the user-provided lookup name literally for linkage name comparisons. That obviously can't work since the "<>" are not really part of the linkage name. The original idea was that we'd use the symbol's language to select the right symbol name matching algorithm, but that doesn't work for Ada because it's not really possible to unambiguously tell from the linkage name alone whether we're dealing with Ada symbols, so Ada minsyms end up with no language set, or sometimes C++ set. So fix this by treating Ada mode specially when determining the linkage name to match against. gdb/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * minsyms.c (linkage_name_str): New function. (iterate_over_minimal_symbols): Use it. gdb/testsuite/ChangeLog: 2018-01-10 Pedro Alves <palves@redhat.com> PR gdb/22670 * gdb.ada/bp_c_mixed_case.exp: Remove setup_kfail calls.
generated by cgit v1.1 at 2024-12-13 16:50:46 +0000