Tom Tromey [Thu, 14 Feb 2019 14:58:58 +0000 (07:58 -0700)]
Use upper case for metasyntactic variables in "help find"
While answering a user's question on irc, I realized that the
metasyntactic variables in "help find" are not in upper case. As you
know this is one of my pet quests, so here is a patch to fix this.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-02-20 Tom Tromey <tromey@adacore.com>
* findcmd.c (_initialize_mem_search): Use upper case for
metasyntactic variables.
Max Filippov [Sat, 16 Feb 2019 00:43:23 +0000 (16:43 -0800)]
bfd: xtensa: fix callx relaxation
Big section alignment requirements between source and destination of a
long call can result in making call range bigger than what's reachable
by the call opcode. Add biggest section alignment of sections between
the call site and call destination to the call distance when making
long call relaxation decision.
2019-02-20 Eric Tsai <erictsai@cadence.com>
bfd/
* elf32-xtensa.c (is_resolvable_asm_expansion): Scan output
sections between the call site and call destination and adjust
call distance by the largest alignment.
ld/
* testsuite/ld-xtensa/call_overflow.d: New test definition.
* testsuite/ld-xtensa/call_overflow1.s: New test source.
* testsuite/ld-xtensa/call_overflow2.s: New test source.
* testsuite/ld-xtensa/call_overflow3.s: New test source.
* testsuite/ld-xtensa/xtensa.exp: Add call_overflow test.
Alan Modra [Wed, 20 Feb 2019 07:52:50 +0000 (18:22 +1030)]
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.
Simon Marchi [Wed, 20 Feb 2019 02:10:18 +0000 (21:10 -0500)]
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.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.
Alan Modra [Tue, 19 Feb 2019 21:51:24 +0000 (08:21 +1030)]
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.
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.
Tom Tromey [Fri, 15 Feb 2019 21:05:38 +0000 (14:05 -0700)]
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>
Andrew Burgess [Mon, 18 Feb 2019 18:10:09 +0000 (18:10 +0000)]
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.
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.
Tom Tromey [Fri, 8 Feb 2019 08:40:39 +0000 (01:40 -0700)]
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>
Tom Tromey [Mon, 28 Jan 2019 20:21:35 +0000 (13:21 -0700)]
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>
Tom Tromey [Thu, 7 Feb 2019 13:23:40 +0000 (06:23 -0700)]
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.
Joel Brobecker [Sun, 17 Feb 2019 15:04:57 +0000 (10:04 -0500)]
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).
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:
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.
Tom Tromey [Wed, 6 Feb 2019 14:14:40 +0000 (15:14 +0100)]
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.
Tom Tromey [Wed, 6 Feb 2019 10:06:49 +0000 (03:06 -0700)]
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.
Tom Tromey [Wed, 6 Feb 2019 09:54:17 +0000 (02:54 -0700)]
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.
Tom Tromey [Tue, 5 Feb 2019 10:08:02 +0000 (03:08 -0700)]
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.
Tom Tromey [Tue, 5 Feb 2019 09:57:21 +0000 (02:57 -0700)]
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.
Tom Tromey [Wed, 13 Feb 2019 12:42:18 +0000 (05:42 -0700)]
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.
Tom Tromey [Tue, 12 Feb 2019 21:28:07 +0000 (14:28 -0700)]
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>
Weimin Pan [Thu, 14 Feb 2019 22:20:36 +0000 (22:20 +0000)]
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".
Thomas Schwinge [Fri, 29 Jun 2018 19:05:29 +0000 (21:05 +0200)]
[ld, hurd] Remove 'ld-elf/elf.exp' XFAILs
... as a follow-up to commit d98164028637041c5de99af0d057bde3f168a8a8 "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='[...]'
[...]/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'.
/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: 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);
^~~~~~~~~~~~~~~
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'.
Thomas Schwinge [Wed, 13 Feb 2019 11:02:20 +0000 (12:02 +0100)]
[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 7aabaf9d4ad52a1df1f551908fbd8cafc5e7597a
"Create private_thread_info hierarchy", and commit 75cbc781e371279f4403045be93b07fd8fe7fde5 "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.
KONRAD Frederic [Thu, 14 Feb 2019 03:37:11 +0000 (22:37 -0500)]
(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.
Joel Brobecker [Thu, 14 Feb 2019 03:13:26 +0000 (07:13 +0400)]
(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.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Try to use the canonical version of a sysroot for debug file links.
Object file paths passed to find_separate_debug_file are always
canonical paths with symbolic links resolved. If a sysroot path
traverses a symbolic link, it will not match the object file paths.
Generate a canonical version of the sysroot directory. If it is
valid, use it instead of gdb_sysroot with child_path to determine if
an object file is under a system root.
gdb/ChangeLog:
* symfile.c (find_separate_debug_file): Use canonical path of
sysroot with child_path instead of gdb_sysroot if it is valid.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Use child_path to determine if an object file is under a sysroot.
This fixes the case where the sysroot happens to end in a trailing
'/'. Note that the path returned from child_path always skips over
the directory separator at the start of the base path, so a separator
must always be explicitly added before the base path.
gdb/ChangeLog:
* symfile.c (find_separate_debug_file): Use child_path to
determine if an object file is under a sysroot.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Add a new function child_path.
child_path returns a pointer to the first component in a child path
that comes after a parent path. This does not depend on trying to
stat() the paths since they may describe remote paths but instead
relies on filename parsing. The function requires that the child path
describe a filename that contains at least one component below the
parent path and returns a pointer to the first component.
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
unittests/child-path-selftests.c.
* common/pathstuff.c (child_path): New function.
* common/pathstuff.h (child_path): New prototype.
* unittests/child-path-selftests.c: New file.
John Baldwin [Tue, 12 Feb 2019 21:56:16 +0000 (13:56 -0800)]
Look for separate debug files in debug directories under a sysroot.
When an object file is present in a system root, GDB currently looks
for separate debug files under the global debugfile directories. For
example, if the sysroot is set to "/myroot" and hte global debugfile
directory is set to "/usr/lib/debug", GDB will look for a separate
debug file for "/myroot/lib/libc.so.7" in the following paths:
However, some system roots include a full system installation
including a nested global debugfile directory under the sysroot. This
patch adds an additional check to support such systems. In the
example above the additional path searched is:
/myroot/usr/lib/debug/lib/libc.so.7.debug
To try to preserve existing behavior as much as possible, this new
path is searched last for each global debugfile directory.
gdb/ChangeLog:
* symfile.c (find_separate_debug_file): Look for separate debug
files in debug directories under the sysroot.
Note that print_msymbol_info does not (yet?) print data msymbol
using variable_name_style, as otherwise 'info variables'
would show the non debugging symbols in variable name style,
but 'real' variables would be not styled.
2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* symtab.h (struct minimal_symbol data_p): New const method.
(struct minimal_symbol text_p): Likewise.
* symtab.c (output_source_filename): Use file name style
to print file name.
(print_symbol_info): Likewise.
(print_msymbol_info): Use address style to print addresses.
Use function name style to print executable text symbols.
(expand_symtab_containing_pc): Use data_p.
(find_pc_sect_compunit_symtab): Likewise.
Use function_name_style to print Ada and C function names
Note that ada-typeprint.c print_func_type is called with
types representing functions and is also called to print
a function NAME together with its type. In such a case, the function
name will be printed using function name style.
Similarly, c_print_type_1 is called to print a type, optionally
with the name of an object of this type in the VARSTRING arg.
So, c_print_type_1 uses function name style to print varstring
when the type code indicates that c_print_type_1 TYPE is some
'real code'.
gdb/ChangeLog
2019-02-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* ada-typeprint.c (print_func_type): Print function name
style to print function name.
* c-typeprint.c (c_print_type_1): Likewise.
tromey [Tue, 12 Feb 2019 13:02:48 +0000 (13:02 +0000)]
Fix splay tree KEY leak detected in GDB test gdb.base/macscp.exp
When a node is removed from a splay tree, the splay tree was
not using the function splay_tree_delete_key_fn to release the key.
This was causing a leak, fixed by Tom Tromey.
This patch fixes another key leak, that happens when a key equal to
a key already present is inserted. In such a case, we have to release
the old KEY.
Note that this is based on the assumption that the caller always
allocates a new KEY when doing an insert.
Also, clarify the documentation about when the release functions are
called.
2019-02-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
libiberty/ChangeLog
2019-02-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* splay-tree.c (splay_tree_insert): Also release old KEY in case
of insertion of a key equal to an already present key.
(splay_tree_new_typed_alloc): Update comment.
Alan Hayward [Mon, 11 Feb 2019 16:38:29 +0000 (16:38 +0000)]
AArch64: Detect exit from execve syscall
Checking the syscall number when stopped on entry/exit relies on checking
the value in register X8.
However, on exit from an execve syscall, the registers will all be cleared.
Given this is only checked on syscall entry/exit, then a cleared register
state either means execve exit or syscall 0 (io_setup) entry with invalid
parameters and an invalid FR and LR, which in reality should never happen.
Use this to detect execve exit.
Move function to allow use of aarch64_sys_execve enum, and use newer
regcache functions.
Fixes gdb.base/catch-syscall.exp on Aarch64.
gdb/ChangeLog:
* aarch64-linux-tdep.c (aarch64_linux_get_syscall_number): Check
for execve.
x86: Rewrite NOP generation for fill and alignment
increased MAX_MEM_FOR_RS_ALIGN_CODE to 4095 which resulted in increase
of assembler time and memory usage by 5 times for inputs with many
.p2align directives, which is typical for LTO output. This patch passes
max_bytes to TC_FRAG_INIT so that MAX_MEM_FOR_RS_ALIGN_CODE can be set
as needed and tracked by backend it so that HANDLE_ALIGN can check the
maximum alignment for each rs_align_code frag. Wall time to assemble
the same cc1plus.s:
before:
423.78user 0.89system 7:05.71elapsed 99%CPU
after:
102.35user 0.27system 1:42.89elapsed 99%CPU
PR gas/24165
* frags.c (frag_var_init): Pass max_chars to TC_FRAG_INIT as
max_bytes.
* config/tc-aarch64.h (TC_FRAG_INIT): Add and pass max_bytes to
aarch64_init_frag.
* /config/tc-arm.h (TC_FRAG_INIT): And and pass max_bytes to
arm_init_frag.
* config/tc-avr.h (TC_FRAG_INIT): And and ignore max_bytes.
* config/tc-ia64.h (TC_FRAG_INIT): Likewise.
* config/tc-mmix.h (TC_FRAG_INIT): Likewise.
* config/tc-nds32.h (TC_FRAG_INIT): Likewise.
* config/tc-ns32k.h (TC_FRAG_INIT): Likewise.
* config/tc-rl78.h (TC_FRAG_INIT): Likewise.
* config/tc-rx.h (TC_FRAG_INIT): Likewise.
* config/tc-score.h (TC_FRAG_INIT): Likewise.
* config/tc-tic54x.h (TC_FRAG_INIT): Likewise.
* config/tc-tic6x.h (TC_FRAG_INIT): Likewise.
* config/tc-xtensa.h (TC_FRAG_INIT): Likewise.
* config/tc-i386.h (MAX_MEM_FOR_RS_ALIGN_CODE): Set to
(alignment ? ((1 << alignment) - 1) : 1)
(i386_tc_frag_data): Add max_bytes.
(TC_FRAG_INIT): Add and track max_bytes.
(HANDLE_ALIGN): Replace MAX_MEM_FOR_RS_ALIGN_CODE with
fragP->tc_frag_data.max_bytes.
* doc/internals.texi: Update TC_FRAG_TYPE with max_bytes.
Valgrind detects a bunch of leaks in several tests, such as:
==22905== 40 (24 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 531 of 3,268
==22905== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==22905== by 0x5893AD: get_type_stack() (parse.c:1509)
==22905== by 0x3F4EAD: c_yyparse() (c-exp.y:1223)
==22905== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308)
==22905== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205)
==22905== by 0x588FA1: parse_exp_in_context (parse.c:1108)
==22905== by 0x588FA1: parse_exp_1 (parse.c:1099)
==22905== by 0x588FA1: parse_expression(char const*) (parse.c:1247)
...
==22395== 456 (168 direct, 288 indirect) bytes in 7 blocks are definitely lost in loss record 2,658 of 2,978
==22395== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==22395== by 0x5893AD: get_type_stack() (parse.c:1509)
==22395== by 0x3F4ECF: c_yyparse() (c-exp.y:1230)
==22395== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308)
==22395== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205)
==22395== by 0x588FA1: parse_exp_in_context (parse.c:1108)
==22395== by 0x588FA1: parse_exp_1 (parse.c:1099)
==22395== by 0x588FA1: parse_expression(char const*) (parse.c:1247)
==22395== by 0x67BB9D: whatis_exp(char const*, int) (typeprint.c:515)
...
==22395== VALGRIND_GDB_ERROR_BEGIN
==22395== 144 (24 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1,016 of 2,978
==22395== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==22395== by 0x5893AD: get_type_stack() (parse.c:1509)
==22395== by 0x3F4E8A: c_yyparse() (c-exp.y:1217)
==22395== by 0x3F71BC: c_parse(parser_state*) (c-exp.y:3308)
==22395== by 0x588CEA: parse_exp_in_context_1(char const**, unsigned long, block const*, int, int, int*) [clone .constprop.89] (parse.c:1205)
==22395== by 0x588FA1: parse_exp_in_context (parse.c:1108)
==22395== by 0x588FA1: parse_exp_1 (parse.c:1099)
==22395== by 0x588FA1: parse_expression(char const*) (parse.c:1247)
==22395== by 0x67BB9D: whatis_exp(char const*, int) (typeprint.c:515)
...
Fix these by storing the allocated type_stack in the cpstate->type_stacks
vector.
Tested on debian/amd64, natively and under valgrind.
gdb/ChangeLog
2019-02-10 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* c-exp.y (direct_abs_decl): Use emplace_back to record the
type_stack.
Joel Brobecker [Sun, 10 Feb 2019 08:14:53 +0000 (03:14 -0500)]
(Ada) -var-update crash for variable whose type is a reference to changeable
Consider the following variable, which is a string whose value
is not known at compile time, because it is the return value
from a function call (Get_Name):
A : String := Get_Name;
If one tries to create a varobj for that variable, everything works
as expected:
| (gdb) -var-create a * a
| ^done,name="a",numchild="19",value="[19] \"Some kind of string\"",type="<ref> array (1 .. 19) of character",thread-id="1",has_more="0"
However, try then to request an update, regardless of whether the string
has changed or not, and we get a crash:
| -var-update a
| ~"/[...]/gdb/varobj.c:1379: internal-error: bool install_new_value(varobj*, value*, bool): Assertion `!value_lazy (var->value.get ())' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
When the varobj gets created (-var-create), the expression is evaluated
and transformed into a value. The debugging information describes our
variables as a reference to an array of characters, so our value has
the corresponding type. We then call varobj.c::install_new_value
to store that value inside our varobj, and we see that this function
pretty starts by determining weither our varobj is changeable, via:
(where 'var' is the varobj we are building, and where the function
varobj_value_is_changeable_p simply dispatches to the Ada version
of this routine: ada_value_is_changeable_p).
At this point, the varobj doesn't have a value, yet, but it does
have a type which was provided by varobj_create a little bit before
install_new_value was called. So ada_value_is_changeable_p uses that
to determine whether or not our type is changeable.
Since our type is a reference to an array, and that the value of
such objects is displayed as if there weren't a reference, it means
that our object is changeable -- in other words, if an element of
the string changes, then the "value" field of the varobj will change
accordingly. But unfortunately, ada_value_is_changeable_p mistakenly
returns false, because it is missing the handling of reference types.
As a consequence of this, install_new_value doesn't feel it is
necessary to fetch the value's contents, as explained by the following
comment inside that function:
/* The new value might be lazy. If the type is changeable,
that is we'll be comparing values of this type, fetch the
value now. Otherwise, on the next update the old value
will be lazy, which means we've lost that old value. */
This means that a lazy value gets installed inside our varobj
as a result of the mistake in ada_value_is_changeable_p.
Another important detail is that, after determining whether
our varobj is changeable or not, it then purposefully removes
the reference layer from our value:
/* We are not interested in the address of references, and given
that in C++ a reference is not rebindable, it cannot
meaningfully change. So, get hold of the real value. */
if (value)
value = coerce_ref (value);
The consequence of those two facts on shows up only later, when
the user requests an update (-var-update). When doing so, GDB
evaluates the expression again into a value which is once more
a reference to a string, and then calls install_new_value again
to install the new value and report any changes. This time around,
the call to...
... now gets a varobj which has a value, and one which had the reference
layer removed! So, this time, we classify the varobj correctly, and
say it is changeable. And because it is changeable, we then go into
the section of code in install_new_value which checks for changes,
where we need the varobj's value to not be lazy, as explained by
the comment we quoted above. That's what the assertion was about.
This patch fixes the issues by teaching ada_value_is_changeable_p
to ignore reference layers when evaluating a given varobj's type.
gdb/ChangeLog:
* ada-varobj.c (ada_value_is_changeable_p): Add handling of
TYPE_CODE_REF types.
gdb/testsuite/ChangeLog:
* gdb.ada/mi_ref_changeable: New testcase.
Prior to this patch, this testcase reports 2 unresolved tests
(due to GDB hitting the internal error). With this patch, all
tests in this testcase pass.
Recent gcc commit b4371b277f1e ("[ARC] Enable init_array support")
inhibits DT_"INIT,FINI} in favor of DT_{INIT,FINI}ARRAY.
Even prior to that, it seems ARC port is the only one with this
special DT_INIT/FINI handling in linker emulation. Removing it
doesn't seem to change any uClibc/glibc testsuite results,
so this can RIP anyways.
Jim Wilson [Tue, 5 Feb 2019 01:31:10 +0000 (17:31 -0800)]
RISC-V: Add FP register core file support.
This adds fp reg support similar to the existing general reg support.
This fixes one gdb testsuite failure
FAIL: gdb.base/gcore.exp: corefile restored system registers
which fails without the patch because fcsr was missing. Otherwise, no
regressions with riscv64-linux native testsuite run.
Jim Wilson [Fri, 8 Feb 2019 20:57:12 +0000 (12:57 -0800)]
RISC-V: Compress 3-operand beq/bne against x0.
This lets us accept an instruction like
beq a2,x0,.Label
and generate a compressed beqz. This will allow some future simplications
to the gcc support, e.g. eliminating some duplicate patterns, and avoiding
adding new duplicate patterns, since currently we have to handle signed
and equality compares against zero specially.
Tested with rv{32,64}-{elf,linux} cross builds and make checks for binutils
and gcc. There were no regressions.
Andrew Burgess [Thu, 24 Jan 2019 14:27:27 +0000 (14:27 +0000)]
binutils: Add new GNU format mode to `size` utility
The size tool currently defaults to berkeley format output. However,
this output format has a weird quirk, read-only data is counted
against the text sections, not the data sections.
The code offers no real explanation for why this is, but I'm reluctant
to change it for two reasons, first, I'm assuming it probably makes
sense in some case that I'm not thinking of (maybe a target where
sections are not marked executable, and so there's no distinction
between read-only data and code), and second, the code has been this
way for at least 20 years, I worry that changing things now might
cause more confusion than it solves.
This commit then introduces a new output format for the size tool,
this new format displays the results in a similar manor to the
berkeley format, but counts read-only data in the data column, and
only executable sections are counted in the text column.
Given that this is a brand new output format I've gone ahead and
simplified things a little, while the berkeley format displays the
total twice, once in decimal and once in hex, the new display format
just displays the total in decimal. Of course, there's still the
'--radix' option which can be used to display all the results in
hexadecimal or octal.
I've called the new format 'gnu', so '--format=gnu' or '-G' are used
to access it.
binutils/ChangeLog:
* size.c (berkeley_format): Delete.
(enum output_format): New enum.
(selected_output_format): New variable.
(usage): Update to mention GNU format.
(main): Update to extract options, and select format as needed.
Handle GNU format where needed.
(berkeley_sum): Renamed to...
(berkeley_or_gnu_sum): ...this, and updated to handle both formats.
(berkeley_format): Renamed to...
(berkeley_or_gnu_format): ...this, and updated to handle both
formats.
(print_sizes): Handle GNU format.
* doc/binutils.texi (size): Document new GNU format.
* testsuite/binutils-all/size.exp: Add test of extended
functionality.
* NEWS: Mention new functionality.
Andrew Burgess [Thu, 31 Jan 2019 10:14:09 +0000 (10:14 +0000)]
binutils/size: Update example output in documentation
The example output from size in Berkeley format is out of date. The
columns are now displayed right aligned. This patch updates the
documentation to reflect reality.
binutils/ChangeLog:
* doc/binutils.texi (size): Update example output for Berkeley
format output.
Tamar Christina [Thu, 7 Feb 2019 17:12:23 +0000 (17:12 +0000)]
Arm: Backport hlt to all architectures.
The software trap instruction HLT that was introduced in Armv8-a is used
as the semihosting trap instruction in AArch64. In order to allow systems
configured to run AArch64 code to also run AArch32 with semihosting it was
decided that AArch32 should also use HLT in the case of the "mixed mode"
environment. This requires that HLT also be backported to all earlier
architectures. The instruction is in the undefined encoding space earlier
architectures but must trigger a semihosting trap [3].
The Arm Architectural Reference Manual [1] doesn't explicitly mention this
however this is an explicit requirement in the Semihosting-v2 protocol [2].
* config/tc-arm.c (insns): Redefine THUMB_VARIANT and ARM_VARIANT for
hlt to armv1.
* testsuite/gas/arm/armv8a-automatic-hlt.d: Update TAGs
* testsuite/gas/arm/hlt.d: New test.
* testsuite/gas/arm/hlt.s: New test.
Tamar Christina [Thu, 7 Feb 2019 16:58:29 +0000 (16:58 +0000)]
AArch64: Add negative tests for Armv8.3-a complex number instructions instructions.
This patch just adds a few negative tests for the Armv8.3-a complex instructions.
These already do the right disassembly without needing a verifier, but adding
some tests to make sure that stays that way.
gas/ChangeLog:
* testsuite/gas/aarch64/undefined_advsimd_armv8_3.d: New test.
* testsuite/gas/aarch64/undefined_advsimd_armv8_3.s: New test.
Tamar Christina [Thu, 7 Feb 2019 16:55:23 +0000 (16:55 +0000)]
AArch64: Add verifier for By elem Single and Double sized instructions.
The AArch64 instruction set has cut-outs inside instructions encodings for
when a given encoding that would normally fall within the encoding space of
an instruction is instead undefined.
This updates the first few instructions FMLA, FMLA, FMUL and FMULX in the case
where sz:L == 11.
gas/ChangeLog:
PR binutils/23212
* testsuite/gas/aarch64/undefined_by_elem_sz_l.s: New test.
* testsuite/gas/aarch64/undefined_by_elem_sz_l.d: New test.
opcodes/ChangeLog:
PR binutils/23212
* aarch64-opc.h (enum aarch64_field_kind): Add FLD_sz.
* aarch64-opc.c (verify_elem_sd): New.
(fields): Add FLD_sz entr.
* aarch64-tbl.h (_SIMD_INSN): New.
(aarch64_opcode_table): Add elem_sd verifier to fmla, fmls, fmul and
fmulx scalar and vector by element isns.
Eric Botcazou [Thu, 7 Feb 2019 16:04:31 +0000 (17:04 +0100)]
SPARC: fix PR ld/18841
This fixes the last ld failures on SPARC64/Linux:
FAIL: Run pr18841 with libpr18841b.so
FAIL: Run pr18841 with libpr18841c.so
FAIL: Run pr18841 with libpr18841bn.so (-z now)
FAIL: Run pr18841 with libpr18841cn.so (-z now)
by mimicing what has been done on x86-64 and Aarch64 to fix the PR.
Alan Hayward [Thu, 7 Feb 2019 14:36:34 +0000 (14:36 +0000)]
gdbserver: When attaching, add process before lwps
The recent BP/WP changes for AArch64 swapping the order in add_lwp()
so that the process was added before the lwp. This was due to the lwp
creation requiring the process data.
This also needs changing in linux_attach().
Also add additional checks to make sure cannot attach to the same
process twice. Add test case for this - do this by splitting
attach.exp into distinct pass and error case sections.
Fixes gdb.server/ext-attach.exp on Aarch64.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_attach): Add process before lwp.
* server.c (attach_inferior): Check if already attached.
Simon Marchi [Thu, 7 Feb 2019 14:22:29 +0000 (09:22 -0500)]
Make gdb.base/corefile.exp work on terminals with few rows
When creating a pty to spawn a subprocess (such as gdb), Expect
copies the settings of its own controlling terminal, including the
number of rows and columns. If you "make check" on a terminal with just
a few rows (e.g. 4), GDB will paginate before reaching the initial
prompt. In default_gdb_start, used by most tests, this is already
handled: if we see the pagination prompt, we sent \n to continue.
Philippe reported that gdb.base/corefile.exp didn't work in terminals
with just a few rows. This test spawns GDB by hand, because it needs to
check things before the initial prompt, which it couldn't do if it used
default_gdb_start.
In this case I think it's not safe to use the same technique as in
default_gdb_start. Even if we could send a \n if we see a pagination
prompt, we match some multiline regexes in there. So if a pagination
slips in there, it might make the regexes not match and fail the test.
It's also not possible to use -ex "set height 0" or -iex "set height 0",
it is handled after the introduction text is shown.
The simplest way I found to avoid showing the pagination completely is
to set stty_init (documented in expect's man page) to initialize gdb's
pty with a fixed number of rows.
And actually, if we set stty_init in gdb_init, it works nicely as a
general solution applicable to all tests. We can therefore remove the
solution introduced in e882ef3cfc3 ("testsuite: expect possible
pagination when starting gdb") where we matched the pagination prompt
during startup.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_start): Don't match pagination
prompt.
(gdb_init): Set stty_init.
Tom Tromey [Sun, 27 Jan 2019 19:51:36 +0000 (12:51 -0700)]
Normalize include guards in gdb
While working on my other scripts to deal with gdb headers, I noticed
that some files were missing include guards. I wrote a script to add
the missing ones, but found that using the obvious names for the
guards ran into clashes -- for example, gdb/nat/linux-nat.h used
"LINUX_NAT_H", but this was also the script's choice for
gdb/linux-nat.h.
So, I changed the script to normalize all include guards in gdb. This
patch is the result.
As usual the script is available here:
https://github.com/tromey/gdb-refactoring-scripts
Tested by rebuilding; I also ran it through "Fedora-x86_64-m64" on the
buildbot.
gdb/ChangeLog
2019-02-07 Tom Tromey <tom@tromey.com>
* yy-remap.h: Add include guard.
* xtensa-tdep.h: Add include guard.
* xcoffread.h: Rename include guard.
* varobj-iter.h: Add include guard.
* tui/tui.h: Rename include guard.
* tui/tui-winsource.h: Rename include guard.
* tui/tui-wingeneral.h: Rename include guard.
* tui/tui-windata.h: Rename include guard.
* tui/tui-win.h: Rename include guard.
* tui/tui-stack.h: Rename include guard.
* tui/tui-source.h: Rename include guard.
* tui/tui-regs.h: Rename include guard.
* tui/tui-out.h: Rename include guard.
* tui/tui-layout.h: Rename include guard.
* tui/tui-io.h: Rename include guard.
* tui/tui-hooks.h: Rename include guard.
* tui/tui-file.h: Rename include guard.
* tui/tui-disasm.h: Rename include guard.
* tui/tui-data.h: Rename include guard.
* tui/tui-command.h: Rename include guard.
* tic6x-tdep.h: Add include guard.
* target/waitstatus.h: Rename include guard.
* target/wait.h: Rename include guard.
* target/target.h: Rename include guard.
* target/resume.h: Rename include guard.
* target-float.h: Rename include guard.
* stabsread.h: Add include guard.
* rs6000-tdep.h: Add include guard.
* riscv-fbsd-tdep.h: Add include guard.
* regformats/regdef.h: Rename include guard.
* record.h: Rename include guard.
* python/python.h: Rename include guard.
* python/python-internal.h: Rename include guard.
* python/py-stopevent.h: Rename include guard.
* python/py-ref.h: Rename include guard.
* python/py-record.h: Rename include guard.
* python/py-record-full.h: Rename include guard.
* python/py-record-btrace.h: Rename include guard.
* python/py-instruction.h: Rename include guard.
* python/py-events.h: Rename include guard.
* python/py-event.h: Rename include guard.
* procfs.h: Add include guard.
* proc-utils.h: Add include guard.
* p-lang.h: Add include guard.
* or1k-tdep.h: Rename include guard.
* observable.h: Rename include guard.
* nto-tdep.h: Rename include guard.
* nat/x86-linux.h: Rename include guard.
* nat/x86-linux-dregs.h: Rename include guard.
* nat/x86-gcc-cpuid.h: Add include guard.
* nat/x86-dregs.h: Rename include guard.
* nat/x86-cpuid.h: Rename include guard.
* nat/ppc-linux.h: Rename include guard.
* nat/mips-linux-watch.h: Rename include guard.
* nat/linux-waitpid.h: Rename include guard.
* nat/linux-ptrace.h: Rename include guard.
* nat/linux-procfs.h: Rename include guard.
* nat/linux-osdata.h: Rename include guard.
* nat/linux-nat.h: Rename include guard.
* nat/linux-namespaces.h: Rename include guard.
* nat/linux-btrace.h: Rename include guard.
* nat/glibc_thread_db.h: Rename include guard.
* nat/gdb_thread_db.h: Rename include guard.
* nat/gdb_ptrace.h: Rename include guard.
* nat/fork-inferior.h: Rename include guard.
* nat/amd64-linux-siginfo.h: Rename include guard.
* nat/aarch64-sve-linux-sigcontext.h: Rename include guard.
* nat/aarch64-sve-linux-ptrace.h: Rename include guard.
* nat/aarch64-linux.h: Rename include guard.
* nat/aarch64-linux-hw-point.h: Rename include guard.
* mn10300-tdep.h: Add include guard.
* mips-linux-tdep.h: Add include guard.
* mi/mi-parse.h: Rename include guard.
* mi/mi-out.h: Rename include guard.
* mi/mi-main.h: Rename include guard.
* mi/mi-interp.h: Rename include guard.
* mi/mi-getopt.h: Rename include guard.
* mi/mi-console.h: Rename include guard.
* mi/mi-common.h: Rename include guard.
* mi/mi-cmds.h: Rename include guard.
* mi/mi-cmd-break.h: Rename include guard.
* m2-lang.h: Add include guard.
* location.h: Rename include guard.
* linux-record.h: Rename include guard.
* linux-nat.h: Add include guard.
* linux-fork.h: Add include guard.
* i386-darwin-tdep.h: Rename include guard.
* hppa-linux-offsets.h: Add include guard.
* guile/guile.h: Rename include guard.
* guile/guile-internal.h: Rename include guard.
* gnu-nat.h: Rename include guard.
* gdb-stabs.h: Rename include guard.
* frv-tdep.h: Add include guard.
* f-lang.h: Add include guard.
* event-loop.h: Add include guard.
* darwin-nat.h: Rename include guard.
* cp-abi.h: Rename include guard.
* config/sparc/nm-sol2.h: Rename include guard.
* config/nm-nto.h: Rename include guard.
* config/nm-linux.h: Add include guard.
* config/i386/nm-i386gnu.h: Rename include guard.
* config/djgpp/nl_types.h: Rename include guard.
* config/djgpp/langinfo.h: Rename include guard.
* compile/gcc-cp-plugin.h: Add include guard.
* compile/gcc-c-plugin.h: Add include guard.
* compile/compile.h: Rename include guard.
* compile/compile-object-run.h: Rename include guard.
* compile/compile-object-load.h: Rename include guard.
* compile/compile-internal.h: Rename include guard.
* compile/compile-cplus.h: Rename include guard.
* compile/compile-c.h: Rename include guard.
* common/xml-utils.h: Rename include guard.
* common/x86-xstate.h: Rename include guard.
* common/version.h: Rename include guard.
* common/vec.h: Rename include guard.
* common/tdesc.h: Rename include guard.
* common/selftest.h: Rename include guard.
* common/scoped_restore.h: Rename include guard.
* common/scoped_mmap.h: Rename include guard.
* common/scoped_fd.h: Rename include guard.
* common/safe-iterator.h: Rename include guard.
* common/run-time-clock.h: Rename include guard.
* common/refcounted-object.h: Rename include guard.
* common/queue.h: Rename include guard.
* common/ptid.h: Rename include guard.
* common/print-utils.h: Rename include guard.
* common/preprocessor.h: Rename include guard.
* common/pathstuff.h: Rename include guard.
* common/observable.h: Rename include guard.
* common/netstuff.h: Rename include guard.
* common/job-control.h: Rename include guard.
* common/host-defs.h: Rename include guard.
* common/gdb_wait.h: Rename include guard.
* common/gdb_vecs.h: Rename include guard.
* common/gdb_unlinker.h: Rename include guard.
* common/gdb_unique_ptr.h: Rename include guard.
* common/gdb_tilde_expand.h: Rename include guard.
* common/gdb_sys_time.h: Rename include guard.
* common/gdb_string_view.h: Rename include guard.
* common/gdb_splay_tree.h: Rename include guard.
* common/gdb_setjmp.h: Rename include guard.
* common/gdb_ref_ptr.h: Rename include guard.
* common/gdb_optional.h: Rename include guard.
* common/gdb_locale.h: Rename include guard.
* common/gdb_assert.h: Rename include guard.
* common/filtered-iterator.h: Rename include guard.
* common/filestuff.h: Rename include guard.
* common/fileio.h: Rename include guard.
* common/environ.h: Rename include guard.
* common/common-utils.h: Rename include guard.
* common/common-types.h: Rename include guard.
* common/common-regcache.h: Rename include guard.
* common/common-inferior.h: Rename include guard.
* common/common-gdbthread.h: Rename include guard.
* common/common-exceptions.h: Rename include guard.
* common/common-defs.h: Rename include guard.
* common/common-debug.h: Rename include guard.
* common/cleanups.h: Rename include guard.
* common/buffer.h: Rename include guard.
* common/btrace-common.h: Rename include guard.
* common/break-common.h: Rename include guard.
* cli/cli-utils.h: Rename include guard.
* cli/cli-style.h: Rename include guard.
* cli/cli-setshow.h: Rename include guard.
* cli/cli-script.h: Rename include guard.
* cli/cli-interp.h: Rename include guard.
* cli/cli-decode.h: Rename include guard.
* cli/cli-cmds.h: Rename include guard.
* charset-list.h: Add include guard.
* buildsym-legacy.h: Rename include guard.
* bfin-tdep.h: Add include guard.
* ax.h: Rename include guard.
* arm-linux-tdep.h: Add include guard.
* arm-fbsd-tdep.h: Add include guard.
* arch/xtensa.h: Rename include guard.
* arch/tic6x.h: Add include guard.
* arch/i386.h: Add include guard.
* arch/arm.h: Rename include guard.
* arch/arm-linux.h: Rename include guard.
* arch/arm-get-next-pcs.h: Rename include guard.
* arch/amd64.h: Add include guard.
* arch/aarch64-insn.h: Rename include guard.
* arch-utils.h: Rename include guard.
* annotate.h: Add include guard.
* amd64-darwin-tdep.h: Rename include guard.
* aarch64-linux-tdep.h: Add include guard.
* aarch64-fbsd-tdep.h: Add include guard.
* aarch32-linux-nat.h: Add include guard.
gdb/gdbserver/ChangeLog
2019-02-07 Tom Tromey <tom@tromey.com>
* x86-tdesc.h: Rename include guard.
* x86-low.h: Add include guard.
* wincecompat.h: Rename include guard.
* win32-low.h: Add include guard.
* utils.h: Rename include guard.
* tracepoint.h: Rename include guard.
* tdesc.h: Rename include guard.
* target.h: Rename include guard.
* server.h: Rename include guard.
* remote-utils.h: Rename include guard.
* regcache.h: Rename include guard.
* nto-low.h: Rename include guard.
* notif.h: Add include guard.
* mem-break.h: Rename include guard.
* lynx-low.h: Add include guard.
* linux-x86-tdesc.h: Add include guard.
* linux-s390-tdesc.h: Add include guard.
* linux-ppc-tdesc-init.h: Add include guard.
* linux-low.h: Add include guard.
* linux-aarch64-tdesc.h: Add include guard.
* linux-aarch32-low.h: Add include guard.
* inferiors.h: Rename include guard.
* i387-fp.h: Rename include guard.
* hostio.h: Rename include guard.
* gdbthread.h: Rename include guard.
* gdb_proc_service.h: Rename include guard.
* event-loop.h: Rename include guard.
* dll.h: Rename include guard.
* debug.h: Rename include guard.
* ax.h: Rename include guard.
When first fixing splay tree key leaks in macrotab.c, some duplicated code
logic was factorized.
The key leaks will be fixed in libiberty, but the code factorization
is better kept in any case.
gdb/ChangeLog
2019-02-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* macrotab.c (macro_define_internal): New function that
factorizes macro_define_object_internal and macro_define_function
code.
(macro_define_object_internal): Use macro_define_internal.
(macro_define_function): Likewise.
Valgrind detects leaks like the following (gdb.base/macscp.exp).
This patch fixes 1 of the 3 leaks (the last one in the list below).
The remaining leaks are better fixed in splay_tree_remove and
splay_tree_insert in libiberty.
Tested on debian/amd64, natively and under valgrind.
==22285== 64 (48 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 737 of 3,377
==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==22285== by 0x4049E7: xmalloc (common-utils.c:44)
==22285== by 0x533A20: new_macro_key(macro_table*, char const*, macro_source_file*, int) (macrotab.c:355)
==22285== by 0x53438B: macro_define_function(macro_source_file*, int, char const*, int, char const**, char const*) (macrotab.c:822)
==22285== by 0x52F945: macro_define_command(char const*, int) (macrocmd.c:409)
...
==22285== 128 (96 direct, 32 indirect) bytes in 2 blocks are definitely lost in loss record 1,083 of 3,377
==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==22285== by 0x4049E7: xmalloc (common-utils.c:44)
==22285== by 0x533A20: new_macro_key(macro_table*, char const*, macro_source_file*, int) (macrotab.c:355)
==22285== by 0x534277: macro_define_object_internal(macro_source_file*, int, char const*, char const*, macro_special_kind) (macrotab.c:776)
==22285== by 0x52F7E0: macro_define_command(char const*, int) (macrocmd.c:414)
...
==22285== 177 bytes in 19 blocks are definitely lost in loss record 1,193 of 3,377
==22285== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==22285== by 0x4049E7: xmalloc (common-utils.c:44)
==22285== by 0x52F5BD: extract_identifier(char const**, int) (macrocmd.c:316)
==22285== by 0x52F77D: macro_define_command(char const*, int) (macrocmd.c:355)
gdb/ChangeLog
2019-02-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* macrocmd.c (extract_identifier): Return
a gdb::unique_xmalloc_ptr<char> instead of a char *, and update
callers.
projects / thirdparty / binutils-gdb.git / log
