| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This patch adds support for the Cortex-A720 CPU to binutils.
bfd/ChangeLog:
* cpu-aarch64.c: Add Cortex-A720.
gas/ChangeLog:
* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A720.
* doc/c-aarch64.texi: Update docs.
* testsuite/gas/aarch64/cpu-cortex-a720.d: New test.
|
|
Fixes the issue where jump failed if multiple inferiors run the same
source.
See the below example
$ gdb -q ./simple
Reading symbols from ./simple...
(gdb) break 2
Breakpoint 1 at 0x114e: file simple.c, line 2.
(gdb) run
Starting program: /temp/simple
Breakpoint 1, main () at simple.c:2
2 int a = 42;
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) info inferiors
Num Description Connection Executable
1 process 6250 1 (native) /temp/simple
* 2 <null> 1 (native)
(gdb) file ./simple
Reading symbols from ./simple...
(gdb) run
Starting program: /temp/simple
Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
2 int a = 42;
(gdb) info inferiors
Num Description Connection Executable
1 process 6250 1 (native) /temp/simple
* 2 process 6705 1 (native) /temp/simple
(gdb) jump 3
Unreasonable jump request
(gdb)
In this example, jump fails because the debugger finds two different
locations, one for each inferior.
Solution is to limit the search to the current program space.
This is done by having the jump_command function use
decode_line_with_current_source rather than
decode_line_with_last_displayed, which makes sense,
the *_current_source function always looks up a location based on the
current thread's location -- if a user is asking the current thread to
jump, then surely their destination should be relative to where the
current thread is located.
Then, inside decode_line_with_current_source, the call to
decode_line_1 is updated to pass through the current program_space,
which will limit the returned locations to those in the current
program space.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
|
|
From what I can tell, inferior::priv is reserved for the
process_stratum target. It seems to me that it has to be, because
currenlty only such targets use it, and if a target at another stratum
started using this field, then conflicts could occur. This patch
documents this.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
|
|
On some T-Head vendor extensions, we test against the constant
18446744073709551615 (2**64-1) to detect invalid immediate errors on -1.
However, it heavily depends on the fact that the value used to print
immediate value is a 64-bit unsigned type and this constant is not (and
should not be) important (we just want to know that -1 is not valid).
This commit replaces all such occurrences of 18446744073709551615 with
a more generic regular expression.
gas/ChangeLog:
* testsuite/gas/riscv/x-thead-ba-fail.l: Replace
18446744073709551615 with generic regular expression.
* testsuite/gas/riscv/x-thead-bb-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-bs-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-memidx-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-mempair-fail.l: Likewise.
|
|
The documentation of the 'Zfa' extension states that "fli.h" is available
"if the Zfh or Zvfh extension is implemented" (both the latest and the
oldest editions are checked).
This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
extensions are implemented.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add new
instruction class handling.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zfa-zvfh.s: New test.
* testsuite/gas/riscv/zfa-zvfh.d: Ditto.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.
|
|
This commit adds 'Zihintntl' extension and its hint instructions.
This is based on:
<https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>,
the first ISA Manual noting that the 'Zihintntl' extension is ratified.
Note that compressed 'Zihintntl' hints require either 'C' or
'Zca' extension.
Co-authored-by: Nelson Chu <nelson@rivosinc.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
standard hint 'Z' extension.
(riscv_multi_subset_supports): Support new instruction classes.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
including auto-compression without C prefix and explicit C prefix.
* testsuite/gas/riscv/zihintntl.d: Likewise.
* testsuite/gas/riscv/zihintntl-na.d: Likewise.
* testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
between 'Zihintntl' and base 'I' or 'C' instructions.
* testsuite/gas/riscv/zihintntl-base.d: Likewise.
include/ChangeLog:
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C.
(MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL,
MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL,
MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL,
MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL,
MATCH_C_NTL_ALL): New.
opcodes/ChangeLog:
* riscv-opc.c (riscv_opcodes): Add instructions from the
'Zihintntl' extension.
|
|
The longest register name is 4 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.
To avoid old gcc, when generating 32-bit code, bogusly warning about
bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
a 64-bit value, and it also doesn't need to - all operand fields to
date are far more narrow than 32 bits. This in turn allows dropping a
number of casts elsewhere.
|
|
The longest register name is 5 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.
|
|
|
|
When building gdb with -O2 -flto I run into:
...
ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
Definition Rule [-Werror=odr]
...
Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.
Likewise for yyalloc.
Tested on x86_64-linux. Also tested with byacc rather than bison on
suggestion of Tom Tromey.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
In addition, detach from any child processes implicitly attached to by
the kernel due to fork following that have not yet been processed by
GDB's core.
|
|
FreeBSD's ptrace fails requests with EBUSY against a running process.
Report that the thread is alive instead of dead if ptrace fails with
EBUSY.
This fixes an internal error in the gdb.threads/detach-step-over.exp
test where one process was detached while a thread in a second process
was being stepped. The core incorrectly assumed the stepping thread
had vanished and discarded the pending stepping state. When the
thread later reported a SIGTRAP from completing the step, this
triggered an assertion.
|
|
- Detach from any child processes implicitly attached to by the kernel
due to fork following that have not yet been processed by GDB's
core.
- Delete breakpoints before detaching.
inf-ptrace::detach does not do this (somewhat surprisingly), so add
an override to remove breakpoints from a process before detaching
from it.
This also requires explicitly draining any pending SIGTRAP events
for software breakpoints before detaching. In particular, threads
may need their PC adjusted due to the software breakpoint before
being resumed after detach. On more modern systems using the si_code
from SIGTRAP to identify software breakpoint traps, the PC is adjusted
in ::wait_1 as a side effect of parsing the event. To support older
kernels, ::detach fixes up the PC for any SIGTRAP stop whose potential
new PC matches an existing software breakpoint.
|
|
I did not fully understand the requirements of multiple process
support when I enabled it previously and several parts were broken.
In particular, the resume method was only resuming a single process,
and wait was not stopping other processes when reporting an event.
To support multiple running inferiors, add a new per-inferior
structure which trackes the number of existing and running LWPs for
each process. The structure also stores a ptid_t describing the
set of LWPs currently resumed for each process.
For the resume method, iterate over all non-exited inferiors resuming
each process matching the passed in ptid rather than only resuming the
current inferior's process for a wildcard ptid. If a resumed process
has a pending event, don't actually resume the process, but other
matching processes without a pending event are still resumed in case
the later call to the wait method requests an event from one of the
processes without a pending event.
For the wait method, stop other running processes before returning an
event to the core. When stopping a process, first check to see if an
event is already pending. If it is, queue the event to be reported
later. If not, send a SIGSTOP to the process and wait for it to stop.
If the event reported by the wait is not for the SIGSTOP, queue the
event and remember to ignore a future SIGSTOP event for the process.
Note that, unlike the Linux native target, entire processes are
stopped rather than individual LWPs. In FreeBSD one can only wait on
processes (via pid), not for an event from a specific thread.
Other changes in this commit handle bookkeeping for the per-inferior
data such as migrating the data to the new inferior in the follow_exec
method. The per-inferior data is created in the attach,
create_inferior, and follow_fork methods.
|
|
If wait_1 finds an event for a thread or process that does not match
the set of threads and processes previously resumed, defer the event.
If the event is for a specific thread, suspend the thread and continue
the associated process before waiting for another event.
One specific example of such an event is if a thread is created while
another thread in the same process hits a breakpoint. If the second
thread's event is reported first, the target resume method does not
yet "know" about the new thread and will not suspend it via
PT_SUSPEND. When wait is called, it will probably return the event
from the first thread before the result of the step from second
thread. This is the case reported in PR 21497.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21497
|
|
The m_pending_events list stores a queue of deferred events that might
be reported by the next call to the target's wait method. The set of
events that are eligible is filtered by the ptid passed to resume.
For now this just replaces the list of vfork_done events. A
subsequent commit will reuse this to store other events.
|
|
I noticed that the call to alloca in osabi.c can be replaced with a
statically-sized buffer, because some code just before the declaration
ensures that the length is bounded.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
When building gdb with -O2 -flto I run into:
...
/data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \
violates the C++ One Definition Rule [-Wodr]
struct token
^
/data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \
another translation unit
struct token
^
...
Fix this by renaming to c_token and d_token.
Likewise in:
- fortran-exp.y, renaming to f_token,
- go-exp.y, renaming to go_token, and
- p-exp.y, renaming to p_token.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
When build gdb with -O2 -flto I run into:
...
gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \
One Definition Rule [-Wodr]
struct token_and_value
^
gdb/d-exp.y:1310:8: note: a different type is defined in another translation \
unit
struct token_and_value
^
...
Fix this by renaming to c_token_and_value and d_token_and_value.
Likewise in gdb/go-exp.y, renaming to go_token_and_value.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
When building gdb with -O2 -flto, I run into:
...
gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \
One Definition Rule [-Wodr]
enum param_types
^
gdb/python/py-param.c:33:6: note: an enum with different value name is \
defined in another translation unit
enum param_types
^
...
Fix this by renaming to enum scm_param_types and py_param_types.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
In gdb/python/py-param.c we have:
...
enum param_types
{
...
}
param_types;
...
which declares both an enum param_types, and an unused variable param_types.
Fix this by removing the variable.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Consider the help text of "maint print symbols":
...
(gdb) help maint print symbols
Print dump of current symbol definitions.
Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE]
mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the full symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...
and "maint print psymbols":
...
(gdb) help maint print psymbols
Print dump of current partial symbol definitions.
Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE]
mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the partial symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...
The OBJFILE lines mistakingly mention minimal symbols.
Fix this by reformulating as "dump only that object file's symbols".
Also make the ADDRESS lines more clear by using the formulation: "dump only
the symbols for the file with code at that address".
Tested on x86_64-linux.
Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/30742
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742
|
|
pr23169b test only works with lazy binding. To work with linker which
disables lazy binding by default, build pr23169b binaries with -z lazy.
PR ld/30698
* ld-ifunc/ifunc.exp: Build pr23169b binaries with -z lazy.
|
|
No one should be using versions of dejagnu without prune_warnings,
which was available in 1996 (dejagnu-1.3).
binutils/
* testsuite/lib/binutils-common.exp: Remove fallback prune_warnings.
gas/
* testsuite/lib/gas-defs.exp: Remove fallback prune_warnings.
|
|
Tidy comment formatting.
|
|
Fix issue reported by Dave and Alan.
Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover
Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did
before.
ld/
PR 30733
PR 30734
* ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64
but include hppa1.1, hppa2.0.
* ld/testsuite/ld-elf/retain7a.d: Ditto.
Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49
Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
When running test-case gdb.python/py-symbol.exp with target board
cc-with-gdb-index, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
1^M
(gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr')))
...
[ Note that the test-case contains rr in both py-symtab.c:
...
static int __attribute__ ((used)) rr = 42; /* line of rr */
...
and py-symtab-2.c:
...
static int __attribute__ ((used)) rr = 99; /* line of other rr */
... ]
This passes with gdb-12-branch, and fails with gdb-13-branch.
AFAIU the current code in symtab_index_entry::minimize makes the assumption
that it's fine to store only one copy of rr in the gdb-index, because
"print rr" will only ever print one, and always the same.
But that fails to recognize that gdb supports gdb.lookup_static_symbols, which
returns a list of variables rather than the first one.
In other words, the current approach breaks feature parity between cooked
index and gdb-index.
Note btw that also debug-names has both instances:
...
[ 5] #00597969 rr:
<4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1
<4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1
...
Fix this in symtab_index_entry::minimize, by not deduplicating variables.
Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
PR symtab/30720
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720
|
|
gprofng GUI can be installed to the other directory.
In this case, $PATH is used to find gp-display-gui from gprofng
and option --gprofngdir is passed to gp-display-gui.
gprofng/ChangeLog
2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/gprofng.cc (Gprofng::exec_cmd): Add option --gprofngdir.
|
|
gprofng/ChangeLog
2023-08-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/Application.cc (Application::get_realpath): Fix typo.
* src/checks.cc (collect::check_executable): Likewise.
|
|
|
|
Add a missing return statement.
|
|
PR 30715
* config/tc-vax.c (md_create_long_jump): Use pc-relative addressing.
* testsuite/gas/vax/broken_word.d,
* testsuite/gas/vax/broken_word.s: New test.
* testsuite/gas/vax/vax.exp: Run it.
|
|
resume_stopped_resumed_lwps
At the moment, while performing a software single-step, gdbserver fails
to reinsert software single-step breakpoints for a LWP when
interrupted by a signal in another thread. This commit fixes this
problem by reinstalling software single-step breakpoints in
linux_process_target::resume_stopped_resumed_lwps in
gdbserver/linux-low.cc.
This bug was discovered due to a failing assert in maybe_hw_step()
in gdbserver/linux-low.cc. Looking at the backtrace revealed
that the caller was linux_process_target::resume_stopped_resumed_lwps.
I was uncertain whether the assert should still be valid when called
from that method, so I tried hoisting the assert from maybe_hw_step
to all callers except resume_stopped_resumed_lwps. But running the
new test case, described below, showed that merely eliminating the
assert for this case was NOT a good fix - a study of the log file for
the test showed that the single-step operation failed to occur.
Instead GDB (via gdbserver) stopped at the next breakpoint that was
hit.
Zhiyong Yan had proposed a fix which resinserted software single-step
breakpoints, albeit at a different location in linux-low.cc. Testing
revealed that, while running gdb.threads/pending-fork-event-detach,
the executable associated with that test would die due to a SIGTRAP
after the test program was detached. Examination of the core file(s)
showed that a breakpoint instruction had been left in program memory.
Test results were otherwise very good, so Zhiyong was definitely on
the right track!
This commit causes software single-step breakpoint(s) to be inserted
before the call to maybe_hw_step in resume_stopped_resumed_lwps. This
will cause 'has_single_step_breakpoints (thread)' to be true, so that
the assert in maybe_hw_step...
/* GDBserver must insert single-step breakpoint for software
single step. */
gdb_assert (has_single_step_breakpoints (thread));
...will no longer fail. And better still, the single-step breakpoints
are reinstalled, so that stepping will actually work, even when
interrupted.
The C code for the test case was loosely adapted from the reproducer
provided in Zhiyong's bug report for this problem. The .exp file was
copied from next-fork-other-thread.exp and then tweaked slightly. As
noted in a comment in next-fork-exec-other-thread.exp, I had to remove
"on" from the loop for non-stop as it was failing on all architectures
(including x86-64) that I tested. I have a feeling that it ought to
work, but this can be investigated separately and (re)enabled once it
works. I also increased the number of iterations for the loop running
the "next" commands. I've had some test runs which don't show the bug
until the loop counter exceeded 100 iterations. The C file for the
new test uses shorter delays than next-fork-other-thread.c though, so
it doesn't take overly long (IMO) to run this new test.
Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
userland using a gdbserver build without the fix in this commit shows
the following results:
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here
=== gdb Summary ===
# of unexpected core files 12
# of expected passes 3011
# of unexpected failures 14
Each of the 12 core files were caused by the failed assertion in
maybe_hw_step in linux-low.c. These correspond to 12 of the
unexpected failures.
When the tests are run using a gdbserver build which includes the fix
in this commit, the results are significantly better, but not perfect:
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line
=== gdb Summary ===
# of expected passes 10178
# of unexpected failures 2
I think that the two remaining failures are due to some different
problem. They are also racy - I've seen runs with no failures or only
one failure, but never more than two. Also, those runs were conducted
with the loop count in next-fork-exec-other-thread.exp set to 200.
During his testing of this fix and the new test case, Luis Machado
found that this test was taking a long time and asked about ways to
speed it up. I then conducted additional tests in which I gradually
reduced the loop count, timing each one, also noting the number of
failures. With the loop count set to 30, I found that I could still
reliably reproduce the failures that Zhiyong reported (in which, with
the proper settings, core files are created). But, with the loop
count set to 30, the other failures noted above were much less likely
to show up. Anyone wishing to investigate those other failures should
set the loop count back up to 200.
Running the new test on x86-64 and aarch64, both native and
native-gdbserver shows no failures.
Also, I see no regressions when running the entire test suite for
armv7l-unknown-linux-gnueabihf (i.e. the Raspberry Pi w/ 32-bit
kernel+userland) with --target_board=native-gdbserver. Additionally,
using --target_board=native-gdbserver, I also see no regressions for
the entire test suite for x86-64 and aarch64 running Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.
|
|
r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.
* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).
|
|
Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so
that the subdir configure scripts use the configured value.
* configure.ac (GDCFLAGS): Set default from ${CFLAGS}.
|
|
This allows us to invoke the rust testsuite.
* Makefile.def: Add Rust language.
|
|
This patch fixes PR bootstrap/106472 by adding a missing dependency
to Makefile.def to allow make bootstrap when configured using
"--enable-languages=go" (and not using make with multiple threads).
2022-07-31 Roger Sayle <roger@nextmovesoftware.com>
PR bootstrap/106472
* Makefile.def (dependencies): Make configure-target-libgo depend
upon all-target-libbacktrace.
|
|
|
|
Compilation during STAGEautofeedback produces additional warnings
since inlining decisions with -fauto-profile are different from
other builds.
This patches disables warnings as errors for STAGEautofeedback.
Tested on x86_64-pc-linux-gnu.
* Makefile.tpl: Disable warnings as errors for STAGEautofeedback
|
|
* Makefile.tpl: Define PROFILE_MERGER
|
|
cc1, cc1plus, and lto built during STAGEautoprofile need to be built with
debug info since they are used to build target libs. -gtoggle was
turning off debug info for this stage.
create_gcov should be passed prev-gcc/cc1, prev-gcc/cc1plus, and prev-gcc/lto
instead of stage1-gcc/cc1, stage1-gcc/cc1plus, and stage1-gcc/lto when
processing profile data collected while building target libraries.
Tested on x86_64-pc-linux-gnu.
* Makefile.tpl: Remove -gtoggle for STAGEautoprofile
|
|
When we collect just user events for autofdo with lbr we get some events where branch
sources are kernel addresses and branch targets are user addresses. Without kernel MMAP
events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if
it can't map at least 95% of events. We sometimes get below this threshold with just
user events. The change is to collect both user events and kernel events.
Tested on x86_64-pc-linux-gnu.
* Makefile.tpl: Collect both kernel and user events for autofdo
|
|
The D front-end is now itself written in D, in order to build GDC, you
will need a working GDC compiler (GCC version 9.1 or later).
GCC changes:
- Add support for bootstrapping the D front-end.
These add the required components in order to have a D front-end written
in D itself. Because the compiler front-end only depends on the core
runtime modules, only libdruntime is built for the bootstrap stages.
D front-end changes:
- Import dmd v2.098.0-beta.1.
Druntime changes:
- Import druntime v2.098.0-beta.1.
Phobos changes:
- Import phobos v2.098.0-beta.1.
The jump from v2.076.1 to v2.098.0 covers nearly 4 years worth of
development on the D programming language and run-time libraries.
* Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
libatomic.
* Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
(STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
target-libphobos-bootstrap.
(STAGE2_CONFIGURE_FLAGS): Likewise.
|
|
Use of libelf was removed from gcc in r0-104274-g48215350c24d52 ("re PR
lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0.
This change removes unused references to libelf from top-level configure
and Makefile.
* Makefile.def: Drop libelf module and gcc-configure dependency
on it.
* Makefile.tpl (HOST_EXPORTS): Drop unused LIBELFLIBS and
LIBELFINC.
|
|
PR gcov-profile/94570
* ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM
for CYGWIN.
Co-Authored-By: Jonathan Yong <10walls@gmail.com>
|
