aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-04-29gdb: Introduce new language field la_is_string_type_pAndrew Burgess14-0/+177
This commit is preparation work for the next commit, and by itself makes no user visible change to GDB. I've split this work into a separate commit in order to make code review easier. This commit adds a new field 'la_is_string_type_p' to the language struct, this predicate will return true if a type is a string type for the given language. Some languages already have a "is this a string" predicate that I was able to reuse, while for other languages I've had to add a new predicate. In this case I took inspiration from the value printing code for that language - what different conditions would result in printing something as a string. A default "is this a string" method has also been added that looks for TYPE_CODE_STRING, this is the fallback I've used for a couple of languages. In this commit I add the new field and initialise it for each language, however at this stage the new field is never used. gdb/ChangeLog: * ada-lang.c (ada_language_defn): Initialise new field. * c-lang.c (c_is_string_type_p): New function. (c_language_defn): Initialise new field. (cplus_language_defn): Initialise new field. (asm_language_defn): Initialise new field. (minimal_language_defn): Initialise new field. * c-lang.h (c_is_string_type_p): Declare new function. * d-lang.c (d_language_defn): Initialise new field. * f-lang.c (f_is_string_type_p): New function. (f_language_defn): Initialise new field. * go-lang.c (go_is_string_type_p): New function. (go_language_defn): Initialise new field. * language.c (default_is_string_type_p): New function. (unknown_language_defn): Initialise new field. (auto_language_defn): Initialise new field. * language.h (struct language_defn) <la_is_string_type_p>: New member variable. (default_is_string_type_p): Declare new function. * m2-lang.c (m2_language_defn): Initialise new field. * objc-lang.c (objc_language_defn): Initialise new field. * opencl-lang.c (opencl_language_defn): Initialise new field. * p-lang.c (pascal_is_string_type_p): New function. (pascal_language_defn): Initialise new field. * rust-lang.c (rust_is_string_type_p): New function. (rust_language_defn): Initialise new field.
2019-04-29gdb: Introduce new language field la_struct_too_deep_ellipsisAndrew Burgess13-15/+56
This commit is preparation work for a later commit, and by itself makes no user visible change to GDB. I've split this work into a separate commit in order to make code review easier. This commit adds a new field 'la_struct_too_deep_ellipsis' to the language struct, this string will be used in the next commit to print a language specific string from within the generic value printing code. In this commit I add the new field and initialise it for each language, however at this stage the new field is never used. gdb/ChangeLog: * language.h (struct language_defn) <la_struct_too_deep_ellipsis>: New field. * ada-lang.c (ada_language_defn): Initialise new field. * c-lang.c (c_language_defn): Likewise. (cplus_language_defn): Likewise. (asm_language_defn): Likewise. (minimal_language_defn): Likewise. * d-lang.c (d_language_defn): Likewise. * f-lang.c (f_language_defn): Likewise. * go-lang.c (go_language_defn): Likewise. * language.c (unknown_language_defn): Likewise. (auto_language_defn): Likewise. * m2-lang.c (m2_language_defn): Likewise. * objc-lang.c (objc_language_defn): Likewise. * opencl-lang.c (opencl_language_defn): Likewise. * p-lang.c (pascal_language_defn): Likewise. * rust-lang.c (rust_language_defn): Likewise.
2019-04-29gdb/ada: Update some predicate functions to return boolAndrew Burgess3-6/+13
A later commit would like to make use of a pointer to the function ada_is_string_type, however, this will require the function to return a bool (so the signature matches). As the ada_is_string_type is a predicate function, and its return value is only ever used as either true or false, then this commit updates the function to return a bool. As a consequence ada_is_character_type needs to change too. There should be no user visible changes after this commit. gdb/ChangeLog: * ada-lang.c (ada_is_character_type): Change return type to bool. (ada_is_string_type): Likewise. * ada-lang.h (ada_is_character_type): Update declaration (ada_is_string_type): Likewise.
2019-04-29[gdb/testsuite] Fix regexp in skip_opencl_testsTom de Vries2-1/+5
When running gdb-caching-proc.exp, if skip_opencl_tests fails like this: ... (gdb) run Starting program: \ build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001) src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown [Inferior 1 (process 13600) exited with code 01] (gdb) skip_opencl_tests: OpenCL support not detected ... then this regexp in skip_opencl_tests fails to match: ... -re ".*$inferior_exited_re code.*${gdb_prompt} $" { ... so instead we hit the default clause after a 30 seconds timeout. With the iteration count set at 10, we end up taking 6 minutes to run this test-case. Fix this by adding the missing "with" in the regexp, bring back the runtime to half a minute. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2019-04-29 Tom de Vries <tdevries@suse.de> * lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
2019-04-29S12Z: Opcodes: Fix crash when trying to decode a truncated operation.John Darrington6-1/+32
opcodes/ * s12z-opc.c (shift_discrim): Return OP_INVALID when reading fails. gas/ * testsuite/gas/s12z/truncated.d: New file. * testsuite/gas/s12z/truncated.s: New file. * testsuite/gas/s12z/s12z.exp: Add new test.
2019-04-29Automatic date update in version.inGDB Administrator1-1/+1
2019-04-28Follow-up to Support style in 'frame|thread apply'Philippe Waroquiers2-1/+32
Fix build problem when configuring with guile. Fix the forgotten copy of ChangeLog info to ChangeLog.
2019-04-28Automatic date update in version.inGDB Administrator1-1/+1
2019-04-27Have 'thread|frame apply' style their output.Philippe Waroquiers10-47/+123
'thread|frame apply CMD' launches CMD so that CMD output goes to a string_file. This patch ensures that string_file for such CMD output contains style escape sequences that 'thread|frame apply' will later on output on the real terminal, so as to have CMD output properly styled. The idea is to have the class ui_file having overridable methods to indicate that the output to this ui_file should be done using 'terminal' behaviour such as styling. Then these methods are overriden in string_file so that a specially constructed string_file will get output with style escape sequences. After this patch, the output of CMD by thread|frame apply CMD is styled similarly as when CMD is launched directly. Note that string_file (term_out true) could also support wrapping, but this is not done (yet?). Tested on debian/amd64. gdb/ChangeLog 2019-04-27 Philippe Waroquiers <philippe.waroquiers@skynet.be> Support style in 'frame|thread apply' * gdbcmd.h (execute_command_to_string): New term_out parameter. * record.c (record_start, record_stop): Update callers of execute_command_to_string with false. * ui-file.h (class ui_file): New term_out and can_emit_style_escape methods. (class string_file): New constructor with term_out parameter. Override methods term_out and can_emit_style_escape. New member term_out. (class stdio_file): Override can_emit_style_escape. (class tee_file): Override term_out and can_emit_style_escape. * utils.h (can_emit_style_escape): Remove. * utils.c (can_emit_style_escape): Likewise. Update all callers of can_emit_style_escape (SOMESTREAM) to SOMESTREAM->can_emit_style_escape. * source-cache.c (source_cache::get_source_lines): Likewise. * stack.c (frame_apply_command_count): Call execute_command_to_string passing the term_out characteristic of the current gdb_stdout. * thread.c (thr_try_catch_cmd): Likewise. * top.c (execute_command_to_string): pass term_out parameter to construct the string_file for the command output. * ui-file.c (term_cli_styling): New function (most code moved from utils.c can_emit_style_escape). (string_file::string_file, string_file::can_emit_style_escape, stdio_file::can_emit_style_escape, tee_file::term_out, tee_file::can_emit_style_escape): New functions.
2019-04-27Implement show | set may-call-functions [on|off]Philippe Waroquiers7-0/+86
Inferior function calls are powerful but might lead to undesired results such as crashes when calling nested functions (frequently used in particular in Ada). This implements a GDB setting to disable calling inferior functions. Note: the idea is that if/when the 'slash command' patch is pushed, that this setting can be changed e.g. by using the shortcut /c. This is version 2 of the patch. It handles all the received comments, mostly replace 'can-call' by 'may-call', and avoid using 'inferior function call' in factor of 'calling function in the program'. 2019-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be> gdb/ChangeLog * NEWS: Mention the new set|show may-call-functions. * infcall.c (may_call_functions_p): New variable. (show_may_call_functions_p): New function. (call_function_by_hand_dummy): Throws an error if not may-call-functions. (_initialize_infcall): Call add_setshow_boolean_cmd for may-call-functions. gdb/testsuite/ChangeLog * gdb.base/callexit.exp: Test may-call-functions off. gdb/doc/ChangeLog * gdb.texinfo (Calling): Document the new set|show may-call-functions.
2019-04-26[MIPS] Add load-link, store-conditional paired instructionsAndrew Bennett18-10/+251
Add several baseline MIPS32R6[1] and MIPS64R6[2] instructions that were omitted from the initial spec. These instructions are optional in implementations but not associated with any ASE or pseudo-ASE. Their presence is indicated by the XNP bit in the Config5 register. [1] "MIPS Architecture for Programmers Volume II-A: The MIPS32 Instruction Set Manual", Imagination Technologies Ltd., Document Number: MD00086, Revision 6.06, December 15, 2016, Section 3.2 "Alphabetical List of Instructions", pp. 228-229, pp. 354-357. [2] "MIPS Architecture for Programmers Volume II-A: The MIPS64 Instruction Set Manual", Imagination Technologies Ltd., Document Number: MD00087, Revision 6.06, December 15, 2016, Section 3.2 "Alphabetical List of Instructions", pp. 289-290 and pp. 458-460. gas/ * config/tc-mips.c (macro) <M_LLWP_AB, M_LLDP_AB, M_SCWP_AB, M_SCDP_AB>: New cases and expansions for paired instructions. * testsuite/gas/mips/llpscp-32.s: New test source. * testsuite/gas/mips/llpscp-64.s: Likewise. * testsuite/gas/mips/llpscp-32.d: New test. * testsuite/gas/mips/llpscp-64.d: Likewise. * testsuite/gas/mips/mips.exp: Run the new tests. * testsuite/gas/mips/r6.s: Add new instructions to test source. * testsuite/gas/mips/r6-64.s: Likewise. * testsuite/gas/mips/r6-64-n32.d: Check new instructions. * testsuite/gas/mips/r6-64-n64.d: Likewise. * testsuite/gas/mips/r6-n32.d: Likewise. * testsuite/gas/mips/r6-n64.d: Likwwise. * testsuite/gas/mips/r6.d: Likewise. include/ * opcode/mips.h (M_LLWP_AB, M_LLDP_AB): New enum values. (M_SCWP_AB, M_SCDP_AB): Likewise. opcodes/ * mips-opc.c (mips_builtin_opcodes): Add llwp, lldp, scwp, scdp.
2019-04-27Automatic date update in version.inGDB Administrator1-1/+1
2019-04-26i386: Don't add 0x66 prefix to IRET for .code16gccH.J. Lu4-0/+22
The .code16gcc directive supports 16bit mode with 32-bit address. Since IRET (opcode 0xcf) in 16bit mode returns from an interrupt in 16bit mode, we shouldn't add 0x66 prefix for IRET. PR gas/24485 * config/tc-i386.c (process_suffix): Don't add DATA_PREFIX_OPCODE to IRET for .code16gcc. * testsuite/gas/i386/jump16.s: Add IRET tests. * testsuite/gas/i386/jump16.d: Updated.
2019-04-26Don't complain undefined weak dynamic referenceH.J. Lu7-1/+44
When undefined non-weak references in IR objects are optimized out by LTO, we can have weak dynamic referencs to symbols marked with bfd_link_hash_undefined. We shouldn't complain such undefined weak dynamic references. bfd/ PR ld/24486 * elflink.c (elf_link_output_extsym): Don't complain undefined weak dynamic reference. ld/ PR ld/24486 * testsuite/ld-plugin/lto.exp: Run PR ld/24486 tests. * testsuite/ld-plugin/pr24486a.c: New file. * testsuite/ld-plugin/pr24486b.c: Likewise. * testsuite/ld-plugin/pr24486c.c: Likewise.
2019-04-26Updated Russian translation for the ld subdirectory.Nick Clifton2-1398/+6670
* po/ru.po: Updated Russian translation.
2019-04-26Fix the hyphenation of word phrases such as "target specific" and "machine ↵Christopher Yeleighton2-6/+10
specific". * ld.texi: Properly hyphenate the word "specific".
2019-04-26Automatic date update in version.inGDB Administrator1-1/+1
2019-04-25c++/24367: Infinite recursion of typedef substitutionKeith Seitz5-3/+46
This bug finds another usage where we end up segfaulting while normalizing user input. inspect_type and replace_type recurse, attempting to substitute the "real" symbol name for the typedef name. However, since the both these names are the same, they keep calling each other until the stack overflows. A simple reproducer for it is given by typedef struct foo foo; int qux (foo *f) { return 0; } (gdb) b qux(foo*) Segmentation fault inspect_type already contains some special handling to prevent a similar situation from occurring with namespaces. I wonder, however, whether we need be so pedantic about the exact nature of the substitution. This patch implements this rather more aggressive assumption that these substitutions should be avoided whenever the replacement symbol's name is exactly the same as the one we're trying to substitute. [In the above example, we're trying to substitute the tyepdef named "foo" with the symbol named "foo" (a struct).] gdb/ChangeLog: PR c++/24367 * cp-support.c (inspect_type): Don't attempt substitutions of symbol with the same name. gdb/testsuite/ChangeLog: PR c++/24367 * gdb.cp/meth-typedefs.cc (incomplete_struct) (another_incomplete_struct, test_incomplete): New definitions. (main): Use new definitions. * gdb.cp/meth-typedefs.exp: Add new tests for `test_incomplete' functions.
2019-04-25Fix memory leak in exception codeTom Tromey2-1/+11
PR gdb/24475 concerns a memory leak coming from gdb's exception handling code. The leak occurs because throw_exception_sjlj does not arrange to destroy the exception object it is passed. However, because gdb_exception has a destructor, it's undefined to longjmp in this situation. This patch fixes the problem by avoiding the need to run any destructors in gdb_rl_callback_handler, by making the gdb_exception "static". gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> PR gdb/24475: * event-top.c (gdb_rl_callback_handler): Make "gdb_rl_expt" static.
2019-04-25Make exception handling more efficientTom Tromey20-63/+110
This makes exception handling more efficient in a few spots, through the use of const- and rvalue-references. I wrote this patch by commenting out the gdb_exception copy constructor and then examining the resulting error messages one by one, introducing the use of std::move where appropriate. gdb/ChangeLog 2019-04-25 Tom Tromey <tromey@adacore.com> * xml-support.c (struct gdb_xml_parser) <set_error>: Take an rvalue reference. (gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper) (gdb_xml_parser::parse): Use std::move. * python/python-internal.h (gdbpy_convert_exception): Take a const reference. * python/py-value.c (valpy_getitem, valpy_nonzero): Use std::move. * python/py-utils.c (gdbpy_convert_exception): Take a const reference. * python/py-inferior.c (infpy_write_memory, infpy_search_memory): Use std::move. * python/py-breakpoint.c (bppy_set_condition, bppy_set_commands): Use std::move. * mi/mi-main.c (mi_print_exception): Take a const reference. * main.c (handle_command_errors): Take a const reference. * linespec.c (parse_linespec): Use std::move. * infcall.c (run_inferior_call): Use std::move. (call_function_by_hand_dummy): Use std::move. * exec.c (try_open_exec_file): Use std::move. * exceptions.h (exception_print, exception_fprintf) (exception_print_same): Update. * exceptions.c (print_exception, exception_print) (exception_fprintf, exception_print_same): Change parameters to const reference. * event-top.c (gdb_rl_callback_read_char_wrapper): Update. * common/new-op.c: Use std::move. * common/common-exceptions.h (struct gdb_exception): Add move constructor. (struct gdb_exception_error, struct gdb_exception_quit, struct gdb_quit_bad_alloc): Change constructor to move constructor. (throw_exception): Change parameter to rvalue reference. * common/common-exceptions.c (throw_exception): Take rvalue reference. * cli/cli-interp.c (safe_execute_command): Use std::move. * breakpoint.c (insert_bp_location, location_to_sals): Use std::move.
2019-04-25Avoid undefined behavior in Guile exception handlingTom Tromey16-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.
2019-04-25Make SJLJ exceptions more efficientTom Tromey4-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.
2019-04-25Remove exception_noneTom Tromey19-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.
2019-04-25[PATCH] Support for DW_FORM_strx tagAli Tamur3-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.
2019-04-25ChangeLog entries for the previous commit.Sergio Durigan Junior2-0/+15
I forgot to include the ChangeLog entries in the commit 57e5e645010430b3d73f8c6a757d09f48dc8f8d5 ("Implement dump of mappings with ELF headers by gcore").
2019-04-25Implement dump of mappings with ELF headers by gcoreSergio Durigan Junior3-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.
2019-04-25testsuite: Add option to capture gdbserver debugAlan Hayward6-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
2019-04-25LTO: Properly handle wrapper symbols in IRH.J. Lu7-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.
2019-04-25Detect invalid length field in debug frame FDE header.Sandra Loosemore2-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.
2019-04-25[BFD, AArch64] Improve bti/pac plts.Sudakshina Das10-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.
2019-04-25MIPS/include: opcode/mips.h: Update stale comment for CODE20 operandMaciej W. Rozycki2-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.
2019-04-25Automatic date update in version.inGDB Administrator1-1/+1
2019-04-25Speed up locview resolution with relaxable fragsAlexandre Oliva4-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.
2019-04-24Fix Rust testingTom Tromey2-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.
2019-04-24Use better test for usable compiler in ld testsuite.Sandra Loosemore41-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].
2019-04-24Use "pulongest" on aarch64-tdep.c:aarch64_gdbarch_initSergio Durigan Junior2-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".
2019-04-24Fix passing of struct with bitfields on x86-64Tom Tromey5-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.
2019-04-24Stop strip from merging notes when stripping debug or dwo information.Nick Clifton3-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.
2019-04-24resolve_symbol_value vs. .loc view resolutionAlan Modra3-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.
2019-04-24S12Z: Opcodes: Handle bit map operations with non-canonical operands.John Darrington5-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.
2019-04-24S12Z: s12z-opc.h: Add extern "C" bracketingJohn Darrington2-1/+13
opcodes/ * s12z-opc.h: Add extern "C" bracketing to help users who wish to use this interface in c++ code.
2019-04-24Automatic date update in version.inGDB Administrator1-1/+1
2019-04-23gdb/s12z: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/rl78: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/xstormy16: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/vax: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/v850: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/tilegx: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/tic6x: Use default gdbarch methods where possibleAndrew Burgess2-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.
2019-04-23gdb/sparc: Use default_unwind_pcAndrew Burgess2-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.