summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Avoid undefined behavior in Guile exception handlingTom Tromey2019-04-2516-82/+235
| | | | | | | | | | | | | | | | | | | | | | | | | The Guile code will longjmp (via scm_throw) when an object requiring destruction is on the stack. This is undefined behavior. This changes this code to run any destructors in inner scopes, and to pass a POD to gdbscm_throw_gdb_exception. gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> * guile/scm-exception.c (gdbscm_scm_from_gdb_exception) (gdbscm_throw_gdb_exception): Take a gdbscm_gdb_exception. * guile/scm-block.c, guile/scm-breakpoint.c, guile/scm-cmd.c, guile/scm-disasm.c, guile/scm-frame.c, guile/scm-lazy-string.c, guile/scm-math.c, guile/scm-param.c, guile/scm-ports.c, guile/scm-symbol.c, guile/scm-symtab.c, guile/scm-type.c, guile/scm-value.c: Use unpack. * guile/guile-internal.h (gdbscm_scm_from_gdb_exception): Take a gdbscm_gdb_exception. (gdbscm_throw_gdb_exception): Likewise. (struct gdbscm_gdb_exception): New. (unpack): New function. (gdbscm_wrap): Use unpack.
* Make SJLJ exceptions more efficientTom Tromey2019-04-254-6/+19
| | | | | | | | | | | | | | | | | | | This changes the SJLJ exception handling code to be a bit more efficient, by using rvalue references and move assignment when possible. Tested by the buildbot. gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept) (gdb_rl_callback_handler): Use std::move. * common/common-exceptions.h (struct gdb_exception): Add move assignment operator. (throw_exception_sjlj): Change "exception" to const reference. * common/common-exceptions.c (exceptions_state_mc_catch): Update. (throw_exception_sjlj): Change "exception" to const reference.
* Remove exception_noneTom Tromey2019-04-2519-29/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that gdb_exception has a constructor, there's no need for exception_none. This patch removes it. gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> * xml-support.c (gdb_xml_parser::gdb_xml_parser): Update. * python/py-value.c (valpy_getitem, valpy_nonzero): Update. * python/py-inferior.c (infpy_write_memory, infpy_search_memory): Update. * python/py-breakpoint.c (bppy_set_condition, bppy_set_commands): Update. * mi/mi-interp.c (mi_interp::exec): Update. * linespec.c (parse_linespec): Update. * infcall.c (run_inferior_call): Update. * guile/scm-value.c (gdbscm_value_to_lazy_string): Update. * guile/scm-symbol.c (gdbscm_lookup_symbol) (gdbscm_lookup_global_symbol): Update. * guile/scm-param.c (gdbscm_parameter_value): Update. * guile/scm-frame.c (gdbscm_frame_read_register) (gdbscm_frame_read_var): Update. * guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Update. * exec.c (try_open_exec_file): Update. * event-top.c (gdb_rl_callback_read_char_wrapper_noexcept) (gdb_rl_callback_handler): Update. * common/common-exceptions.h (exception_none): Don't declare. * common/common-exceptions.c (exception_none): Don't define. (struct catcher) <exception>: Update. * cli/cli-interp.c (safe_execute_command): Update. * breakpoint.c (insert_bp_location, location_to_sals): Update.
* [PATCH] Support for DW_FORM_strx tagAli Tamur2019-04-253-2/+24
| | | | | DW_FORM_strx is the new name of DW_FORM_GNU_str_index in the Dwarf 5 standard. This is a small step towards supporting Dwarf 5 in gdb.
* ChangeLog entries for the previous commit.Sergio Durigan Junior2019-04-252-0/+15
| | | | | | I forgot to include the ChangeLog entries in the commit 57e5e645010430b3d73f8c6a757d09f48dc8f8d5 ("Implement dump of mappings with ELF headers by gcore").
* Implement dump of mappings with ELF headers by gcoreSergio Durigan Junior2019-04-253-13/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch has a long story, but it all started back in 2015, with commit df8411da087dc05481926f4c4a82deabc5bc3859 ("Implement support for checking /proc/PID/coredump_filter"). The purpose of that commit was to bring GDB's corefile generation closer to what the Linux kernel does. However, back then, I did not implement the full support for the dumping of memory mappings containing ELF headers (like mappings of DSOs or executables). These mappings were being dumped most of time, though, because the default value of /proc/PID/coredump_filter is 0x33, which would cause anonymous private mappings (DSOs/executable code mappings have this type) to be dumped. Well, until something happened on binutils... A while ago, I noticed something strange was happening with one of our local testcases on Fedora GDB: it was failing due to some strange build-id problem. On Fedora GDB, we (unfortunately) carry a bunch of "local" patches, and some of these patches actually extend upstream's build-id support in order to generate more useful information for the user of a Fedora system (for example, when the user loads a corefile into GDB, we detect whether the executable that generated that corefile is present, and if it's not we issue a warning suggesting that it should be installed, while also providing the build-id of the executable). A while ago, Fedora GDB stopped printing those warnings. I wanted to investigate this right away, and spent some time trying to determine what was going on, but other things happened and I got sidetracked. Meanwhile, the bug started to be noticed by some of our users, and its priority started changing. Then, someone on IRC also mentioned the problem, and when I tried helping him, I noticed he wasn't running Fedora. Hm... So maybe the bug was *also* present upstream. After "some" time investigating, and with a lot of help from Keith and others, I was finally able to determine that yes, the bug is also present upstream, and that even though it started with a change in ld, it is indeed a GDB issue. So, as I said, the problem started with binutils, more specifically after the following commit was pushed: commit f6aec96dce1ddbd8961a3aa8a2925db2021719bb Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Feb 27 11:34:20 2018 -0800 ld: Add --enable-separate-code This commit makes ld use "-z separate-code" by default on x86-64 machines. What this means is that code pages and data pages are now separated in the binary, which is confusing GDB when it tries to decide what to dump. BTW, Fedora 28 binutils doesn't have this code, which means that Fedora 28 GDB doesn't have the problem. From Fedora 29 on, binutils was rebased and incorporated the commit above, which started causing Fedora GDB to fail. Anyway, the first thing I tried was to pass "-z max-page-size" and specify a bigger page size (I saw a patch that did this and was proposed to Linux, so I thought it might help). Obviously, this didn't work, because the real "problem" is that ld will always use separate pages for code and data. So I decided to look into how GDB dumped the pages, and that's where I found the real issue. What happens is that, because of "-z separate-code", the first two pages of the ELF binary are (from /proc/PID/smaps): 00400000-00401000 r--p 00000000 fc:01 799548 /file Size: 4 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 4 kB Private_Dirty: 0 kB Referenced: 4 kB Anonymous: 0 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 0 VmFlags: rd mr mw me dw sd 00401000-00402000 r-xp 00001000 fc:01 799548 /file Size: 4 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 0 VmFlags: rd ex mr mw me dw sd Whereas before, we had only one: 00400000-00401000 r-xp 00000000 fc:01 798593 /file Size: 4 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4 kB Pss: 4 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4 kB Referenced: 4 kB Anonymous: 4 kB LazyFree: 0 kB AnonHugePages: 0 kB ShmemPmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 0 kB THPeligible: 0 VmFlags: rd ex mr mw me dw sd Notice how we have "Anonymous" data mapped into the page. This will be important. So, the way GDB decides which pages it should dump has been revamped by my patch in 2015, and now it takes the contents of /proc/PID/coredump_filter into account. The default value for Linux is 0x33, which means: Dump anonymous private, anonymous shared, ELF headers and HugeTLB private pages. Or: filter_flags filterflags = (COREFILTER_ANON_PRIVATE | COREFILTER_ANON_SHARED | COREFILTER_ELF_HEADERS | COREFILTER_HUGETLB_PRIVATE); Now, it is important to keep in mind that GDB doesn't always have *all* of the necessary information to exactly determine the type of a page, so the whole algorithm is based on heuristics (you can take a look at linux-tdep.c:dump_mapping_p and linux-tdep.c:linux_find_memory_regions_full for more info). Before the patch to make ld use "-z separate-code", the (single) page containing data and code was being flagged as an anonymous (due to the non-zero "Anonymous:" field) private (due to the "r-xp" permission), which means that it was being dumped into the corefile. That's why it was working fine. Now, as you can imagine, when "-z separate-code" is used, the *data* page (which is where the ELF notes are, including the build-id one) now doesn't have any "Anonymous:" mapping, so the heuristic is flagging it as file-backed private, which is *not* dumped by default. The next question I had to answer was: how come a corefile generated by the Linux kernel was correct? Well, the answer is that GDB, unlike Linux, doesn't actually implement the COREFILTER_ELF_HEADERS support. On Linux, even though the data page is also treated as a file-backed private mapping, it is also checked to see if there are any ELF headers in the page, and then, because we *do* have ELF headers there, it is dumped. So, after more time trying to think of ways to fix this, I was able to implement an algorithm that reads the first few bytes of the memory mapping being processed, and checks to see if the ELF magic code is present. This is basically what Linux does as well, except that, if it finds the ELF magic code, it just dumps one page to the corefile, whereas GDB will dump the whole mapping. But I don't think that's a big issue, to be honest. It's also important to explain that we *only* perform the ELF magic code check if: - The algorithm has decided *not* to dump the mapping so far, and; - The mapping is private, and; - The mapping's offset is zero, and; - The user has requested us to dump mappings with ELF headers. IOW, we're not going to blindly check every mapping. As for the testcase, I struggled even more trying to write it. Since our build-id support on upstream GDB is not very extensive, it's not really possible to determine whether a corefile contains build-id information or not just by using GDB. So, after thinking a lot about the problem, I decided to rely on an external tool, eu-unstrip, in order to verify whether the dump was successful. I verified the test here on my machine, and everything seems to work as expected (i.e., it fails without the patch, and works with the patch applied). We are working hard to upstream our "local" Fedora GDB patches, and we intend to submit our build-id extension patches "soon", so hopefully we'll be able to use GDB itself to perform this verification. I built and regtested this on the BuildBot, and no problems were found. gdb/ChangeLog: 2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/11608 PR corefiles/18187 * linux-tdep.c (dump_mapping_p): Add new parameters ADDR and OFFSET. Verify if current mapping contains an ELF header. (linux_find_memory_regions_full): Adjust call to dump_mapping_p. gdb/testsuite/ChangeLog: 2019-04-25 Sergio Durigan Junior <sergiodj@redhat.com> PR corefiles/11608 PR corefiles/18187 * gdb.base/coredump-filter-build-id.exp: New file.
* testsuite: Add option to capture gdbserver debugAlan Hayward2019-04-256-2/+82
| | | | | | | | | | | | | | | | | | | | | | | | Add both board option and environment variable which enables gdbserver debug and sends it to the file gdbserver.debug, located in the output directory for the current test. Document this. Add support for the environment variable in the Makefile. The testsuite can be run with gdbserver debug enabled in the following way: make check GDBSERVER_DEBUG=all Disable tspeed.exp when debugging to prevent the log file filling many gigabytes then timing out. gdb/testsuite/ChangeLog: * Makefile.in: Pass through GDBSERVER_DEBUG. * README (Testsuite Parameters): Add GDBSERVER_DEBUG. (gdbserver,debug): Add board setting. * gdb.trace/tspeed.exp: Skip when debugging. * lib/gdb.exp (gdbserver_debug_enabled): New procedure. * lib/gdbserver-support.exp: Likewise
* LTO: Properly handle wrapper symbols in IRH.J. Lu2019-04-257-10/+89
| | | | | | | | | | | | | | | | | When a wrapper symbol, __wrap_FOO, is defined in IR, its resolution should be LDPR_PREVAILING_DEF, not PREVAILING_DEF_IRONLY, since LTO doesn't know that __wrap_FOO provides definition of FOO. And resolution of FOO should be LDPR_RESOLVED_IR since it is resolved by __wrap_FOO in IR. PR ld/24406 * ld.texi: Remove LTO warning from --wrap. * plugin.c (get_symbols): Update resolution for wrapper and wrapped symbols. * testsuite/ld-plugin/lto.exp: Run ld/24406 tests. * testsuite/ld-plugin/pr24406-1.c: New file. * testsuite/ld-plugin/pr24406-2a.c: Likewise. * testsuite/ld-plugin/pr24406-2b.c: Likewise.
* Detect invalid length field in debug frame FDE header.Sandra Loosemore2019-04-252-7/+17
| | | | | | | | | | | | | | | | | | | | | | | GDB was failing to catch cases where a corrupt ELF or core file contained an invalid length value in a Dwarf debug frame FDE header. It was checking for buffer overflow but not cases where the length was negative or caused pointer wrap-around. In addition to the additional validity check, this patch cleans up the multiple signed/unsigned conversions on the length field so that an unsigned representation is used consistently throughout. This patch fixes CVE-2017-9778 and PR gdb/21600. 2019-04-25 Sandra Loosemore <sandra@codesourcery.com> Kang Li <kanglictf@gmail.com> PR gdb/21600 * dwarf2-frame.c (read_initial_length): Be consistent about using unsigned representation of length. (decode_frame_entry_1): Likewise. Check for wraparound of end pointer as well as buffer overflow.
* [BFD, AArch64] Improve bti/pac plts.Sudakshina Das2019-04-2510-73/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch aims to improve the definitions of BTI and PAC based PLTs. The following changes are made: * PLT0 does not need PAC instructions since the PLTGOT[2] (and PLTGOT[1]) are readonly so they cannot be corrupted at runtime. Thus both PAC plt0 and BTI+PAC plt0 are removed and we can use basic plt0 and BTI plt0 instead, respectively. * We can remove the extra padding nops when we add the new bti instructions. BTI plt0 and BTI TLSDESC plt are updated. * For better performance PLTn could be padded to 24bytes. Both BTI pltn and PAC pltn are updated. *** bfd/ChangeLog *** 2019-04-25 Sudakshina Das <sudi.das@arm.com> * elfnn-aarch64.c (PLT_BTI_ENTRY_SIZE): Remove. (PLT_BTI_TLSDESC_ENTRY_SIZE): Remove. (PLT_PAC_ENTRY_SIZE, PLT_BTI_PAC_ENTRY_SIZE): Remove. (PLT_BTI_SMALL_ENTRY_SIZE, PLT_PAC_SMALL_ENTRY_SIZE): Update. (elfNN_aarch64_small_plt0_pac_entry): Remove. (elfNN_aarch64_small_plt0_bti_pac_entry): Remove. (elfNN_aarch64_small_plt0_bti_entry): Update. (elfNN_aarch64_small_plt_bti_entry): Update. (elfNN_aarch64_small_plt_pac_entry): Update. (elfNN_aarch64_tlsdesc_small_plt_bti_entry): Update. (setup_plt_values): Setup new entries. (elfNN_aarch64_finish_dynamic_sections): Remove size change. (elfNN_aarch64_plt_sym_val): Likewise. *** ld/ChangeLog *** 2019-04-25 Sudakshina Das <sudi.das@arm.com> * testsuite/ld-aarch64/bti-pac-plt-1.d: Update. * testsuite/ld-aarch64/bti-pac-plt-2.d: Update. * testsuite/ld-aarch64/bti-plt-1.d: Update. * testsuite/ld-aarch64/bti-plt-3.d: Update. * testsuite/ld-aarch64/bti-plt-5.d: Update. * testsuite/ld-aarch64/pac-plt-1.d: Update. * testsuite/ld-aarch64/pac-plt-2.d: Update.
* MIPS/include: opcode/mips.h: Update stale comment for CODE20 operandMaciej W. Rozycki2019-04-252-2/+6
| | | | | | | | | | | | Complement commit 1586d91e32ea ("/ 0 should send SIGFPE not SIGTRAP..."), <https://sourceware.org/ml/binutils/2004-07/msg00260.html>, and update a stale comment referring the 20-bit code field of the BREAK and SDBBP instructions, by making it explicit that where permitted by choosing the MIPS32 or a later ISA the whole field can now be set with a single operand for the SDBBP instruction only. include/ * opcode/mips.h: Update comment for MIPS32 CODE20 operand.
* Automatic date update in version.inGDB Administrator2019-04-251-1/+1
|
* Speed up locview resolution with relaxable fragsAlexandre Oliva2019-04-254-1/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Targets such as xtensa incur a much higher overhead to resolve location view numbers than e.g. x86, because the expressions used to compute view numbers cannot be resolved soon enough. Each view number is computed by incrementing the previous view, if they are both at the same address, or by resetting it to zero otherwise. If PV is the previous view number, PL is its location, and NL is the location of the next view, its number is computed by evaluating NV = !(NL > PL) * (PV + 1). set_or_check_view uses resolve_expression to decide whether portions of this expression can be simplified to constants. The (NL > PL) subexpression is one that can often be resolved to a constant, breaking chains of view number computations at instructions of nonzero length, but not after alignment that might be unnecessary. Alas, when nearly every frag ends with a relaxable instruction, frag_offset_fixed_p will correctly fail to determine a known offset between two unresolved addresses in neighboring frags, so the unresolved symbolic operation will be constructed and used in the computation of most view numbers. This results in very deep expressions. As view numbers get referenced in location view lists, each operand in the list goes through symbol_clone_if_forward_ref, which recurses on every subexpression. If each view number were to be referenced, this would exhibit O(n^2) behavior, where n is the depth of the view number expressions, i.e., the length of view number sequences without an early resolution that cuts the expression short. This patch enables address compares used by view numbering to be resolved even when exact offsets are not known, using new logic to determine when the location either remained the same or changed for sure, even with the possibility of relaxation. This enables most view number expressions to be resolved with a small, reasonable depth. PR gas/24444 * frags.c (frag_gtoffset_p): New. * frags.h (frag_gtoffset_p): Declare it. * expr.c (resolve_expression): Use it.
* Fix Rust testingTom Tromey2019-04-242-1/+7
| | | | | | | | | | | | | | This changes the gdb test suite to omit -fno-stack-protector when compiling Rust code. This makes Rust testing work again. I think I saw this patch somewhere already, but I couldn't find it again just now, so I'm checking this version in. gdb/testsuite/ChangeLog 2019-04-24 Tom Tromey <tromey@adacore.com> * lib/gdb.exp (gdb_compile): Don't add -fno-stack-protector for Rust.
* Use better test for usable compiler in ld testsuite.Sandra Loosemore2019-04-2441-55/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ld testsuite includes numerous tests that depend on being able to compile and link programs with the C compiler. Some of these tests use [which $CC] to check for the presence of the compiler before proceeding with the test, but run_ld_link_exec_tests and run_cc_link_tests give ERRORs if compilation fails. Also, even if $CC is defined and present, it may not be usable due to missing libraries, etc. This patch adds a new procedure check_compiler_available that attempts to build an empty program and caches the result. Uses of [which $CC] are replaced with calls to this procedure, and run_ld_link_exec_tests and run_cc_link_tests now also guard attempts to use $CC. 2019-04-24 Sandra Loosemore <sandra@codesourcery.com> ld/ * testsuite/config/default.exp: Use [check_compiler_available] instead of [which $CC]. * testsuite/ld-auto-import/auto-import.exp: Likewise. * testsuite/ld-cygwin/exe-export.exp: Likewise. * testsuite/ld-elf/audit.exp: Likewise. * testsuite/ld-elf/compress.exp: Likewise. * testsuite/ld-elf/dwarf.exp: Likewise. * testsuite/ld-elf/elf.exp: Likewise. * testsuite/ld-elf/indirect.exp: Likewise. * testsuite/ld-elf/linux-x86.exp: Likewise. * testsuite/ld-elf/shared.exp: Likewise. * testsuite/ld-elf/tls.exp: Likewise. * testsuite/ld-elf/wrap.exp: Likewise. * testsuite/ld-elfcomm/elfcomm.exp: Likewise. * testsuite/ld-elfvers/vers.exp: Likewise. * testsuite/ld-elfvsb/elfvsb.exp: Likewise. * testsuite/ld-elfweak/elfweak.exp: Likewise. * testsuite/ld-gc/gc.exp: Likewise. * testsuite/ld-i386/i386.exp: Likewise. * testsuite/ld-i386/no-plt.exp: Likewise. * testsuite/ld-i386/tls.exp: Likewise. * testsuite/ld-ifunc/ifunc.exp: Likewise. * testsuite/ld-mn10300/mn10300.exp: Likewise. * testsuite/ld-pe/pe-compile.exp: Likewise. * testsuite/ld-pe/pe-run.exp: Likewise. * testsuite/ld-pe/pe-run2.exp: Likewise. * testsuite/ld-pie/pie.exp: Likewise. * testsuite/ld-plugin/lto.exp: Likewise. * testsuite/ld-plugin/plugin.exp: Likewise. * testsuite/ld-scripts/crossref.exp: Likewise. * testsuite/ld-sh/sh.exp: Likewise. * testsuite/ld-shared/shared.exp: Likewise. * testsuite/ld-size/size.exp: Likewise. * testsuite/ld-srec/srec.exp: Likewise. * testsuite/ld-undefined/undefined.exp: Likewise. * testsuite/ld-unique/unique.exp: Likewise. * testsuite/ld-x86-64/mpx.exp: Likewise. * testsuite/ld-x86-64/no-plt.exp: Likewise. * testsuite/ld-x86-64/tls.exp: Likewise. * testsuite/ld-x86-64/x86-64.exp: Likewise. * testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Call check_compiler_available before trying to use the compiler. (run_cc_link_tests): Likewise. (check_compiler_available): New. Use it instead of [which $CC].
* Use "pulongest" on aarch64-tdep.c:aarch64_gdbarch_initSergio Durigan Junior2019-04-242-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While trying to build GDB on i686, I found the following error: In file included from ../../gdb/common/common-defs.h:105, from ../../gdb/defs.h:28, from ../../gdb/aarch64-tdep.c:21: ../../gdb/aarch64-tdep.c: In function 'gdbarch* aarch64_gdbarch_init(gdbarch_info, gdbarch_list*)': ../../gdb/aarch64-tdep.c:3176:43: error: format '%ld' expects argument of type 'long int', but argument 4 has type 'uint64_t' {aka 'long long unsigned int'} [-Werror=format=] 3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"), | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../gdb/common/gdb_locale.h:28:29: note: in definition of macro '_' 28 | # define _(String) gettext (String) | ^~~~~~ ../../gdb/aarch64-tdep.c:3176:64: note: format string is defined here 3176 | internal_error (__FILE__, __LINE__, _("VQ out of bounds: %ld (max %d)"), | ~~^ | | | long int | %lld This happens because aarch64-tdep.c:aarch64_gdbarch_init prints a "uint64_t" variable using "%ld". This patch fixes the build by using "pulongest" instead. As explained in a similar fix (commit 495143533ad95369811391c6e3c6dadd69d7dd67), this should be safe because if aarch64-tdep.c is included in the build, then ULONGEST must be a 64-bit type. gdb/ChangeLog: 2019-04-24 Sergio Durigan Junior <sergiodj@redhat.com> * aarch64-tdep.c (aarch64_gdbarch_init): Use "pulongest" to print "vq".
* Fix passing of struct with bitfields on x86-64Tom Tromey2019-04-245-4/+37
| | | | | | | | | | | | | | | | | | | | | | | Commit 4aa866af ("Fix AMD64 return value ABI in expression evaluation") introduced a regression when calling a function with a structure that contains bitfields. Because the caller of amd64_has_unaligned_fields handles bitfields already, it seemed to me that the simplest fix was to ignore bitfields here. gdb/ChangeLog 2019-04-24 Tom Tromey <tromey@adacore.com> * amd64-tdep.c (amd64_has_unaligned_fields): Ignore bitfields. gdb/testsuite/ChangeLog 2019-04-24 Tom Tromey <tromey@adacore.com> * gdb.arch/amd64-eval.exp: Test bitfield return. * gdb.arch/amd64-eval.cc (struct Bitfields): New. (class Foo) <return_bitfields>: New method. (main): Call it.
* Stop strip from merging notes when stripping debug or dwo information.Nick Clifton2019-04-243-3/+20
| | | | | | * objcopy.c (strip_main): Do not enable note merging by default if just stripping debug or dwo information. * doc/binutils.texi (strip): Update documentation.
* resolve_symbol_value vs. .loc view resolutionAlan Modra2019-04-243-29/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In most cases we don't want expression symbols, such as that created for an expression like "symbol + (1f - .)", resolved down to a constant. Instead we'd like to leave the expression as "symbol + constant" once the "1f - ." part has been resolved, and let the backend decide whether "symbol" can be reduced further. However, that doesn't work when trying to resolve .loc view symbols early. We get expression symbols left as an O_symbol expression pointing at an absolute symbol, and marked as sy_flags.sy_resolved. That wouldn't really be a problem, but when one of those expression symbols is used in further .loc view expressions, its value is taken as zero. This patch fixes the symbol value mistake, and stops creation of O_symbol expression symbols pointing to absolute symbols. Either of these fixes would cure the .loc view usage. PR 24444 * symbols.c (resolve_symbol_value): When handling symbols marked as sy_flags.resolved, return correct value for the case of expression symbols left as an O_symbol expression. Merge O_symbol code handling undefined and common symbols with code handling special cases of expression symbols. Use seg_left to test for undefined and common symbols. Don't leave an O_symbol expression when X_add_symbol resolves to the absolute_section. Init final_val later. * testsuite/gas/mmix/basep-7.d: Adjust expected output.
* S12Z: Opcodes: Handle bit map operations with non-canonical operands.John Darrington2019-04-245-4/+21
| | | | | | | | | opcodes/ * s12z-opc.c (bm_decode): Handle the RESERVERD0 case. gas/ * testsuite/gas/s12z/bit-manip-invalid.d: Extend the test. * testsuite/gas/s12z/bit-manip-invalid.s: Extend the test.
* S12Z: s12z-opc.h: Add extern "C" bracketingJohn Darrington2019-04-242-1/+13
| | | | | | opcodes/ * s12z-opc.h: Add extern "C" bracketing to help users who wish to use this interface in c++ code.
* Automatic date update in version.inGDB Administrator2019-04-241-1/+1
|
* gdb/s12z: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-18/+7
| | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * s12z-tdep.c (s12z_unwind_pc): Delete. (s12z_unwind_sp): Delete. (s12z_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/rl78: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-9/+5
| | | | | | | | | | | | | Make use of the default gdbarch method gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * rl78-tdep.c (rl78_unwind_sp): Delete. (rl78_gdbarch_init): Don't register deleted function with gdbarch.
* gdb/xstormy16: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-23/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * xstormy16-tdep.c (xstormy16_unwind_sp): Delete. (xstormy16_unwind_pc): Delete. (xstormy16_dummy_id): Delete. (xstormy16_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/vax: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-7/+5
| | | | | | | | | | | | | Make use of the default gdbarch method gdbarch_unwind_pc where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * vax-tdep.c (vax_unwind_pc): Delete. (vax_gdbarch_init): Don't register deleted function with gdbarch.
* gdb/v850: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-25/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * v850-tdep.c (v850_unwind_sp): Delete. (v850_unwind_pc): Delete. (v850_dummy_id): Delete. (v850_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/tilegx: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-26/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * tilegx-tdep.c (tilegx_unwind_sp): Delete. (tilegx_unwind_pc): Delete. (tilegx_unwind_dummy_id): Delete. (tilegx_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/tic6x: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-22/+7
| | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * tic6x-tdep.c (tic6x_unwind_sp): Delete. (tic6x_dummy_id): Delete. (tic6x_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/sparc: Use default_unwind_pcAndrew Burgess2019-04-232-9/+6
| | | | | | | | | | | | | | Make use of the default gdbarch method gdbarch_unwind_pc where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * sparc-tdep.c (sparc_unwind_pc): Delete. (sparc32_gdbarch_init): Don't register deleted function with gdbarch.
* gdb/sh: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-25/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * sh-tdep.c (sh_unwind_sp): Delete. (sh_unwind_pc): Delete. (sh_dummy_id): Delete. (sh_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/score: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-23/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * score-tdep.c (score_unwind_sp): Delete. (score_unwind_pc): Delete. (score_dummy_id): Delete. (score_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/rx: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-36/+10
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * rx-tdep.c (rx_unwind_pc): Delete. (rx_unwind_sp): Delete. (rx_dummy_id): Delete. (rx_gdbarch_init): Don't register deleted functions with gdbarch. Update comment.
* gdb/rs6000: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-18/+7
| | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * rs6000-tdep.c (rs6000_unwind_pc): Delete. (rs6000_dummy_id): Delete. (rs6000_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/or1k: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-9/+5
| | | | | | | | | | | | | | | | | | Make use of the default gdbarch method gdbarch_dummy_id where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. This commit leaves or1k_unwind_sp and or1k_unwind_pc in place. These functions do match the default methods except that they add additional debugging code. In order to preserve the debug I have left these functions unchanged. gdb/ChangeLog: * or1k-tdep.c (or1k_dummy_id): Delete. (or1k_gdbarch_init): Don't register deleted function with gdbarch.
* gdb/nios2: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-20/+7
| | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * nios2-tdep.c (nios2_dummy_id): Delete. (nios2_unwind_sp): Delete. (nios2_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/nds32: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-28/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * nds32-tdep.c (nds32_dummy_id): Delete. (nds32_unwind_pc): Delete. (nds32_unwind_sp): Delete. (nds32_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/msp430: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-32/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * msp430-tdep.c (msp430_unwind_pc): Delete. (msp430_unwind_sp): Delete. (msp430_dummy_id): Delete. (msp430_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/moxie: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-33/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * moxie-tdep.c (moxie_unwind_sp): Delete. (moxie_unwind_pc): Delete. (moxie_dummy_id): Delete. (moxie_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/mn10300: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-31/+11
| | | | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * mn10300-tdep.c (mn10300_dummy_id): Delete. (mn10300_unwind_pc): Delete. (mn10300_unwind_sp): Delete. (mn10300_push_dummy_call): Use gdbarch_unwind_sp not mn10300_unwind_sp. (mn10300_frame_unwind_init): Don't register deleted functions with gdbarch.
* gdb/mep: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-29/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * mep-tdep.c (mep_unwind_pc): Delete. (mep_unwind_sp): Delete. (mep_dummy_id): Delete. (mep_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/m68hc11: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-24/+7
| | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * m68hc11-tdep.c (m68hc11_unwind_pc): Delete. (m68hc11_unwind_sp): Delete. (m68hc11_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/m32r: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-37/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * m32r-tdep.c (m32r_unwind_sp): Delete. (m32r_unwind_pc): Delete. (m32r_dummy_id): Delete. (m32r_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/m32c: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-34/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * m32c-tdep.c (m32c_unwind_pc): Delete. (m32c_unwind_sp): Delete. (m32c_dummy_id): Delete. (m32c_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/lm32: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-23/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/lm32-tdep.c (lm32_unwind_sp): Delete. (lm32_unwind_pc): Delete. (lm32_dummy_id): Delete. (lm32_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/iq2000: Use default gdbarch methods where possibleAndrew Burgess2019-04-232-22/+8
| | | | | | | | | | | | | | | | Make use of the default gdbarch methods for gdbarch_dummy_id, gdbarch_unwind_pc, and gdbarch_unwind_sp where possible. I have not tested this change but, by inspecting the code, I believe the default methods are equivalent to the code being deleted. gdb/ChangeLog: * gdb/iq2000-tdep.c (iq2000_unwind_sp): Delete. (iq2000_unwind_pc): Delete. (iq2000_dummy_id): Delete. (iq2000_gdbarch_init): Don't register deleted functions with gdbarch.
* gdb/nds32: Use type_align instead of nds32_type_alignAndrew Burgess2019-04-232-47/+7
| | | | | | | | | | | | | | | | | The general type_align method should be a suitable alternative to nds32_type_align, so switch to use that. The only change this will introduce is related to static fields in a struct or union, the existing code doesn't take account of static fields when computing the alignment for structs of unions, though this is probably a bug - which would probably be exposed by the test case gdb.cp/many-args.exp, though I don't have any way to test this target right now. gdb/ChangeLog: * nds32-tdep.c (nds32_type_align): Delete. (nds32_push_dummy_call): Use type_align instead.
* gdb/arm: Use type_align instead of arm_type_alignAndrew Burgess2019-04-232-51/+23
| | | | | | | | | | | | | | | | | | Replaces use of arm_type_align with common type_align function. Doing this fixes a bug in arm_type_align where static fields are considered as part of the alignment calculation of a struct, which results in arguments passed on the stack being misaligned, this bug was causing a failure in gdb.cp/many-args.exp. Part of the old arm_type_align is retained and used as the gdbarch type align callback in order to correctly align vectors. gdb/ChangeLog: * arm-tdep.c (arm_type_align): Only handle vector override case. (arm_push_dummy_call): Use type_align. (arm_gdbarch_init): Register arm_type_align gdbarch function.
* gdb/aarch64: Use type_align instead of aarch64_type_alignAndrew Burgess2019-04-235-51/+144
| | | | | | | | | | | | | | | | | | | | | | | | | Replaces use of aarch64_type_align with common type_align function. Doing this fixes a bug in aarch64_type_align where static fields are considered as part of the alignment calculation of a struct, which results in arguments passed on the stack being misaligned. This bug is exposed in the new test gdb.cp/many-args.exp. Part of the old aarch64_type_align is retained and used as the gdbarch type align callback in order to correctly align vectors. gdb/ChangeLog: * aarch64-tdep.c (aarch64_type_align): Only handle vector override case. (pass_on_stack): Use type_align. (aarch64_gdbarch_init): Register aarch64_type_align gdbarch function. gdb/testsuite/ChangeLog: * gdb.cp/many-args.cc: New file. * gdb.cp/many-args.exp: New file.
* Remove unused overload of line_header::file_name_atTom Tromey2019-04-232-8/+5
| | | | | | | | | | | I noticed that one of the overloads of line_header::file_name_at is unused. This patch removes it. gdb/ChangeLog 2019-04-23 Tom Tromey <tromey@adacore.com> * dwarf2read.c (line_header::file_name_at): Remove unused overload.
View Lorry Controller Status