Underscore was specified twice in all these patterns, and backslash
twice in some. Flex warned about the $SYSROOT rule, which is covered
by earlier rules: "ldlex.l:386: warning, rule cannot be matched".
* ldlex.l: Formatting.
(CMDFILENAMECHAR, CMDFILENAMECHAR1): Delete.
(FILENAMECHAR1, SYMBOLNAMECHAR1, FILENAMECHAR, WILDCHAR),
(NOCFILENAMECHAR): Remove duplicate chars. Reorder.
(SYMBOLCHARN): Likewise. Rename to SYMBOLNAMECHAR.
(<INPUTLIST>"$SYSROOT"..): Delete rule.
This fixes a glib build failure reported in PR 24389. Using ld -b binary
creates an object file with no elf header flags set which has the wrong ABI
info for riscv64-linux. But the file also has no code sections, so I added
code borrowed from the arm port that only checks the ELF header ABI flags if
there is a code section.
bfd/
PR 24389
* elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Move read of
ELF header flags to after check for ELF object file. Loop through
sections looking for code sections, if none, then skip ABI checks.
If an convenience function is defined in python (or guile), then
currently this will not work in Fortran, instead the user is given
this message:
(gdb) set language fortran
(gdb) p $myfunc (3)
Cannot perform substring on this type
Compare this to C:
(gdb) set language c
(gdb) p $myfunc (3)
$1 = 1
After this patch we see the same behaviour in both C and Fortran.
I've extended the test to check that all languages can call the
convenience functions - only Fortran was broken.
When calling convenience functions in Fortran we don't need to perform
the same value preparation (passing by pointer) that we would for
calling a native function - passing the real value is fine.
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): Handle internal functions
during Fortran function call handling.
gdb/testsuite/ChangeLog:
* gdb.python/py-function.exp: Check calling helper function from
all languages.
* lib/gdb.exp (gdb_supported_languages): New proc.
Add two new internal functions $_cimag and $_creal that extract the
imaginary and real parts of a complex value.
These internal functions can take a complex value of any type 'float
complex', 'double complex', or 'long double complex' and return a
suitable floating point value 'float', 'double', or 'long double'.
So we can now do this:
(gdb) p z1
$1 = 1.5 + 4.5 * I
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) p $_creal (z1)
$4 = 1.5
The components of a complex value are not strictly named types in
DWARF, as the complex type is itself the base type. However, once we
are able to extract the components it makes sense to be able to ask
what the type of these components is and get a sensible answer back,
rather than the error we would currently get. Currently GDB says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = <invalid type code 9>
With the changes in dwarf2read.c, GDB now says:
(gdb) ptype z1
type = complex double
(gdb) p $_cimag (z1)
$4 = 4.5
(gdb) ptype $
type = double
Which seems to make more sense.
gdb/ChangeLog:
* NEWS: Mention new internal functions.
* dwarf2read.c (dwarf2_init_complex_target_type): New function.
(read_base_type): Use dwarf2_init_complex_target_type.
* value.c (creal_internal_fn): New function.
(cimag_internal_fn): New function.
(_initialize_values): Register new internal functions.
gdb/doc/ChangeLog:
* gdb.texinfo (Convenience Funs): Document '$_creal' and
'$_cimag'.
gdb/testsuite/ChangeLog:
* gdb.base/complex-parts.c: New file.
* gdb.base/complex-parts.exp: New file.
The test gdb.threads/watchthreads-reorder.exp verifies that the
'set debug infrun 1' debug output does not crash GDB.
Under high load, the test can still cause a GDB internal error (see details
below).
This patch fixes this crash, and improves/factorises some wait kind traces.
Tested on debian/amd64 + run one test with 'set debug infrun 1'.
Changes compared to the first version:
* Handles the suggestions of Kevin to trace the relevant elements
of the wait status (this is done by calling target_waitstatus_to_string).
* Some other changes to factorise wait status tracing.
Note that using target_waitstatus_to_string instead of the 'locally printed'
status kind strings means that debug trace that was using strings such as:
"EXITED" or "TARGET_WAITKIND_EXITED"
will now use what is printed by target_waitstatus_to_string e.g.
"exited".
gdb/ChangeLog
2019-04-01 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* infrun.c (stop_all_threads): If debug_infrun, always
trace the wait status after wait_one, using
target_waitstatus_to_string and target_pid_to_str.
(handle_inferior_event): Replace various trace of
wait status kind by a single trace.
* gdb/gnu-nat.c (gnu_nat_target::wait): Replace local
wait status kind image by target_waitstatus_to_string.
* target/waitstatus.c (target_waitstatus_to_string): Fix
obsolete comment.
(top-gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f3d54a0642a in __GI_abort () at abort.c:89
#2 0x0000555c24c60e66 in dump_core () at ../../fixleaks/gdb/utils.c:201
#3 0x0000555c24c63d49 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=problem@entry=0x555c25338d40 <internal_error_problem>, file=<optimized out>, line=287,
fmt=<optimized out>, ap=<optimized out>) at ../../fixleaks/gdb/utils.c:411
#4 0x0000555c24c63eab in internal_verror (file=<optimized out>, line=<optimized out>, fmt=<optimized out>,
ap=<optimized out>) at ../../fixleaks/gdb/utils.c:436
#5 0x0000555c249e8c22 in internal_error (file=file@entry=0x555c24e0f2ad "../../fixleaks/gdb/inferior.c",
line=line@entry=287, fmt=<optimized out>) at ../../fixleaks/gdb/common/errors.c:55
#6 0x0000555c247d3f5c in find_inferior_pid (pid=<optimized out>) at ../../fixleaks/gdb/inferior.c:287
#7 0x0000555c24ad2248 in find_inferior_pid (pid=<optimized out>) at ../../fixleaks/gdb/inferior.c:302
#8 find_inferior_ptid (ptid=...) at ../../fixleaks/gdb/inferior.c:301
#9 0x0000555c24c35f25 in find_thread_ptid (ptid=...) at ../../fixleaks/gdb/thread.c:522
#10 0x0000555c24b0ab4d in thread_db_target::pid_to_str[abi:cxx11](ptid_t) (
this=0x555c2532e3e0 <the_thread_db_target>, ptid=...) at ../../fixleaks/gdb/linux-thread-db.c:1637
#11 0x0000555c24c2f420 in target_pid_to_str[abi:cxx11](ptid_t) (ptid=...) at ../../fixleaks/gdb/target.c:2083
#12 0x0000555c24ad9cab in stop_all_threads () at ../../fixleaks/gdb/infrun.c:4373
#13 0x0000555c24ada00f in stop_waiting (ecs=<optimized out>) at ../../fixleaks/gdb/infrun.c:7464
#14 0x0000555c24adc401 in process_event_stop_test (ecs=ecs@entry=0x7ffc9402d9d0) at ../../fixleaks/gdb/infrun.c:6181
...
(top-gdb) fr 12
#12 0x0000555c24ad9cab in stop_all_threads () at ../../fixleaks/gdb/infrun.c:4373
(top-gdb) p event_ptid
$5 = {m_pid = 25419, m_lwp = 25427, m_tid = 0}
(top-gdb) p ptid
$6 = {m_pid = 0, m_lwp = 0, m_tid = 0}
(top-gdb) p ws
$7 = {kind = TARGET_WAITKIND_THREAD_EXITED, value = {integer = 0, sig = GDB_SIGNAL_0, related_pid = {m_pid = 0,
m_lwp = 0, m_tid = 0}, execd_pathname = 0x0, syscall_number = 0}}
(top-gdb)
The gdb.log corresponding to the above crash is:
(gdb) PASS: gdb.threads/watchthreads-reorder.exp: reorder1: set debug infrun 1
continue
Continuing.
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcfb40 (LWP 25419))
infrun: clear_proceed_status_thread (Thread 0x7ffff7310700 (LWP 25427))
infrun: clear_proceed_status_thread (Thread 0x7ffff6b0f700 (LWP 25428))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming Thread 0x7ffff7fcfb40 (LWP 25419)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcfb40 (LWP 25419)] at 0x7ffff7344317
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: proceed: resuming Thread 0x7ffff7310700 (LWP 25427)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7310700 (LWP 25427)] at 0x5555555553d7
infrun: prepare_to_wait
infrun: proceed: resuming Thread 0x7ffff6b0f700 (LWP 25428)
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff6b0f700 (LWP 25428)] at 0x5555555554c8
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
Joining the threads.
[Thread 0x7ffff6b0f700 (LWP 25428) exited]
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = ignore
infrun: TARGET_WAITKIND_IGNORE
infrun: prepare_to_wait
infrun: target_wait (-1.0.0, status) =
infrun: 25419.25419.0 [Thread 0x7ffff7fcfb40 (LWP 25419)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x555555555e50
infrun: context switch
infrun: Switching context from Thread 0x7ffff6b0f700 (LWP 25428) to Thread 0x7ffff7fcfb40 (LWP 25419)
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: Thread 0x7ffff7fcfb40 (LWP 25419) not executing
infrun: Thread 0x7ffff7310700 (LWP 25427) executing, need stop
[Thread 0x7ffff7310700 (LWP 25427) exited]
infrun: target_wait (-1.0.0, status) =
infrun: 25419.25427.0 [LWP 25427],
infrun: status->kind = thread exited, status = 0
infrun: infrun_async(0)
../../fixleaks/gdb/inferior.c:287: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: gdb.threads/watchthreads-reorder.exp: reorder1: continue to breakpoint: break-at-exit (GDB internal error)
Resyncing due to internal error.
n
infrun: infrun_async(1)
This is a bug, please report it. For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.
infrun: infrun_async(0)
../../fixleaks/gdb/inferior.c:287: internal-error: inferior* find_inferior_pid(int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
add_partial_subprogram does not handle DW_AT_ranges, while the full
symtab reader does. This can lead to discrepancies where a function
is not put into a partial symtab, and so is not available to "break"
and the like -- but is available if the full symtab has somehow been
read.
This patch fixes the bug by arranging to read DW_AT_ranges when
reading partial DIEs.
This is PR symtab/23331.
The new test case is derived from dw2-ranges-func.exp, which is why I
kept the copyright dates.
gdb/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* dwarf2read.c (partial_die_info::read): Handle DW_AT_ranges.
gdb/testsuite/ChangeLog
2019-04-01 Tom Tromey <tromey@adacore.com>
PR symtab/23331:
* gdb.dwarf2/dw2-ranges-main.c: New file.
* gdb.dwarf2/dw2-ranges-psym.c: New file.
* gdb.dwarf2/dw2-ranges-psym.exp: New file.
When the user exits GDB, we might still have some allocated values in
the chain, which, in specific scenarios, can cause problems when GDB
attempts to destroy them in "quit_force". For example, see the bug
reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1690120
And the thread starting at:
https://sourceware.org/ml/gdb-patches/2019-03/msg00475.html
Message-ID: <87r2azkhmq.fsf@redhat.com>
In order to avoid that, and to be more aware of our allocated
resources, this commit implements a new function "finalize_values" and
calls it from inside "quit_force".
Tested by the BuildBot.
2019-04-01 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
* top.c (quit_force): Call 'finalize_values'.
* value.c (finalize_values): New function.
* value.h (finalize_values): Declare.
This patch adds a new framework to add architecture sensitive extensions, like
GCC does. This patch also implements all architecture extensions currently
available in GCC.
This framework works as follows. To enable architecture sensitive extensions
for a particular architecture, that architecture must contain an ARM_ARCH_OPT2
entry in the 'arm_archs' table. All fields here are the same as previous, with
the addition of a new extra field at the end to <name> it's extension table.
This <name>, corresponds to a <name>_ext_table of type 'struct arm_ext_table'.
This struct can be filled with three types of entries:
ARM_ADD (string <ext>, arm_feature_set <enable_bits>), which means +<ext> will
enable <enable_bits>
ARM_REMOVE (string <ext>, arm_feature_set <disable_bits>), which means
+no<ext> will disable <disable_bits>
ARM_EXT (string <ext>, arm_feature_set <enable_bits>, arm_feature_set
<disable_bits>), which means +<ext> will enable <enable_bits> and +no<ext>
will disable <disable_bits> (this is to be used instead of adding an
ARM_ADD and ARM_REMOVE for the same <ext>)
This patch does not disable the use of the old extensions, even if some of them
are duplicated in the new tables. This is a "in-between-step" as we may want to
deprecate the old table of extensions in later patches. For now, GAS will first
look for the +<ext> or +no<ext> in the new table and if no entry is found it
will continue searching in the old table, following old behaviour. If only an
ARM_ADD or an ARM_REMOVE is defined for <ext> and +no<ext> or +<ext> resp. is
used then it also continues to search the old table for it.
A couple of caveats:
- This patch does not enable the use of these architecture extensions with the
'.arch_extension' directive. This is future work that I will tend to later.
- This patch does not enable the use of these architecture extensions with the
-mcpu option. This is future work that I will tend to later.
- This patch does not change the current behaviour when combining an
architecture extension and using -mfpu on the command-line. The current
behaviour of GAS is to stage the union of feature bits enabled by both -march
and -mfpu. GCC behaves differently here, so this is something we may want to
revisit on a later date.
The str () function, called on a gdb.Value instance, produces a string
representation similar to what can be achieved with the print command,
but it doesn't allow to specify additional formatting settings, for
instance disabling pretty printers.
This patch introduces a new format_string () method to gdb.Value which
allows specifying more formatting options, thus giving access to more
features provided by the internal C function common_val_print ().
gdb/ChangeLog:
2019-04-01 Marco Barisione <mbarisione@undo.io>
Add gdb.Value.format_string ().
* python/py-value.c (copy_py_bool_obj):
(valpy_format_string): Add gdb.Value.format_string ().
* NEWS: Document the addition of gdb.Value.format_string ().
gdb/doc/ChangeLog:
2019-04-01 Marco Barisione <mbarisione@undo.io>
* python.texi (Values From Inferior): Document
gdb.Value.format_string ().
gdb/testsuite/ChangeLog:
2019-04-01 Marco Barisione <mbarisione@undo.io>
Test gdb.Value.format_string ().
* gdb.python/py-format-string.exp: New test.
* gdb.python/py-format-string.c: New file.
* gdb.python/py-format-string.py: New file.
PR 24402
* symtab.c (symtab_finalize): Init prev_addr to one less than
first symbol address, not one more. Correct test for symbols
with leading underscores.
I noticed that the help for "info addr" did not include a "usage"
line; and when adding it I went through and fixed a few minor issues
in printcmd.c:
* Added usage lines to all commands
* Updated the help text for some commands
* Changed some help to use upper case metasyntactic variables
* Removed some dead code
Regression tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-03-29 Tom Tromey <tromey@adacore.com>
* printcmd.c (_initialize_printcmd): Add usage lines. Update some
help text. Remove dead code.
gdb/testsuite/ChangeLog
2019-03-29 Tom Tromey <tromey@adacore.com>
* gdb.base/help.exp: Tighten apropos regexp.
This is the fortran part of the patch, including tests, which
are essentially unchanged from Siddhesh's original 2012 submission:
https://sourceware.org/ml/gdb-patches/2012-08/msg00562.html
There is, however, one large departure. In the above thread,
Jan pointed out problems with GCC debuginfo for -m32 builds
(filed usptream as gcc/54934). After investigating the issue,
I am dropping the hand-tweaked assembler source file to workaround
this case.
While I would normally do something to accommodate this, in
this case, given the ubiquity of 64-bit systems today (where
the tests pass) and the apparent lack of urgency on the compiler
side (by users), I don't think the additional complexity and
maintenance costs are worth it. It will be very routinely tested
on 64-bit systems. [For example, at Red Hat, we always
test -m64 and -m32 configurations for all GDB releases.]
gdb/ChangeLog:
From Siddhesh Poyarekar:
* f-lang.h (f77_get_upperbound): Return LONGEST.
(f77_get_lowerbound): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Expand
UPPER_BOUND and LOWER_BOUND to LONGEST. Use plongest to format
print them.
(f_type_print_base): Expand UPPER_BOUND to LONGEST. Use
plongest to format print it.
* f-valprint.c (f77_get_lowerbound): Return LONGEST.
(f77_get_upperbound): Likewise.
(f77_get_dynamic_length_of_aggregate): Expand UPPER_BOUND,
LOWER_BOUND to LONGEST.
(f77_create_arrayprint_offset_tbl): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-bounds.exp: New file.
* gdb.fortran/array-bounds.f90: New file.
This series is revisit of Siddhesh Poyarekar's patch from back in
2012. The last status on the patch is in the following gdb-patches
thread:
https://sourceware.org/ml/gdb-patches/2012-08/msg00562.html
It appears that Tom approved the patch, but Jan had some issues
with a compiler error that made the test fail on -m32 test runs.
He wrote up a hand-tweaked .S file to deal with it. Siddesh said
he would update tests. Then nothing.
Siddesh and Jan have both moved on since.
The patch originally required a large precursor patch to work.
I have whittled this down to/rewritten the bare minimum, and this
first patch is the result, changing the type of TYPE_LENGTH
to ULONGEST from unsigned int.
The majority of the changes involve changing printf format
strings to use %s and pulongest instead of %d.
gdb/ChangeLog:
* ada-lang.c (ada_template_to_fixed_record_type_1): Use
%s/pulongest for TYPE_LENGTH instead of %d in format
strings.
* ada-typerint.c (ada_print_type): Likewise.
* amd64-windows-tdep.c (amd64_windows_store_arg_in_reg): Likewise.
* compile/compile-c-support.c (generate_register_struct): Likewise.
* gdbtypes.c (recursive_dump_type): Likewise.
* gdbtypes.h (struct type) <length>: Change type to ULONGEST.
* m2-typeprint.c (m2_array): Use %s/pulongest for TYPE_LENGTH
instead of %d in format strings.
* riscv-tdep.c (riscv_type_alignment): Cast second argument
to std::min to ULONGEST.
* symmisc.c (print_symbol): Use %s/pulongest for TYPE_LENGTH
instead of %d in format strings.
* tracepoint.c (info_scope_command): Likewise.
* typeprint.c (print_offset_data::update)
(print_offset_data::finish): Likewise.
* xtensa-tdep.c (xtensa_store_return_value)
(xtensa_push_dummy_call): Likewise.
shrink_dynamic_reloc_sections must remove PLT entry that was created for
an undefined weak symbol in the presence of --export-dynamic option when
relaxation coalesces literals pointing to that symbol. This fixes the
following assertion:
ld: BFD (GNU Binutils) 2.31.1 internal error, aborting at
elf32-xtensa.c:3292 in elf_xtensa_finish_dynamic_sections
2019-03-29 Max Filippov <jcmvbkbc@gmail.com>
bfd/
* elf32-xtensa.c (shrink_dynamic_reloc_sections): Add
info->export_dynamic to the conditional.
ld/
* testsuite/ld-xtensa/relax-undef-weak-pie-export-dynamic.d: New
test definition.
* testsuite/ld-xtensa/xtensa.exp
(relax-undef-weak-pie-export-dynamic): Add new test.
This commit:
commit ef9866970c
Date: Thu Mar 28 06:40:30 2019 +0900
sim/common: convert sim-arange to use sim-inline
broke many simulator targets. I fixed aarch64 in a previous commit
without realising how many other target were also broken.
This commit adds the missing includes (sim-assert.h and libiberty.h),
which seem to be needed by many simulator targets, in a central
location, this should fix most builds.
sim/common/ChangeLog:
* sim-base.h: Add 'sim-assert.h' include.
* sim-basics.h: Add 'libiberty.h' include.
DWORD type is not a long on 64-bit Cygwin, because that it is LP64.
Explicitly cast DWORD values to unsigned long and use an appropriate
format.
gdb/ChangeLog:
2019-03-28 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (display_selector): Fixed format specifications
for 64-bit Cygwin.
Similarly to multi-arch-exec.exp, increase the alarm timer to avoid
test blocking under high load or with a slow gdb.
2019-03-28 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.multi/multi-term-settings.c (main): Increase alarm timer.
When running multi-arch-exec.exp under valgrind, the test succeeds
when the machine is not loaded, but blocks when the machine is highly
loaded (e.g. when running the testsuite with valgrind with -j X
where X is one more than the nr of available cores).
The problem is that the hello program dies too early due to the alarm (30).
So, increase the alarm timer.
Note that this does not make the test take longer (it takes about
3.5 seconds on my system). As I understand, the alarm is just there
to avoid hello staying there forever in case of another problem.
2019-03-28 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.multi/hello.c (main): Increase alarm timer.
When running under valgrind, multi-arch-exec.exp blocks forever.
Some (painful) investigation shows this is due to valgrind slowing
down GDB, and GDB has to output some messages at a different time,
when GDB does not have the terminal for output.
To reproduce the problem, you need to slow down GDB.
It can be reproduced by:
cd gdb/testsuite/outputs/gdb.multi/multi-arch-exec/
../../../../gdb -ex 'set debug lin-lwp 1' -ex 'break all_started' -ex 'run' ./2-multi-arch-exec
The above stops at a breakpoint. Do continue.
GDB is then suspended because of SIGTTOU.
The stacktrace that leads to the hanging GDB is:
(top-gdb) bt
at ../../binutils-gdb/gdb/exceptions.c:130
....
Alternatively, the same happens when doing
strace -o s.out ../../../../gdb -ex 'break all_started' -ex 'run' ./2-multi-arch-exec
And of course, valgrind is also sufficiently slowing down GDB to
reproduce this :).
Fix this by calling target_terminal::ours_for_output ();
at the beginning of follow_exec.
Note that all this terminal handling is not very clear to me:
* Some code takes the terminal, and then takes care to give it back to the inferior
if the terminal was belonging to the inferior.
(e.g. annotate_breakpoints_invalid).
* some code takes the terminal, but does not give it back
(e.g. update_inserted_breakpoint_locations).
* some code takes it, and unconditionally gives it back
(e.g. handle_jit_event)
* here and there, we also find
gdb::optional<target_terminal::scoped_restore_terminal_state> term_state;
before a (sometimes optional) call to ours_for_output.
And such calls to ours_for_output is sometimes protected by:
if (target_supports_terminal_ours ())
(e.g. exceptions.c: print_flush).
but most of the code calls it without checking if the target supports it.
* some code is outputting some errors, but only takes the terminal
after. E.g. infcmd.c: prepare_one_step
gdb/ChangeLog
2019-03-28 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* infrun.c (follow_exec): Call target_terminal::ours_for_output.
This patch fixes a problem on nios2-linux-gnu with stepping past the
kernel helper __kuser_cmpxchg, which was exposed by the testcase
gdb.threads/watchpoint-fork.exp. The kernel maps this function into
user space on an unwritable page. In this testcase, the cmpxchg
helper is invoked indirectly from the setbuf call in the test program.
Since this target lacks hardware breakpoint/watchpoint support, GDB
tries to single-step through the program by setting software
breakpoints, and was just giving an error when it reached the function
on the unwritable page.
The solution here is to always step over the call instead of stepping
into it; cmpxchg is supposed to be an atomic operation so this
behavior seems reasonable. The hook in nios2_get_next_pc is somewhat
generic, but at present cmpxchg is the only helper provided by the
Linux kernel that is invoked by an ordinary function call. (Signal
return trampolines also go through the unwritable page but not by a
function call.)
Fixing this issue also revealed that the testcase needs a much larger
timeout factor when software single-stepping is used. That has also
been fixed in this patch.
gdb/ChangeLog
2019-03-28 Sandra Loosemore <sandra@codesourcery.com>
* nios2-tdep.h (struct gdbarch_tdep): Add is_kernel_helper.
* nios2-tdep.c (nios2_get_next_pc): Skip over kernel helpers.
* nios2-linux-tdep.c (nios2_linux_is_kernel_helper): New.
(nios2_linux_init_abi): Install it.
gdb/testsuite/ChangeLog
2019-03-28 Sandra Loosemore <sandra@codesourcery.com>
* gdb.threads/watchpoint-fork.exp (test): Use large timeout
factor when no hardware watchpoint support.
When testing using native-gdbserver and native-extended-gdbserver, the sysroot
is not set. This results in a warning from GDB and files are sent via the
remote protocol, which can be slow.
On Ubuntu 18.04 (unlike most distros) the debug versions of the standard
libraries are included by default in /usr/lib/debug/.
These file reads are causing a complete native-gdbserver run on the AArch64
buildbot slave to timeout after 2.5 hours. This is also causing the builds
to back up on the slave.
The solution is to ensure the sysroot is set to / for all local boards.
This drastically reduces the time of a test. For example, gdb.base/sigall.exp
drops from 23 seconds to 4 seconds.
A full native-gdbserver run on the AArch64 slave now takes 8 minutes.
gdb/testsuite/ChangeLog:
* boards/local-board.exp: set sysroot to /.
This commit:
commit ef9866970c
Date: Thu Mar 28 06:40:30 2019 +0900
sim/common: convert sim-arange to use sim-inline
Broke the simulator build for aarch64 - some required macros are no
longer included where needed, fixed in this commit.
sim/aarch64/ChangeLog:
* cpustate.c: Add 'libiberty.h' include.
* interp.c: Add 'sim-assert.h' include.
When SVE is enabled, the V registers become pseudo registers based
on the Z registers. They should look the same as they do when
there is no SVE.
The existing code viewed them as single value registers. Switch
this to a vector.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_vnv_type): Use vector types.
SVE can view Z registers as 128bit values using .q prefix.
Add this view to the SVE feature.
gdb/ChangeLog:
* features/aarch64-sve.c (create_feature_aarch64_sve): Add q view.
When using older compilers, AT_HWCAP2 may not be be defined.
It is defined in elf/common.h, however including this in
gdbserver/linux-low.c causes conflicts.
Manually add the define if it does not exist.
gdb/gdbserver/ChangeLog:
* linux-low.c (AT_HWCAP2): Add define if not already included.
"mtfsb0 4*cr7+lt" doesn't make all that much sense, but unfortunately
glibc uses just that instead of "mtfsb0 28" to clear the fpscr xe bit.
So for backwards compatibility accept cr field expressions when
assembling mtfsb operands, but disassemble to a plain number.
PR 24390
include/
* opcode/ppc.h (PPC_OPERAND_CR_REG): Comment.
opcodes/
* ppc-opc.c (BTF): Define.
(powerpc_opcodes): Use for mtfsb*.
* ppc-dis.c (print_insn_powerpc): Print fields with both
PPC_OPERAND_CR_REG and PPC_OPERAND_CR_BIT as a plain number.
gas/
* testsuite/gas/ppc/476.d: Update mtfsb*.
* testsuite/gas/ppc/a2.d: Likewise.
During building of several cgen simulator's I notices the below
warnings. Adding includes fixes these.
Including config.h allows stdio.h to properly configure itself to expose
asprintf().
The other warnings for abort, free, memset, strlen are trivial.
Warnings:
../../../binutils-gdb/sim/or1k/../common/sim-watch.c: In function ‘sim_watchpoint_install’:
../../../binutils-gdb/sim/or1k/../common/sim-watch.c:415:10: warning: implicit declaration of function ‘asprintf’; did you mean ‘vasprintf’? [-Wimplicit-function-declaration]
if (asprintf (&name, "watch-%s-%s",
^~~~~~~~
vasprintf
../../../binutils-gdb/sim/lm32/../common/hw-device.c: In function ‘hw_strdup’:
../../../binutils-gdb/sim/lm32/../common/hw-device.c:59:34: warning: implicit declaration of function ‘strlen’ [-Wimplicit-function-declaration]
char *dup = hw_zalloc (me, strlen (str) + 1);
^~~~~~
../../../binutils-gdb/sim/lm32/../common/hw-events.c: In function ‘hw_event_queue_schedule’:
../../../binutils-gdb/sim/lm32/../common/hw-events.c:92:3: warning: implicit declaration of function ‘memset’ [-Wimplicit-function-declaration]
memset (&dummy, 0, sizeof dummy);
^~~~~~
../../../binutils-gdb/sim/lm32/../common/hw-handles.c: In function ‘hw_handle_remove_ihandle’:
../../../binutils-gdb/sim/lm32/../common/hw-handles.c:211:4: warning: implicit declaration of function ‘free’ [-Wimplicit-function-declaration]
free (delete);
^~~~
../../../binutils-gdb/sim/lm32/../common/sim-fpu.c: In function ‘pack_fpu’:
../../../binutils-gdb/sim/lm32/../common/sim-fpu.c:292:7: warning: implicit declaration of function ‘abort’ [-Wimplicit-function-declaration]
abort ();
^~~~~
sim/common/ChangeLog:
* sim-options.c: Include "config.h".
Include <stdio.h>.
* sim-watch.c: Include "config.h".
Include <stdio.h>.
* hw-device.c: Include <string.h>.
* hw-events.c: Include <string.h>.
* hw-handles.c: Include <stdlib.h>.
* sim-fpu.c: Include <stdlib.h>.
This fixes a TODO item and also fixes an error which we get when
building with no optimizations (-O0) in at least gcc 8.2.1.
Tested with sims that use cgen code lm32, or1k, cris, m32r and inlining
is working corretly.
Reference Error:
gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL='"or1200"' -DWITH_ALIGNMENT=STRICT_ALIGNMENT \
-DWITH_TARGET_WORD_BITSIZE=32 -DWITH_TARGET_WORD_MSB=31 -DWITH_TARGET_ADDRESS_BITSIZE=32 \
-DWITH_TARGET_BYTE_ORDER=BFD_ENDIAN_BIG -DDEFAULT_INLINE=0 -DWITH_SCACHE=16384 \
-I. -I../../../binutils-gdb/sim/or1k -I../common -I../../../binutils-gdb/sim/or1k/../common \
-I../../include -I../../../binutils-gdb/sim/or1k/../../include -I../../bfd \
-I../../../binutils-gdb/sim/or1k/../../bfd -I../../opcodes -I../../../binutils-gdb/sim/or1k/../../opcodes \
-g -o run nrun.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a ../../libiberty/libiberty.a \
-ldl -lz -lm
/usr/bin/ld: libsim.a(mloop.o): in function `extract':
/home/shorne/work/openrisc/gdb-musl/sim/or1k/mloop.c:82: undefined reference to `sim_addr_range_hit_p'
/usr/bin/ld: /home/shorne/work/openrisc/gdb-musl/sim/or1k/mloop.c:83: undefined reference to `sim_addr_range_hit_p'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:305: run] Error 1
sim/common/ChangeLog:
* Make-common.in (sim-arange_h): Remove sim-arange.c
* sim-arange.c: Remove SIM_ARANGE_C.
Add ifdef for _SIM_ARANGE_C_.
Include "sim-arange.h".
Remove include for unused "sim-assert.h".
Remove DEFINE_INLINE_P. Remove DEFINE_NON_INLINE_P.
(sim_addr_range_add): Declare as INLINE_SIM_ARANGE.
(sim_addr_range_delete): Declare as INLINE_SIM_ARANGE.
(sim_addr_range_hit_p): Change from SIM_ARANGE_INLINE to
INLINE_SIM_ARANGE.
* sim-arange.h (sim_addr_range_add): Declare as
INLINE_SIM_ARANGE.
(sim_addr_range_delete): Declare as INLINE_SIM_ARANGE.
(sim_addr_range_hit_p) Declare as INLINE_SIM_ARANGE.
Remove definition of SIM_ARANGE_INLINE.
Remove [HAVE_INLINE].
Wrap include "sim-arange.c" in H_REVEALS_MODULE_P.
* sim-base.h: Include "sim-arange.h"
* sim-basics.h: Remove include of "sim-arange.h"
* sim-inline.c: Include "sim-arange.c"
* sim-inline.h: Define INLINE_SIM_ARANGE.
Define SIM_ARANGE_INLINE. Define EXTERN_SIM_ARANGE_P.
Define STATIC_INLINE_SIM_ARANGE. Define STATIC_SIM_ARANGE.
Valgrind detects the following error in a bunch of tests,
e.g. in gdb.base/foll-fork.exp.
==15155== VALGRIND_GDB_ERROR_BEGIN
==15155== Invalid read of size 8
==15155== at 0x55BE04: minimal_symbol_upper_bound(bound_minimal_symbol) (minsyms.c:1504)
==15155== by 0x3B2E9C: find_pc_partial_function(unsigned long, char const**, unsigned long*, unsigned long*, block const**) (blockframe.c:340)
==15155== by 0x3B3135: find_function_entry_range_from_pc(unsigned long, char const**, unsigned long*, unsigned long*) (blockframe.c:385)
==15155== by 0x4F5597: fill_in_stop_func(gdbarch*, execution_control_state*) [clone .part.16] (infrun.c:4124)
==15155== by 0x4FBE01: fill_in_stop_func (infrun.c:7636)
==15155== by 0x4FBE01: process_event_stop_test(execution_control_state*) (infrun.c:6279)
...
==15155== Address 0x715bec8 is 0 bytes after a block of size 2,952 alloc'd
==15155== at 0x4C2E2B3: realloc (vg_replace_malloc.c:836)
==15155== by 0x405F2C: xrealloc (common-utils.c:62)
==15155== by 0x55BA4E: xresizevec<minimal_symbol> (poison.h:170)
==15155== by 0x55BA4E: minimal_symbol_reader::install() (minsyms.c:1399)
==15155== by 0x4981C7: elf_read_minimal_symbols (elfread.c:1165)
...
This seems to be a regression created by:
commit 042d75e42c
Author: Tom Tromey <tom@tromey.com>
AuthorDate: Sat Mar 2 12:29:48 2019 -0700
Commit: Tom Tromey <tom@tromey.com>
CommitDate: Fri Mar 15 16:02:10 2019 -0600
Allocate minimal symbols with malloc
Before this commit, the array of 'struct minimal_symbol'
contained a last element that was a "null symbol". The comment in
minimal_symbol_reader::install was:
/* We also terminate the minimal symbol table with a "null symbol",
which is *not* included in the size of the table. This makes it
easier to find the end of the table when we are handed a pointer
to some symbol in the middle of it. Zero out the fields in the
"null symbol" allocated at the end of the array. Note that the
symbol count does *not* include this null symbol, which is why it
is indexed by mcount and not mcount-1. */
memset (&msymbols[mcount], 0, sizeof (struct minimal_symbol));
However, minimal_symbol_upper_bound was still based on the assumption
that the array of minsym is terminated by a minsym with a null symbol:
it is looping with:
for (i = 1; MSYMBOL_LINKAGE_NAME (msymbol + i) != NULL; i++)
Replace this NULL comparison by a logic that calculates how
many msymbol are following the msymbols from which we are starting from.
(Re-)tested on debian/amd64, natively and under valgrind.
gdb/ChangeLog
2019-03-24 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Tom Tromey <tromey@adacore.com>
* minsyms.c (minimal_symbol_upper_bound): Fix buffer overflow.
Looking at the AArch64 buildbot, I noticed about two dozen old instances of
interrupt-daemon-attach taking up a full 100% cpu each.
If the test fails then the test binary relies on an alarm to ensure it dies
after 60 seconds.
As per the Linux man page for alarm:
Alarms created by alarm() ... are not inherited by children created via fork.
Update the test to add an alarm in the child and also put a sleep in the
child loop so it does not constantly consume cpu.
Note I haven't managed to re-create why the test failed. This fix will just
stop it hanging and consuming cpu when it does.
gdb/testsuite/ChangeLog:
* gdb.base/interrupt-daemon-attach.c (main): Add alarm and sleep
in child.
I noticed that trying to print the contents of a struct main_type
would fail when the type was a TYPE_CODE_RANGE:
(gdb) p *type.main_type
$1 = Python Exception <class 'gdb.error'> There is no member named low_undefined.:
And indeed, Python is right, fields "low_undefined" has been removed
from struct range_bounds back in ... 2014! It was done when we introduced
dynamic bounds handling. This patch fixes gdb-gdb.py.in according to
the new structure.
gdb/ChangeLog:
* gdb-gdb.py.in (StructMainTypePrettyPrinter.bound_img): New method.
(StructMainTypePrettyPrinter.bounds_img): Use new "bound_img"
method to compute the bounds of range types. Also print "[evaluated]"
if the bounds' values come from a dynamic evaluation.
The documentation say that the display_hint method must return a
string to serve as a display hint, and then goes on to list some
acceptable strings.
However, if we don't supply the display_hint method then we get a
default display style behaviour and there's currently no way (in the
python api) to force this default behaviour.
The guile api allows #f to be used in order to force the default
display style behaviour, and this is documented.
Currently, using None in the python api also forces the default
display behaviour.
This commit extends the documentation to make returning None from the
display_hint method an official mechanism by which the user can get
the default display style.
I've extended one of the existing tests to cover this case.
gdb/doc/ChangeLog:
* python.texi (Pretty Printing API): Document use of None for the
display_hint.
gdb/testsuite/ChangeLog:
* gdb.python/py-prettyprint.c (struct container) <is_map_p>: New
field.
(make_container): Initialise new field.
* gdb.python/py-prettyprint.exp: Add new tests.
* gdb.python/py-prettyprint.py (class ContainerPrinter)
<display_hint>: New method.
This makes the test names unique in gdb.python/py-prettyprint.exp, it
also switches to use gdb_breakpoint and gdb_continue_to_breakpoint
more so that we avoid test names with the source line number in - this
is bad if the test source ever changes as the test names will then
change.
One final change is to switch from using gdb_py_test_silent_cmd to use
gdb_test_no_output, the former should be used for running python
commands and can catch any thrown exception. However, in this case
the command being run is not a python command, its just a normal GDB
CLI command that produces no output, so lets use the appropriate
wrapper function.
gdb/testsuite/ChangeLog:
* gdb.python/py-prettyprint.exp: Use gdb_breakpoint and
gdb_continue_to_breakpoint more throughout this test.
(run_lang_tests) Supply unique test names, and use
gdb_test_no_output.
While writing a new test for 'set print pretty on' I spotted that GDB
will sometimes add a trailing whitespace character when pretty
printing. This commit removes the trailing whitespace and updates the
expected results in one tests where this was an issue.
I've added an extra test for 'set print pretty on' as it doesn't seem
to have much testing.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Don't print trailing
whitespace when pretty printing is on.
gdb/testsuite/ChangeLog:
* gdb.base/finish-pretty.exp: Update expected results.
* gdb.base/pretty-print.c: New file.
* gdb.base/pretty-print.exp: New file.
This fixes the testcases that are failing due to my recent patch.
It turns out that the start address across baremetal and linux builds
isn't entirely predictable without a linker script. Since the address
themselves are not the important thing I am ignoring them now.
Secondly I was encoding data using .word using non 0 values, however
because .word is subjected to endiannes these non-zero values under
big-endian happen to fall into the encoding space of instructions which
changes the disassembly. Using 0 fixes this problem and the purpose of
the test still holds, though objdump will dump ... for data only sections,
which is ok as the data/insn mixed sections will test the patch.
The ARM Attributes sections is not important and is ignored.
binutils/ChangeLog:
* testsuite/binutils-all/aarch64/in-order.d: Likewise.
* testsuite/binutils-all/aarch64/out-of-order-all.d: Likewise.
* testsuite/binutils-all/aarch64/out-of-order.d: Likewise.
* testsuite/binutils-all/aarch64/out-of-order.s: Likewise.
* testsuite/binutils-all/arm/in-order-all.d: Likewise.
* testsuite/binutils-all/arm/in-order.d: Likewise.
* testsuite/binutils-all/arm/out-of-order-all.d: Likewise.
* testsuite/binutils-all/arm/out-of-order.d: Likewise.
* testsuite/binutils-all/arm/out-of-order.s: Likewise.
