Commit Graph

96745 Commits

Author SHA1 Message Date
Alan Modra 34d75fb5c4 Check asprintf return value
git a31b8bd9a0 introduced a warning (depending on your system
headers).

	PR 24225
	* elf32-nios2.c (nios2_elf32_relocate_section): Check asprintf
	return value.
2019-02-20 18:54:41 +10:30
Alan Modra c22b42ce30 Unsigned integer overflows in readelf checks
PR 24132
	PR 24138
	* readelf.c (get_data): Avoid possibility of overflow when
	checking for a read that may extend past end of file.
	(process_program_headers): Likewise.
2019-02-20 18:22:50 +10:30
Michael Roitzsch edd01d077c Use or1k-darwin host SHARED_LIBADD for *-darwin.
* configure.ac (SHARED_LIBADD): Add -liberty -lintl for all
	Darwin hosts, not just or1k.
	* configure: Regenerate.
2019-02-20 14:49:07 +10:30
Alan Modra 7d272a55ca PR24233, Out of memory
PR 24233
	* objdump.c (dump_bfd_private_header): Print warning if
	bfd_print_private_bfd_data returns false.
2019-02-20 13:41:54 +10:30
Simon Marchi 6caa91b6e5 Fix error message and use-after-free on errors in nested sourced files
Errors that happen in nested sourced files (when a sourced file sources
another file) lead to a wrong error message, or use-after-free.

For example, if I put this in "a.gdb":

    command_that_doesnt_exist

and this in "b.gdb":

   source a.gdb

and try to "source b.gdb" in GDB, the result may look like this:

    (gdb) source b.gdb
    b.gdb:1: Error in sourced command file:
    _that_doesnt_exist:1: Error in sourced command file:
    Undefined command: "command_that_doesnt_exist".  Try "help".

Notice the wrong file name where "a.gdb" should be.  The exact result
may differ, depending on the feelings of the memory allocator.

What happens is:

- The "source a.gdb" command is saved by command_line_append_input_line
  in command_line_input's static buffer.
- Since we are sourcing a file, the script_from_file function stores the
  script name (a.gdb) in the source_file_name global.  However, it doesn't
  do a copy, it just saves a pointer to command_line_input's static buffer.
- The "command_that_doesnt_exist" command is saved by
  command_line_append_input_line in command_line_input's static buffer.
  Depending on what xrealloc does, source_file_name may now point to
  freed memory, or at the minimum the data it was pointing to was
  overwritten.
- When the error is handled in script_from_file, we dererence
  source_file_name to print the name of the file in which the error
  occured.

To fix it, I made source_file_name an std::string, so that keeps a copy of
the file name instead of pointing to a buffer with a too small
lifetime.

With this patch, the expected filename is printed, and no use-after-free
occurs:

    (gdb) source b.gdb
    b.gdb:1: Error in sourced command file:
    a.gdb:1: Error in sourced command file:
    Undefined command: "command_that_doesnt_exist".  Try "help".

I passed explicit template parameters to make_scoped_restore
(<std::string, const std::string &>), so that the second parameter is
passed by reference and avoid a copy.

It was not as obvious as I first thought to change gdb.base/source.exp
to test this, because source commands inside sourced files are
interpreted relative to GDB's current working directory, not the
directory of the currently sourced file.  As a workaround, I moved the
snippet that tests errors after the snippet that adds the source
directory to the search path.  This way, the "source source-error-1.gdb"
line in source-error.exp manages to find the file.

For reference, here is what ASAN reports when use-after-free occurs:

(gdb) source b.gdb
=================================================================
==18498==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000019847 at pc 0x7f1d3645de8e bp 0x7ffdcb892e50 sp 0x7ffdcb8925c8
READ of size 6 at 0x60c000019847 thread T0
    #0 0x7f1d3645de8d in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546
    #1 0x7f1d36477175 in __interceptor_vasprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1525
    #2 0x5632eaffa277 in xstrvprintf(char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-utils.c:122
    #3 0x5632eaff96d1 in throw_it /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:351
    #4 0x5632eaff98df in throw_verror(errors, char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:379
    #5 0x5632eaff9a2a in throw_error(errors, char const*, ...) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:394
    #6 0x5632eafca21a in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1553
    #7 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #8 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #9 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #10 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #11 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #12 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #13 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #14 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
    #15 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #16 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #17 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #18 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #19 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #20 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #21 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #22 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #23 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
    #24 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
    #25 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
    #26 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
    #27 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
    #28 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
    #29 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
    #30 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
    #31 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
    #32 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
    #33 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
    #34 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
    #35 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
    #36 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
    #37 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
    #38 0x5632eabfe5dd in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x195d5dd)

0x60c000019847 is located 7 bytes inside of 128-byte region [0x60c000019840,0x60c0000198c0)
freed by thread T0 here:
    #0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
    #1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
    #2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
    #3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
    #4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
    #5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
    #6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
    #7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #15 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
    #16 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #17 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #18 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #19 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #20 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #21 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #22 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #23 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #24 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
    #25 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
    #26 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
    #27 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
    #28 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
    #29 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511

previously allocated by thread T0 here:
    #0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
    #1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
    #2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
    #3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
    #4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
    #5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
    #6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
    #7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #15 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
    #16 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
    #17 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
    #18 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
    #19 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
    #20 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
    #21 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
    #22 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
    #23 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
    #24 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
    #25 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
    #26 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
    #27 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
    #28 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
    #29 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

SUMMARY: AddressSanitizer: heap-use-after-free /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 in printf_common

gdb/ChangeLog:

	* top.h (source_file_name): Change to std::string.
	* top.c (source_file_name): Likewise.
	(command_line_input): Adjust.
	* cli/cli-script.c (script_from_file): Adjust.

gdb/testsuite/ChangeLog:

	* gdb.base/source.exp: Move "error in sourced script" code to
	the end.
	* gdb.base/source-error.gdb: Move contents to
	source-error-1.gdb.  Add new code to source source-error-1.gdb.
	* gdb.base/source-error-1.gdb: New file, from previous
	source-error.gdb.
2019-02-19 21:13:21 -05:00
Alan Modra 8abac8031e PR24236, Heap buffer overflow in _bfd_archive_64_bit_slurp_armap
PR 24236
	* archive64.c (_bfd_archive_64_bit_slurp_armap): Move code adding
	sentinel NUL to string buffer nearer to loop where it is used.
	Don't go past sentinel when scanning strings, and don't write
	NUL again.
	* archive.c (do_slurp_coff_armap): Simplify string handling to
	archive64.c style.
2019-02-20 11:50:07 +10:30
Egeyar Bagcioglu 7ae39e2d40 Check whether symbols with MOVW_.ABS relocations require PLT entries (aarch64).
2019-02-19  Egeyar Bagcioglu  <egeyar.bagcioglu@oracle.com>

gold/
     PR gold/23870
     * aarch64.cc (Target_aarch64::Scan::global): Check if a symbol with
     R_AARCH64_MOVW_.ABS_* relocations requires a PLT entry.
     * testsuite/Makefile.am: Add aarch64_pr23870 test case.
     * testsuite/Makefile.in: Regenerate.
     * testsuite/aarch64_pr23870_bar.c: New file.
     * testsuite/aarch64_pr23870_foo.c: New file.
     * testsuite/aarch64_pr23870_main.S: New file.
2019-02-19 16:13:24 -08:00
GDB Administrator abaeb15626 Automatic date update in version.in 2019-02-20 00:00:41 +00:00
Tom Tromey 98814c6c11 Minor Ada task cleanups
While working on the Ada task code, I noticed a few things that could
be cleaned up:

* task_list_valid_p was not set in all cases in ada_build_task_list.
  This causes many needless re-fetches of the task list.

* task_list_valid_p can be bool, and various functions can also return
  bool.

* Nothing checks the return value of read_known_tasks, so it can be
  changed to return void.

* The call to ada_build_task_list in
  ravenscar_thread_target::update_thread_list is redundant, because
  this is the first thing done by iterate_over_live_ada_tasks.

Tested using the internal AdaCore test suite against a ravenscar
target.

gdb/ChangeLog
2019-02-19  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c
	(ravenscar_thread_target::update_thread_list): Don't call
	ada_build_task_list.
	* ada-lang.h (ada_build_task_list): Don't declare.
	* ada-tasks.c (struct ada_tasks_inferior_data)
	<task_list_valid_p>: Now bool.
	(read_known_tasks, ada_task_list_changed)
	(ada_tasks_invalidate_inferior_data): Update.
	(read_known_tasks_array): Return bool.
	(read_known_tasks_list): Likewise.
	(read_known_tasks): Return void.
	(ada_build_task_list): Now static.
2019-02-19 12:26:37 -07:00
Paul Hua 6f2117ba38 Fix a potential deadlock in some older Loongson 3A1000 MIPS processors.
* NEWS: Mention -m[no-]fix-loongson3-llsc.
	* configure.ac: Add --enable-mips-fix-loongson3-llsc.
	Define DEFAULT_MIPS_FIX_LOONGSON3_LLSC.
	* config.in: Regenerated.
	* configure: Likewise.
	* config/tc-mips.c (sync_insn, mips_fix_loongson3_llsc):
	New variables.
	(options): New OPTION_FIX_LOONGSON3_LLSC,
	OPTION_NO_FIX_LOONGSON3_LLSC.
	(md_longopts): Add -m[no-]fix-loongson3-llsc.
	(md_begin): Initialize sync insn.
	(fix_loongson3_llsc): New.
	(append_insn): Call fix_loongson3_llsc.
	(md_parse_option): Handle OPTION_FIX_LOONGSON3_LLSC,
	OPTION_NO_FIX_LOONGSON3_LLSC.
	(md_show_usage): Display -m[no-]fix-loongson3-llsc.
	* doc/c-mips.texi: Document -m[no-]fix-loongson3-llsc,
	--enable-mips-fix-loongson3-llsc=[yes|no].
2019-02-19 17:57:16 +00:00
Alan Modra 179f2db0d9 PR24235, Read memory violation in pei-x86_64.c
PR 24235
	* pei-x86_64.c (pex64_bfd_print_pdata_section): Correct checks
	attempting to prevent read past end of section.
2019-02-19 22:52:55 +10:30
GDB Administrator c72e75a640 Automatic date update in version.in 2019-02-19 00:00:40 +00:00
Andrew Burgess 70cd633e87 gdb: Allow gdbarch to override alignment for method and member pointers
The code in type_align (gdbtypes.c) currently hard-codes the rules for
aligning method and member pointers.  It would seem better to forward
these types through the gdbarch hook, so that an architecture could
override the alignment of these types if needed.

Only 3 architectures currently override the gdbarch alignment hook,
these are arc, i386, and nio2.

For arc and nios the alignment rules are that alignment is the minimum
of 4-bytes and the type length.  As pointers are 4-bytes on these
targets, then (assuming method and members pointers are also 4-bytes)
there should be no change to the alignment after this patch.

For i386 the gdbarch alignment hook overrides for some INT and FLOAT
types only.  For method and member pointers we align on the type size
still, so there should be no change to the alignment after this patch.

I tested this on x86-64 GNU Linux with no regressions.

gdb/ChangeLog:

	* gdbtypes.c (type_align): Allow alignment of TYPE_CODE_METHODPTR
	and TYPE_CODE_MEMBERPTR to be overridden by the gdbarch.
2019-02-18 23:24:53 +00:00
Philippe Waroquiers 040b3e95e4 Fix leaks of 'per program space' and 'per inferior' ada task data.
Valgrind reports leaks such as the below.
Fix these leaks by changing ada_tasks_pspace_data_handle
and ada_tasks_inferior_data_handle to use the 'with_cleanup' register variant.

Tested on debian/amd64 natively and under Valgrind.

==26346== 56 bytes in 1 blocks are definitely lost in loss record 631 of 3,249
==26346==    at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==26346==    by 0x38F911: get_ada_tasks_inferior_data(inferior*) (ada-tasks.c:281)
==26346==    by 0x38FA3F: ada_tasks_invalidate_inferior_data (ada-tasks.c:1362)
==26346==    by 0x38FA3F: ada_tasks_new_objfile_observer(objfile*) (ada-tasks.c:1411)
==26346==    by 0x60CBC5: operator() (functional:2127)
==26346==    by 0x60CBC5: notify (observable.h:106)
==26346==    by 0x60CBC5: clear_symtab_users(enum_flags<symfile_add_flag>) (symfile.c:2903)
...

==26346== 104 bytes in 1 blocks are definitely lost in loss record 984 of 3,249
==26346==    at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==26346==    by 0x4056F0: xcalloc (common-utils.c:84)
==26346==    by 0x38F8AE: xcnew<ada_tasks_pspace_data> (poison.h:122)
==26346==    by 0x38F8AE: get_ada_tasks_pspace_data(program_space*) (ada-tasks.c:253)
==26346==    by 0x38FA77: ada_tasks_invalidate_pspace_data (ada-tasks.c:1354)
==26346==    by 0x38FA77: ada_tasks_new_objfile_observer(objfile*) (ada-tasks.c:1394)
==26346==    by 0x60CBC5: operator() (functional:2127)
==26346==    by 0x60CBC5: notify (observable.h:106)
...

gdb/ChangeLog
2019-02-18  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* ada-task.c (_initialize_tasks): Use 'with_cleanup' register
	variant for ada_tasks_pspace_data_handle and
	ada_tasks_inferior_data_handle.
	(ada_tasks_pspace_data_cleanup): New function.
	(ada_tasks_inferior_data_cleanup): New function.
2019-02-18 22:14:59 +01:00
Alan Modra a31b8bd9a0 PR24225, nios2 buffer overflow
PR 24225
	* elf32-nios2.c (nios2_elf32_relocate_section): Use asprintf and
	PRIx64 to generate warning messages.  Print local sym names too.
2019-02-18 15:12:34 +10:30
GDB Administrator d57e4f2b86 Automatic date update in version.in 2019-02-18 00:00:44 +00:00
Tom Tromey 9409233b0e Change macro_source_fullname to return a std::string
While working on the previous patch, I noticed that if
macro_source_fullname returned a std::string, then the callers would
be simplified.  This patch implements this idea.

gdb/ChangeLog
2019-02-17  Tom Tromey  <tom@tromey.com>

	* macrotab.h (macro_source_fullname): Return a std::string.
	* macrotab.c (macro_include, check_for_redefinition)
	(macro_undef, macro_lookup_definition, foreach_macro)
	(foreach_macro_in_scope): Update.
	(macro_source_fullname): Return a std::string.
	* macrocmd.c (show_pp_source_pos): Update.
2019-02-17 16:28:38 -07:00
Tom Tromey 6506371f06 Add styling to macro commands
This adds filename styling to "info macro".

gdb/ChangeLog
2019-02-17  Tom Tromey  <tom@tromey.com>

	* macrocmd.c (show_pp_source_pos): Style the file names.

gdb/testsuite/ChangeLog
2019-02-17  Tom Tromey  <tom@tromey.com>

	* gdb.base/style.exp: Use -g3 to compile when possible.  Add test
	for macro styling.
	* gdb.base/style.c (SOME_MACRO): New macro.
2019-02-17 16:28:38 -07:00
Tom Tromey 0c820d6793 Fix some valgrind errors in the TUI
The styling series introduced some new errors in the TUI -- the series
changed how source lines are allocated, without updating
tui_set_source_content_nil.

There are several failures but a typical one looks like:

==6274== Use of uninitialised value of size 8
==6274==    at 0x4E4A095: wclrtoeol (in /usr/lib64/libncursesw.so.6.1)
==6274==    by 0x4E47617: waddch (in /usr/lib64/libncursesw.so.6.1)
==6274==    by 0x8325CB: tui_puts_internal(_win_st*, char const*, int*) (tui-io.c:393)
==6274==    by 0x82E89D: tui_file::puts(char const*) (tui-file.c:39)
==6274==    by 0x84BF5F: vfprintf_unfiltered(ui_file*, char const*, __va_list_tag*) (utils.c:2026)

This patch rewrites tui_set_source_content_nil, fixing the bug.

This was also reported as PR tui/24197.

Verified by running valgrind before and after on x86-64 Fedora 29.

gdb/ChangeLog
2019-02-17  Tom Tromey  <tom@tromey.com>

	PR tui/24197:
	* tui/tui-source.c (tui_set_source_content_nil): Rewrite.
2019-02-17 10:39:45 -07:00
Tom Tromey a008792038 Fix pager bugs with style output
I believe this fixes all the pager output problems with styling that
Philippe pointed out, plus at least one more.  The patch is somewhat
hard to reason about, so you may wish to give it a try.  Even writing
the tests was hard.

This removes the style caching, because it was difficult to keep the
style cache correct in all cases.  Since this would cause more style
escapes to be emitted, instead it changes fputs_styled to try to avoid
unnecessary changes.

Another bug was that the wrap buffer was not flushed in the case where
wrap_column==0.  In the old (pre-patch series) code, characters were
directly emitted in this case; so flushing the wrap buffer here
restores this behavior.

On error the wrap buffer must be emptied.  Otherwise, interrupting
output can leave characters in the buffer that will be emitted later.

As discussed on gdb-patches, this fixes the ada-lang.c problem where
filtered and unfiltered printing were mixed.  Now user_select_syms
uses filtered printing, which is what its callees were already doing.

Finally, it was possible for source line highlighting to be garbled
(and invalid escape sequences emitted) if the pager was invoked at the
wrong spot.  To fix this, the patch arranges for source line escapes
to always be emitted as a unit.

gdb/ChangeLog
2019-02-17  Tom Tromey  <tom@tromey.com>

	* ada-lang.c (user_select_syms): Use filtered printing.
	* utils.c (wrap_style): New global.
	(desired_style): Remove.
	(emit_style_escape): Add stream parameter.
	(set_output_style, reset_terminal_style, prompt_for_continue):
	Update.
	(flush_wrap_buffer): Only flush gdb_stdout.
	(wrap_here): Set wrap_style.
	(fputs_maybe_filtered): Clear the wrap buffer on exception.  Don't
	treat escape sequences as a character.  Change when wrap buffer is
	flushed.
	(fputs_styled): Do not set the output style when the default is
	requested.
	* ui-style.h (struct ui_file_style) <is_default>: New method.
	* source.c (print_source_lines_base): Emit escape sequences in one
	piece.

gdb/testsuite/ChangeLog
2019-02-17  Tom Tromey  <tom@tromey.com>

	* gdb.base/style.exp: Add line-wrapping tests.
	* gdb.base/page.exp: Add test for quitting during pagination.
2019-02-17 08:35:14 -07:00
Joel Brobecker 75ba10dc55 type_align: handle range types the same as ints and enums
This commit enhances type_align to handle TYPE_CODE_RANGE types
the same as integers and enums, rather than returning zero,
which means for this function that it could not determine its
alignment.

gdb/ChangeLog:

	* gdbtypes.c (type_align): Handle TYPE_CODE_RANGE the same as
        integers and enumeration types.

Tested on x86_64-linux. Also tested on a variety of platforms
(with CPUs being ARM, AArch64, Leon3 (SPARC-like), PowerPC,
PowerPC64, RV64, Visium, x86, x86_64).
2019-02-17 10:04:57 -05:00
Joel Brobecker a2cd4f1475 (Ada) fix GDB crash printing packed array
Trying to print a packed array sometimes leads to a crash (see
attached testcase for an example of when this happens):

  | (gdb) p bad
  | [1]    65571 segmentation fault  gdb -q foo

Variable "bad" is declared in the debug information as an array where
the array's type name has an XPnnn suffix:

  | .uleb128 0xc    # (DIE (0x566) DW_TAG_typedef)
  | .long   .LASF200        # DW_AT_name: "pck__t___XP1"
  | [loc info attributes snipped]
  | .long   0x550   # DW_AT_type
  | .byte   0x1     # DW_AT_alignment

The signals to GDB that the debugging information follows a GNAT encoding
used for packed arrays, and an in order to decode it, we need to find
the type whose name is the same minus the "___XPnnn" suffix: "pck__t".

For that, we make a call to ada-lang.c::standard_lookup, which is
a simple function which essentially does:

  | /* Return the result of a standard (literal, C-like) lookup of NAME in
  |    given DOMAIN, visible from lexical block BLOCK.  */
  |
  |   [...]
  |   sym = lookup_symbol_in_language (name, block, domain, language_c, 0);

Unfortunately for us, while the intent of this call was to perform
an exact-match lookup, in our case, it returns ... type pck__t___XP1
instead! In other words, it finds itself back. The reason why it finds
this type is a confluence of two factors:

  (1) Forcing the lookup into language_c currently does not affect
      how symbol matching is done anymore, because we look at the symbol's
      language to determine which kind of matching should be done;

  (2) The lookup searches the local context (via block) first, beforei
      doing a more general lookup. And looking at the debug info for
      the main subprogram, we see that type "pck__t" is not declared
      there, only in the debug info for pck.ads. In other words,
      there is no way that we accidently find "pck__t" by random chance.

I believe Pedro added a new function called ada_lookup_encoded_symbol
for that specific purpose, so I started by replacing the lookup
by language above by this. Unfortunately, still no joy.

This was because, even though ada_lookup_encoded_symbol puts angle-
brackets around the search name to signal that we want a verbatim
search, we end up losing that information in the function called
to compare a symbol with the search name:

  | static bool
  | do_full_match (const char *symbol_search_name,
  |                const lookup_name_info &lookup_name,
  |                completion_match_result *comp_match_res)
  | {
  |   return full_match (symbol_search_name, ada_lookup_name (lookup_name));
                                             ^^^^^^^^^^^^^^^
                                                    |
                                    <=> lookup_name.m_ada.m_encoded_name
                                           (no angle brackets)

The way I fixed this was by introducing a new function called
do_exact_match, and then adjust ada_get_symbol_name_matcher to
return that function when seeing that we have a verbatim non-wild-match
search.

As it happens, this fixes an incorrect test in gdb.ada/homony.exp,
where we were inserting a breakpoint on a symbol using the angle-brackets
notation, and got 2 locations for that breakpoint...

    (gdb) b <homonym__get_value>
    Breakpoint 1 at 0x4029fc: <homonym__get_value>. (2 locations)

...  each location being in a different function:

    (gdb) info break
    Num     Type           Disp Enb Address            What
    1       breakpoint     keep y   <MULTIPLE>
    1.1                         y   0x00000000004029fc in homonym.get_value
                                    at /[...]/homonym.adb:32
    1.2                         y   0x0000000000402a3a in homonym.get_value
                                    at /[...]/homonym.adb:50
    (gdb) x /i 0x00000000004029fc
       0x4029fc <homonym__get_value+8>:     movl   $0x1d,-0x4(%rbp)
    (gdb) x /i 0x0000000000402a3a
       0x402a3a <homonym__get_value__2+8>:  movl   $0x11,-0x4(%rbp)

Since we used angle-brackets, we shouldn't be matching the second one,
something this patch fixes.

gdb/ChangeLog:

        * ada-lang.c (standard_lookup): Use ada_lookup_encoded_symbol
        instead of lookup_symbol_in_language
        (do_exact_match): New function.
        (ada_get_symbol_name_matcher): Return do_exact_match when
        doing a verbatim match.

gdb/testsuite/ChangeLog:

        * gdb.ada/big_packed_array: New testcase.
        * gdb.ada/homonym.exp: Fix incorrect expected output for
        "break <homonym__get_value>" test.

Tested on x86_64-linux.
2019-02-17 08:32:45 -05:00
GDB Administrator aa9e1dc0c6 Automatic date update in version.in 2019-02-17 00:01:01 +00:00
GDB Administrator 166e5d9d41 Automatic date update in version.in 2019-02-16 00:01:06 +00:00
Tom Tromey 485b851b68 Special-case wildcard requests in ravenscar-thread.c
ravenscar-thread.c intercepts resume and wait target requests and
replaces the requested ptid with the ptid of the underlying CPU.
However, this is incorrect when a request is made with a wildcard
ptid.

This patch adds a special case to ravenscar-thread.c for
minus_one_ptid.  I don't believe a special case for process wildcards
is necessary, so I have not added that.

Joel's description explains the bug well:

At the user level, we noticed the issue because we had a test were
we insert a breakpoint one some code which is only run from, say,
CPU #2, whereas we unfortunately resumed the execution after having
stopped somewhere in CPU #1. As a result, we sent an order to resume
CPU #1, which starves CPU #2 forever, because the code in CPU #1
waits for some of the Ada tasks allocated to CPU #2 (and we never
reach our breakpoint either).

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c (ravenscar_thread_target::resume)
	(ravenscar_thread_target::wait): Special case wildcard requests.
2019-02-15 13:53:43 -07:00
Tom Tromey 0b790b1eeb Make the ravenscar thread target multi-target-ready
This changes ravenscar-thread.c to make it ready for multi-target.
This is done by moving globals into the target, and then arranging to
allocate the target with "new" and delete the target in its "close"
method.

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c (base_ptid): Remove.
	(struct ravenscar_thread_target) <close>: New method.
	<m_base_ptid>: New member.
	<update_inferior_ptid, active_task, task_is_currently_active,
	runtime_initialized>: Declare methods.
	<ravenscar_thread_target>: Add constructor.
	(ravenscar_thread_target::task_is_currently_active)
	(ravenscar_thread_target::update_inferior_ptid)
	(ravenscar_runtime_initialized): Rename.  Now methods.
	(ravenscar_thread_target::resume, ravenscar_thread_target::wait)
	(ravenscar_thread_target::update_thread_list): Update.
	(ravenscar_thread_target::active_task): Now method.
	(ravenscar_thread_target::store_registers)
	(ravenscar_thread_target::prepare_to_store)
	(ravenscar_thread_target::prepare_to_store)
	(ravenscar_thread_target::mourn_inferior): Update.
	(ravenscar_inferior_created): Use "new" to create target.
	(ravenscar_thread_target::get_ada_task_ptid): Update.
	(_initialize_ravenscar): Don't initialize base_ptid.
	(ravenscar_ops): Remove global.
2019-02-15 13:53:43 -07:00
Tom Tromey dea57a6263 Add push_target overload
This adds a push_target overload that takes a "target_ops_up &&".
This removes some calls to release a target_ops_up, and makes the
intent here clearer.

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* target.h (push_target): Declare new overload.
	* target.c (push_target): New overload, taking an rvalue reference.
	* remote.c (remote_target::open_1): Use push_target overload.
	* corelow.c (core_target_open): Use push_target overload.
2019-02-15 13:53:43 -07:00
Tom Tromey 989f3c583d Minor C++-ification in ravenscar-thread.c
This changes some functions in ravenscar-thread.c to return "bool"
rather than int, where appropriate, and also changes "(void)" to "()".

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c (is_ravenscar_task)
	(ravenscar_task_is_currently_active): Return bool.
	(ravenscar_update_inferior_ptid, get_running_thread_msymbol)
	(_initialize_ravenscar): Remove "(void)".
	(has_ravenscar_runtime, ravenscar_runtime_initialized): Likewise.
	Return bool.
2019-02-15 13:53:43 -07:00
Tom Tromey 6cbcc006e9 Fix formatting in ravenscar-thread.c
This fixes some incorrect formatting in ravenscar-thread.c.

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c (ravenscar_runtime_initializer)
	(has_ravenscar_runtime, get_running_thread_id)
	(ravenscar_thread_target::resume): Fix indentation.
2019-02-15 13:53:42 -07:00
Tom Tromey 7657f14df7 C++-ify ravenscar_arch_ops
This turns ravenscar_arch_ops into an abstract base class and updates
all the places where it is used.  This is an improvement because it
avoids any possibility of forgetting to set one of the function
pointers.  It also makes clear that these functions aren't intended to
be changed dynamically.

This version of the patch removes the prepare_to_store method, as it
is unused, and it is easy enough to add if it is ever needed.

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* sparc-ravenscar-thread.c (struct sparc_ravenscar_ops): Derive
	from ravenscar_arch_ops.
	(sparc_ravenscar_ops::fetch_registers)
	(sparc_ravenscar_ops::store_registers): Now methods.
	(sparc_ravenscar_prepare_to_store): Remove.
	(sparc_ravenscar_ops): Redefine.
	* ravenscar-thread.h (struct ravenscar_arch_ops): Add virtual
	methods and destructor.  Remove members.
	* ravenscar-thread.c (ravenscar_thread_target::fetch_registers)
	(ravenscar_thread_target::store_registers)
	(ravenscar_thread_target::prepare_to_store): Update.
	* ppc-ravenscar-thread.c (ppc_ravenscar_generic_prepare_to_store):
	Remove.
	(struct ppc_ravenscar_powerpc_ops): Derive from
	ravenscar_arch_ops.
	(ppc_ravenscar_powerpc_ops::fetch_registers)
	(ppc_ravenscar_powerpc_ops::store_registers): Now methods.
	(ppc_ravenscar_powerpc_ops): Redefine.
	(struct ppc_ravenscar_e500_ops): Derive from ravenscar_arch_ops.
	(ppc_ravenscar_e500_ops::fetch_registers)
	(ppc_ravenscar_e500_ops::store_registers): Now methods.
	(ppc_ravenscar_e500_ops): Redefine.
	* aarch64-ravenscar-thread.c
	(aarch64_ravenscar_generic_prepare_to_store): Remove.
	(struct aarch64_ravenscar_ops): Derive from ravenscar_arch_ops.
	(aarch64_ravenscar_fetch_registers)
	(aarch64_ravenscar_store_registers): Now methods.
	(aarch64_ravenscar_ops): Redefine.
2019-02-15 13:53:42 -07:00
Tom Tromey 5b6ea500d5 Exception safety in ravenscar-thread.c
This changes some code in ravenscar-thread.c to use scoped_restore.  I
am not sure if it matters in practice, but this makes these methods
exception-safe in case the methods lower in the target stack can
throw.

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c (ravenscar_thread_target::stopped_by_sw_breakpoint)
	(ravenscar_thread_target::stopped_by_hw_breakpoint)
	(ravenscar_thread_target::stopped_by_watchpoint)
	(ravenscar_thread_target::stopped_data_address)
	(ravenscar_thread_target::core_of_thread): Use scoped_restore.
2019-02-15 13:53:42 -07:00
Tom Tromey e397fd39c6 Fix some typos in ravenscar-thread.c
This fixes some typos I noticed in ravenscar-thread.c.

gdb/ChangeLog
2019-02-15  Tom Tromey  <tromey@adacore.com>

	* ravenscar-thread.c: Fix some typos.
2019-02-15 13:53:42 -07:00
Tom Tromey cc12f4a8f9 Fix memory leak in create_ada_exception_catchpoint
Phillipe noticed that create_ada_exception_catchpoint was not freeing
the "addr_string" memory:

==14141== 114 bytes in 4 blocks are definitely lost in loss record 1,054 of 3,424
==14141==    at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==14141==    by 0x405107: xmalloc (common-utils.c:44)
==14141==    by 0x7563F9: xstrdup (xstrdup.c:34)
==14141==    by 0x381B21: ada_exception_sal (ada-lang.c:13217)
==14141==    by 0x381B21: create_ada_exception_catchpoint(gdbarch*, ada_exception_catchpoint_kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int, int) (ada-lang.c:13251)
==14141==    by 0x3820A8: catch_ada_exception_command(char const*, int, cmd_list_element*) (ada-lang.c:13285)
==14141==    by 0x3F4828: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)

This patch fixes the problem by changing ada_exception_sal to return a
std::string via its out parameter.

gdb/ChangeLog
2019-02-15  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
	    Tom Tromey  <tromey@adacore.com>

	* ada-lang.c (ada_exception_sal): Change addr_string to a
	std::string.
	(create_ada_exception_catchpoint): Update.
2019-02-15 13:21:39 -07:00
Tom Tromey 5f48666010 C++-ify bp_location
Philippe noticed a memory leak coming from ada_catchpoint_location --
it was not freeing the "function_name" member from its base class:

==14141== 114 bytes in 4 blocks are definitely lost in loss record 1,055 of 3,424
==14141==    at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==14141==    by 0x405107: xmalloc (common-utils.c:44)
==14141==    by 0x7563F9: xstrdup (xstrdup.c:34)
==14141==    by 0x3B82B3: set_breakpoint_location_function(bp_location*, int) (breakpoint.c:7156)
==14141==    by 0x3C112B: add_location_to_breakpoint(breakpoint*, symtab_and_line const*) (breakpoint.c:8609)
==14141==    by 0x3C127A: init_raw_breakpoint(breakpoint*, gdbarch*, symtab_and_line, bptype, breakpoint_ops const*) (breakpoint.c:7187)
==14141==    by 0x3C1B52: init_ada_exception_breakpoint(breakpoint*, gdbarch*, symtab_and_line, char const*, breakpoint_ops const*, int, int, int) (breakpoint.c:11262)
==14141==    by 0x381C2E: create_ada_exception_catchpoint(gdbarch*, ada_exception_catchpoint_kind, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, int, int) (ada-lang.c:13255)

This patch fixes the problem by further C++-ifying bp_location.  In
particular, bp_location_ops is now removed, and the "dtor" function
pointer is replaced with an ordinary destructor.

gdb/ChangeLog
2019-02-15  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
	    Tom Tromey  <tromey@adacore.com>

	* breakpoint.c (~bp_location): Rename from bp_location_dtor.
	(bp_location_ops): Remove.
	(base_breakpoint_allocate_location): Update.
	(free_bp_location): Update.
	* ada-lang.c (class ada_catchpoint_location)
	<ada_catchpoint_location>: Remove ops parameter.
	(ada_catchpoint_location_dtor): Remove.
	(ada_catchpoint_location_ops): Remove.
	(allocate_location_exception): Update.
	* breakpoint.h (struct bp_location_ops): Remove.
	(class bp_location) <bp_location>: Remove bp_location_ops
	parameter.
	<~bp_location>: Add destructor.
	<ops>: Remove.
2019-02-15 13:21:29 -07:00
Saagar Jha 91d78b8179 Use the correct name for various MACH-O based operating systems in comments.
include	* mach-o/loader.h: Use new OS names in comments.
2019-02-15 12:50:52 +00:00
GDB Administrator 99df80f894 Automatic date update in version.in 2019-02-15 00:01:15 +00:00
Weimin Pan 9d70ffbc5b Updating test case
gdb.arch/aarch64-dbreg-contents.exp:
 * Replaced "run" with "runto_main + continue".
 * Replaced "gdb_compile + clean_restart" with "prepare_for_testing".
 * Added comment for case "exited with code 01".

gdb.arch/aarch64-dbreg-contents.c:
 * Removed SET_WATCHPOINT marco.
 * Removed redundent cleanup ().
 * Cleaned up comment.
2019-02-14 22:27:43 +00:00
Thomas Schwinge abc163a464 [ld, hurd] Remove 'ld-elf/elf.exp' XFAILs
... as a follow-up to commit d981640286 "Run more
ld tests when not native", which replaced by a proper solution the following
mess before present in 'ld/configure.host':

    -*-*-gnu*)
    -  # When creating static executables, we ought to use crt0.o instead of crt1.o,
    -  # <http://www.gnu.org/software/hurd/open_issues/binutils.html#static>,
    -  # but the testing infrastructure is not prepared for that.  This is not
    -  # relevant for most tests, and the few remaining ones have been XFAILed.
    -  HOSTING_CRT0='[...]'
    -  HOSTING_LIBS='[...]'

	ld/
	* testsuite/ld-elf/elf.exp: Remove Hurd XFAILs.
2019-02-14 17:51:22 +01:00
Thomas Schwinge b671c7fb21 [gdb, hurd] Avoid using 'PATH_MAX' in 'gdb/remote.c'
..., which is not defined in GNU/Hurd systems, and so commit
94585166df "Extended-remote follow-exec" caused:

    [...]/gdb/remote.c: In member function 'void remote_target::remote_parse_stop_reply(const char*, stop_reply*)':
    [...]/gdb/remote.c:7343:22: error: 'PATH_MAX' was not declared in this scope
            char pathname[PATH_MAX];
                          ^~~~~~~~

	gdb/
	* remote.c (remote_target::remote_parse_stop_reply): Avoid using
	'PATH_MAX'.
2019-02-14 17:40:19 +01:00
David Michael 8071c5ce78 [gdb, hurd] Adjust to Hurd "proc" interface changes
Hurd's commit baf7e5c8ce176aead15c2559952d8bdf0da41ffd "hurd: Use polymorphic
port types to return some rights" causes in the GDB build:

    /usr/bin/ld: process_reply_S.o: in function `_Xproc_pid2proc_reply':
    [...]/gdb/process_reply_S.c:754: undefined reference to `S_proc_pid2proc_reply'
    /usr/bin/ld: [...]/gdb/process_reply_S.c:730: undefined reference to `S_proc_pid2proc_reply'
    /usr/bin/ld: process_reply_S.o: in function `_Xproc_task2proc_reply':
    [...]/gdb/process_reply_S.c:589: undefined reference to `S_proc_task2proc_reply'
    /usr/bin/ld: [...]/gdb/process_reply_S.c:565: undefined reference to `S_proc_task2proc_reply'
    /usr/bin/ld: process_reply_S.o: in function `_Xproc_getmsgport_reply':
    [...]/gdb/process_reply_S.c:204: undefined reference to `S_proc_getmsgport_reply'
    /usr/bin/ld: [...]/gdb/process_reply_S.c:180: undefined reference to `S_proc_getmsgport_reply'
    collect2: error: ld returned 1 exit status

	gdb/
	* gnu-nat.c (S_proc_getmsgport_reply, S_proc_task2proc_reply)
	(S_proc_pid2proc_reply): Adjust to Hurd "proc" interface changes.
2019-02-14 17:29:55 +01:00
Thomas Schwinge 924514e11c [gdb, hurd] Address "ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]" diagnostics
... that appeared with 9bf2a70066
"-Wwrite-strings: Remove -Wno-write-strings".

	gdb/
	* gnu-nat.c (gnu_write_inferior, parse_int_arg, _parse_bool_arg)
	(check_empty): Use "const char *".
2019-02-14 17:14:33 +01:00
Thomas Schwinge c29ee8d45e [gdb, hurd] Repair build after "Use thread_info and inferior pointers more throughout"
..., that is commit 00431a78b2 causing:

    [...]/gdb/gnu-nat.c: In member function 'virtual void gnu_nat_target::detach(inferior*, int)':
    [...]/gdb/gnu-nat.c:2284:23: error: invalid conversion from 'int' to 'inferior*' [-fpermissive]
       detach_inferior (pid);
                           ^
    In file included from [...]/gdb/gnu-nat.c:61:0:
    [...]/gdb/inferior.h:523:13: note:   initializing argument 1 of 'void detach_inferior(inferior*)'
     extern void detach_inferior (inferior *inf);
                 ^~~~~~~~~~~~~~~

Fixed by inlining the removed code.

	gdb/
	* gnu-nat.c (gnu_nat_target::detach): Instead of
	'detach_inferior (pid)' call
	'detach_inferior (find_inferior_pid (pid))'.
2019-02-14 16:40:36 +01:00
Thomas Schwinge 6c6ef69fb4 [gdb, hurd] Repair build after "Share fork_inferior et al with gdbserver" changes
..., that is commit 2090129c36 causing:

    [...]/gdb/gnu-nat.c: In function 'void gnu_ptrace_me()':
    [...]/gdb/gnu-nat.c:2133:5: error: 'trace_start_error_with_name' was not declared in this scope
         trace_start_error_with_name ("ptrace");
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
    [...]/gdb/gnu-nat.c:2133:5: note: suggested alternative: 'throw_perror_with_name'
         trace_start_error_with_name ("ptrace");
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
         throw_perror_with_name
    [...]/gdb/gnu-nat.c: In function 'void gnu_create_inferior(target_ops*, const char*, const string&, char**, int)':
    [...]/gdb/gnu-nat.c:2147:9: error: 'fork_inferior' was not declared in this scope
       pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me,
             ^~~~~~~~~~~~~
    [...]/gdb/gnu-nat.c:2147:9: note: suggested alternative: 'exit_inferior'
       pid = fork_inferior (exec_file, allargs, env, gnu_ptrace_me,
             ^~~~~~~~~~~~~
             exit_inferior
    [...]/gdb/gnu-nat.c:2174:30: error: 'START_INFERIOR_TRAPS_EXPECTED' was not declared in this scope
       gdb_startup_inferior (pid, START_INFERIOR_TRAPS_EXPECTED);
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    /usr/bin/ld: gnu-nat.o: in function `gnu_ptrace_me()':
    [...]/gdb/gnu-nat.c:2134: undefined reference to `trace_start_error_with_name(char const*)'
    /usr/bin/ld: gnu-nat.o: in function `gnu_create_inferior(target_ops*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, int)':
    [...]/gdb/gnu-nat.c:2148: undefined reference to `fork_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char**, void (*)(), void (*)(int), void (*)(), char const*, void (*)(char const*, char* const*, char* const*))'
    /usr/bin/ld: fork-child.o: in function `gdb_startup_inferior(int, int)':
    [...]/gdb/fork-child.c:136: undefined reference to `startup_inferior(int, int, target_waitstatus*, ptid_t*)'
    collect2: error: ld returned 1 exit status

	gdb/
	* configure.nat [gdb_host == i386gnu] (NATDEPFILES): Add
	'nat/fork-inferior.o'.
	* gnu-nat.c: #include "nat/fork-inferior.h".
2019-02-14 16:36:05 +01:00
Thomas Schwinge 2d0a338c7c [gdb, hurd] Repair build after "Convert struct target_ops to C++" changes
..., that is commit f6ac5f3d63 causing:

    In file included from [...]/gdb/gnu-nat.c:24:0:
    [...]/gdb/gnu-nat.h:123:1: error: expected class-name before '{' token
     {
     ^
    [...]/gdb/gnu-nat.h:128:16: error: 'inferior' has not been declared
       void detach (inferior *, int) override;
                    ^~~~~~~~
    [...]/gdb/gnu-nat.h:132:8: error: use of enum 'target_xfer_status' without previous declaration
       enum target_xfer_status xfer_partial (enum target_object object,
            ^~~~~~~~~~~~~~~~~~
    [...]/gdb/gnu-nat.h:132:46: error: use of enum 'target_object' without previous declaration
       enum target_xfer_status xfer_partial (enum target_object object,
                                                  ^~~~~~~~~~~~~
    [...]/gdb/gnu-nat.h:124:8: error: 'void gnu_nat_target::attach(const char*, int)' marked 'override', but does not override
       void attach (const char *, int) override;
            ^~~~~~
    [...]

    [...]/gdb/gnu-nat.c: In member function 'virtual void gnu_nat_target::detach(inferior*, int)':
    [...]/gdb/gnu-nat.c:2286:34: error: 'ops' was not declared in this scope
       inf_child_maybe_unpush_target (ops);
                                      ^~~
    [...]/gdb/gnu-nat.c:2286:34: note: suggested alternative: 'open'
       inf_child_maybe_unpush_target (ops);
                                      ^~~
                                      open
    [...]/gdb/gnu-nat.c:2286:3: error: 'inf_child_maybe_unpush_target' was not declared in this scope
       inf_child_maybe_unpush_target (ops);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    [...]/gdb/gnu-nat.c:2286:3: note: suggested alternative: 'maybe_unpush_target'
       inf_child_maybe_unpush_target (ops);
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       maybe_unpush_target

    [...]/gdb/i386-gnu-nat.c:200:1: warning: 'void gnu_store_registers(target_ops*, regcache*, int)' defined but not used [-Wunused-function]
     gnu_store_registers (struct target_ops *ops,
     ^~~~~~~~~~~~~~~~~~~
    [...]/gdb/i386-gnu-nat.c:109:1: warning: 'void gnu_fetch_registers(target_ops*, regcache*, int)' defined but not used [-Wunused-function]
     gnu_fetch_registers (struct target_ops *ops,
     ^~~~~~~~~~~~~~~~~~~
    [...]
    /usr/bin/ld: i386-gnu-nat.o:(.data.rel+0x0): undefined reference to `vtable for i386_gnu_nat_target'
    collect2: error: ld returned 1 exit status

	gdb/
	* gnu-nat.c (gnu_nat_target::detach): Instead of
	'inf_child_maybe_unpush_target (ops)' call 'maybe_unpush_target'.
	* gnu-nat.h: #include "inf-child.h".
	* i386-gnu-nat.c (gnu_fetch_registers): Rename/move to
	'i386_gnu_nat_target::fetch_registers'.
	(gnu_store_registers): Rename/move to
	'i386_gnu_nat_target::store_registers'.
2019-02-14 16:22:42 +01:00
Thomas Schwinge cabb5f067d [gdb, hurd] Work around conflict between Mach's 'thread_info' function, and GDB's 'thread_info' class
In file included from ./nm.h:25:0,
                     from [...]/gdb/defs.h:423,
                     from [...]/gdb/gdb.c:19:
    [...]/gdb/regcache.h:35:46: warning: 'get_thread_regcache' initialized and declared 'extern'
     extern struct regcache *get_thread_regcache (thread_info *thread);
                                                  ^~~~~~~~~~~
    [...]/gdb/regcache.h:35:46: error: 'regcache* get_thread_regcache' redeclared as different kind of symbol
    [...]
    [...]/gdb/gdbarch.h:1203:69: error: 'thread_info' is not a type
     extern LONGEST gdbarch_get_syscall_number (struct gdbarch *gdbarch, thread_info *thread);
                                                                         ^~~~~~~~~~~

Fixed with a different (self-contained, more maintainable?) approach compared
to what has been done in commit 7aabaf9d4a
"Create private_thread_info hierarchy", and commit
75cbc781e3 "gdb: For macOS, s/thread_info/struct
thread_info/".  We don't want to change all the GDB code to everywhere use
'class thread_info' or 'struct thread_info' instead of plain 'thread_info'.

	gdb/
	* config/i386/nm-i386gnu.h: Don't "#include" any files.
	* gnu-nat.h (mach_thread_info): New function.
	* gnu-nat.c (thread_takeover_sc_cmd): Use it.
2019-02-14 16:02:33 +01:00
Thomas Schwinge b1041ae0ae [gdb, hurd] Remove long obsolete 'gnu_target_pid_to_str' function declaration
... for function definition removed/renamed in 1999.  ;-)

	gdb/
	* config/i386/nm-i386gnu.h (gnu_target_pid_to_str): Remove.
2019-02-14 15:45:16 +01:00
KONRAD Frederic 2988d01ea5 (riscv/ada) fix error when calling functions with range argument
Using the gdb.ada/call_pn.exp testcase, and running it by hand on
riscv64-elf, we get the following error:

    (gdb) call pn(55)
    Could not compute alignment of type

The problem occurs because the parameter's type is a TYPE_CODE_RANGE,
and that type code is not handled by riscv_type_alignment. So this patch
fixes the issue by handling TYPE_CODE_RANGE the same way we handle other
integral types.

gdb/ChangeLog:

        * riscv-rdep.c (riscv_type_alignment): Handle TYPE_CODE_RANGE.

Tested on riscv64-elf using AdaCore's testsuite.
2019-02-13 22:37:11 -05:00
Joel Brobecker c559d7096b (Windows) remove thread notification for main thread of inferior
This is a followup on a recent patch which, among other things
introduced the exit notification of the main thread in order
to be symetrical with the fact that a thread notification was
emitted before signaling its creation.

This patch takes the opposite approach of removing both creation
and exit notifications for that main thread, which is consistent
with what is done on other platforms such as GNU/Linux for instance.

gdb/ChangeLog

	* windows-nat.c (windows_add_thread): Add new parameter
	"main_thread_p" with default value set to false.  Update
	function documentation as well as all callers.
	(windows_delete_thread): Likewise.
	(fake_create_process): Update call to windows_add_thread.
	(get_windows_debug_event) <CREATE_THREAD_DEBUG_EVENT>
	<CREATE_PROCESS_DEBUG_EVENT>: Likewise.
	<EXIT_THREAD_DEBUG_EVENT, EXIT_PROCESS_DEBUG_EVENT>: Update
	call to windows_delete_thread.

Tested on x86-windows (MinGW) using AdaCore's testsuite.
2019-02-14 07:13:26 +04:00
GDB Administrator e6e006612f Automatic date update in version.in 2019-02-14 00:00:28 +00:00
Simon Marchi 007024cc6a Add Andrew Burgess as global maintainer of gdb/ and sim/ 2019-02-13 16:56:21 -05:00