| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
see if sizeof cgen structs differ in some way.
|
|
Now that all ports have migrated to the new framework, drop support
for the old sim_cpu_base layout. There's a lot of noise here, so
it's been split into a dedicated commit.
|
|
All ports should be migrated now. Drop the SIM_HAVE_COMMON_SIM_CPU
knob and require it be used everywhere now.
|
|
The cpu.h change is in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
The cpu*.h changes are in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
The cpu.h change is in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
The cpu.h change is in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
The cpu.h change is in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
The cpu*.h changes are in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
The cpu.h change is in generated cgen code, but that has been sent
upstream too, so the next regen should include it automatically.
|
|
Some common cgen code changes to allow cgen ports to invert their
sim_cpu storage one-by-one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently all ports have to declare sim_cpu themselves in their
sim-main.h and then embed the common sim_cpu_base in it. This
dynamic makes it impossible to share common object code among
multiple ports because the core data structure is always different.
Let's invert this relationship: common code declares sim_cpu, and
the port uses the new arch_data field for its per-cpu state.
This is the first in a series of changes: it adds a define to select
between the old & new layouts, then converts all the ports that don't
need custom state over to the new layout. This includes mn10300 that,
while it defines custom fields in its cpu struct, never uses them.
|
|
|
|
Other arches use the .dc extension for the instruction decode table.
|
|
The parser for boolean rules fails to skip over the , separator in
the options which makes it hang forever. No dc files in the tree
use boolean rules atm which is why no one noticed.
|
|
|
|
... and fix the legitimate bug that it catches.
|
|
|
|
To make it clear this is an input to the igen tool, rename it with an
igen extension. This matches the other files in the ppc dir (altivec
& e500 igen files), and the other igen ports (mips, mn10300, v850).
|
|
(%dx) isn't a valid memory address in any modes. It is used as a special
memory operand for input/output port address in AT&T syntax and should
only be used with input/output instructions. Update i386_att_operand to
set i.input_output_operand to true for (%dx) and issue an error if (%dx)
is used with non-input/output instructions.
PR gas/29751
* config/tc-i386.c (_i386_insn): Add input_output_operand.
(md_assemble): Issue an error if input/output memory operand is
used with non-input/output instructions.
(i386_att_operand): Set i.input_output_operand to true for
(%dx).
* testsuite/gas/i386/inval.l: Updated.
* testsuite/gas/i386/x86-64-inval.l: Likewise.
* testsuite/gas/i386/inval.s: Add tests for invalid (%dx) usage.
* testsuite/gas/i386/x86-64-inval.s: Likewise.
|
|
I saw this failure on a CI:
(gdb) add-inferior
[New inferior 2]
Added inferior 2
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: add-inferior
inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 2
kill
The program is not being run.
(gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep...
(gdb) run &
Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior-sleep
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: run inferior 2
inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: inferior 1
kill
The program is not being run.
(gdb) file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
Reading symbols from /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior...
(gdb) break should_break_here
Breakpoint 1 at 0x11b1: file /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior.c, line 25.
(gdb) PASS: gdb.threads/vfork-multi-inferior.exp: method=non-stop: break should_break_here
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
start
Temporary breakpoint 2 at 0x11c0: -qualified main. (2 locations)
Starting program: /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/tmp/tmp.GYATAXR8Ku/gdb/testsuite/outputs/gdb.threads/vfork-multi-inferior/vfork-multi-inferior
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Thread 2.1 "vfork-multi-inf" hit Temporary breakpoint 2, main () at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/gdb/testsuite/gdb.threads/vfork-multi-inferior-sleep.c:23
23 sleep (30);
(gdb) FAIL: gdb.threads/vfork-multi-inferior.exp: method=non-stop: start inferior 1
What happens is:
1. We start inferior 2 with "run&", it runs very slowly, takes time to
get to main
2. We switch to inferior 1, and run "start"
3. The temporary breakpoint inserted by "start" applies to all inferiors
4. Inferior 2 hits that breakpoint and GDB reports that hit
To avoid this, breakpoints inserted by "start" should be
inferior-specific. However, we don't have a nice way to make
inferior-specific breakpoints yet. It's possible to make
pspace-specific breakpoints (for example how the internal_breakpoint
constructor does) by creating a symtab_and_line manually. However,
inferiors can share program spaces (usually on particular embedded
targets), so we could have a situation where two inferiors run the same
code in the same program space. In that case, it would just not be
possible to insert a breakpoint in one inferior but not the other.
A simple solution that should work all the time is to add a condition to
the breakpoint inserted by "start", to check the inferior reporting the
hit is the expected one. This is what this patch implements.
Add a test that does:
- start in background inferior 1 that sleeps before reaching its main
function (using a sleep in a global C++ object's constructor)
- start inferior 2 with the "start" command, which also sleeps before
reaching its main function
- validate that we hit the breakpoint in inferior 2
Without the fix, we hit the breakpoint in inferior 1 pretty much all the
time. There could be some unfortunate scheduling causing the test not
to catch the bug, for instance if the scheduler decides not to schedule
inferior 1 for a long time, but it would be really rare. If the bug is
re-introduced, the test will catch it much more often than not, so it
will be noticed.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: Ib0148498a476bfa634ed62353c95f163623c686a
|
|
Commit 041de3d73aa changed the output format of all error messages when
GDB couldn't determine a compatible overload for a given function, but
it was only supposed to change if the failure happened due to incomplete
types. This commit removes the stray . that was added
|
|
If the download size is known, a progress bar is displayed along with
the percentage of completion and the total download size.
Downloading separate debug info for /lib/libxyz.so
[############ ] 25% (10.01 M)
If the download size is not known, a progress indicator is displayed
with a ticker ("###") that moves across the screen at a rate of 1 tick
every 0.5 seconds.
Downloading separate debug info for /lib/libxyz.so
[ ### ]
If the output stream is not a tty, batch mode is enabled, the screen is
too narrow or width has been set to 'unlimited', then only a static
description of the download is printed. No bar or ticker is displayed.
Downloading separate debug info for /lib/libxyz.so...
In any case, if the size of the download is known at the time the
description is printed then it will be included in the description.
Downloading 10.01 MB separate debug info for /lib/libxyz.so...
|
|
I noticed this problem while preparing the initial submission for the
ROCm GDB port. One particularity of this patch set is that it does not
support unwinding frames, that requires support of some DWARF extensions
that will come later. It was still possible to run to a breakpoint and
print frame #0, though.
When rebasing on top of the frame_info_ptr work, GDB started tripping on
a prepare_reinflate call, making it not possible anymore to event print
the frame when stopping on a breakpoint. One thing to know about frame
0 is that its id is lazily computed when something requests it through
get_frame_id. See:
https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L2070-2080
So, up to that prepare_reinflate call, frame 0's id was not computed,
and prepare_reinflate, calling get_frame_id, forces it to be computed.
Computing the frame id generally requires unwinding the previous frame,
which with my ROCm GDB patch fails. An exception is thrown and the
printing of the frame is simply abandonned.
Regardless of this ROCm GDB problem (which is admittedly temporary, it
will be possible to unwind with subsequent patches), we want to avoid
prepare_reinflate to force the computing of the frame id, for the same
reasons we lazily compute it in the first place.
In addition, frame 0's id is subject to change across a frame cache
reset. This is why save_selected_frame and restore_selected_frame have
special handling for frame 0:
https://gitlab.com/gnutools/binutils-gdb/-/blob/23912acd402f5af9caf91b257e5209ec4c58a09c/gdb/frame.c#L1841-1863
For this last reason, we also need to handle frame 0 specially in
prepare_reinflate / reinflate. Because the frame id of frame 0 can
change across a frame cache reset, we must not rely on the frame id from
that frame to reinflate it. We should instead just re-fetch the current
frame at that point.
This patch adds a frame_info_ptr::m_cached_level field, set in
frame_info_ptr::prepare_reinflate, so we can tell if a frame is frame 0.
There are cases where a frame_info_ptr object wraps a sentinel frame,
for which frame_relative_level returns -1, so I have chosen the value -2
to represent "invalid frame level", for when the frame_info_ptr object
is empty.
In frame_info_ptr::prepare_reinflate, only cache the frame id if the
frame level is not 0. It's fine to cache the frame id for the sentinel
frame, it will be properly handled by frame_find_by_id later.
In frame_info_ptr::reinflate, if the frame level is 0, call
get_current_frame to get the target's current frame. Otherwise, use
frame_find_by_id just as before.
This patch should not have user-visible changes with upstream GDB. But
it will avoid forcing the computation of frame 0's when calling
prepare_reinflate. And, well, it fixes the upcoming ROCm GDB patch
series.
Change-Id: I176ed7ee9317ddbb190acee8366e087e08e4d266
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
print_frame_info calls frame_info_ptr::reinflate, but not
frame_info_ptr::prepare_reinflate, add the call to prepare_reinflate.
It works right now, because all callers of print_frame_info that could
possibly lead to the pretty printers being called, and the frame_info
objects being invalidated, do call prepare_reinflate themselves. And
since the cached frame id is copied when passing a frame_info_ptr by
value, print_frame_info does have a cached frame id on entry. So
technically, this change isn't needed. But I don't think it's good for
a function to rely on its callers to have called prepare_reinflate, if
it intends to call reinflate.
Change-Id: Ie332b2d5479aef46f83fdc1120c7c83f4e84d1b0
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
frame_info_ptr::reinflate
The assertion
gdb_assert (m_cached_id != null_frame_id);
is always true, as comparing equal to null_frame_id is always false
(it's the first case in frame_id::operator==, not sure why it's not this
way, but that's what it is).
Replace the comparison with a call to frame_id_p.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I93986e6a85ac56353690792552e5b3b4cedec7fb
|
|
With the following patch applied (gdb: use frame_id_p instead of
comparing to null_frame_id in frame_info_ptr::reinflate), I would get:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame -ex "b breakpt" -ex r -ex "bt full"
Reading symbols from testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame...
Breakpoint 1 at 0x1131: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c, line 22.
Starting program: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/bt-selected-frame/bt-selected-frame
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
22 }
#0 breakpt () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/bt-selected-frame.c:22
No locals.
/home/smarchi/src/binutils-gdb/gdb/frame-info.c:42: internal-error: reinflate: Assertion `frame_id_p (m_cached_id)' failed.
This is because the code in backtrace_command_1 to manually reinflate
`fi` steps overs frame_info_ptr's toes.
When calling
fi.prepare_reinflate ();
`fi` gets properly filled with the cached frame id. But when this
happens:
fi = frame_find_by_id (frame_id);
`fi` gets replaced by a brand new frame_info_ptr that doesn't have a
cached frame id. Then this is called without a cached frame id:
fi.reinflate ();
That doesn't cause any problem currently, since
- the gdb_assert in the reinflate method doesn't actually do anything
(the following patch fixes that)
- `fi.m_ptr` will always be non-nullptr, since we just got it from
frame_find_by_id, so reinflate will not do anything, it won't try to
use m_cached_id
Fix that by removing the code to manually re-fetch the frame. That
should be taken care of by frame_info_ptr::reinflate.
Note that the old code checked if we successfully re-inflated the frame
or not, and if not it did emit a warning. The equivalent in
frame_info_ptr::reinflate asserts that the frame has been successfully
re-inflated. It's not clear if / when this can happen, but if it can
happen, we'll need to find a solution to this problem globally
(everywhere a frame_info_ptr can be re-inflated), not just here. So I
propose to leave it like this, until it does become a problem.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I07b783d94e2853e0a2d058fe7deaf04eddf24835
|
|
I don't see any particular reason why the implementations of the
frame_info_ptr object are in the header file. It only seems to add some
complexity. Since we can't include frame.h in frame-info.h, we have to
add declarations of functions defined in frame.c, in frame-info.h. By
moving the implementations to a new frame-info.c, we can avoid that.
Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
info_frame_command_core
I noticed this crash:
$ ./gdb --data-directory=data-directory -nx -q \
testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand \
-x testsuite/outputs/gdb.python/pretty-print-call-by-hand/pretty-print-call-by-hand.py \
-ex "b g" -ex r
(gdb) info frame
Stack level 0, frame at 0x7fffffffdd80:
rip = 0x555555555160 in g
(/home/simark/src/binutils-gdb/gdb/testsuite/gdb.python/pretty-print-call-by-hand.c:41); saved rip = 0x5555555551a3
called by frame at 0x7fffffffdda0
source language c.
Arglist at 0x7fffffffdd70, args: mt=mytype is 0x555555556004 "hello world",
depth=10
Fatal signal: Segmentation fault
This is another case of frame_info being invalidated under a function's
feet. The stack trace when the frame_info get invalidated looks like:
... many frames to pretty print the arg, that eventually invalidate the frame_infos ...
#35 0x00005568d0a8ab24 in print_frame_arg (fp_opts=..., arg=0x7ffc3216bcb0) at /home/simark/src/binutils-gdb/gdb/stack.c:489
#36 0x00005568d0a8cc75 in print_frame_args (fp_opts=..., func=0x621000233210, frame=..., num=-1, stream=0x60b000000300)
at /home/simark/src/binutils-gdb/gdb/stack.c:898
#37 0x00005568d0a9536d in info_frame_command_core (fi=..., selected_frame_p=true) at /home/simark/src/binutils-gdb/gdb/stack.c:1682
print_frame_args knows that print_frame_arg can invalidate frame_info
objects, and therefore calls prepare_reinflate/reinflate. However,
info_frame_command_core has a separate frame_info_ptr instance (it is
passed by value / copy). So info_frame_command_core needs to know that
print_frame_args can invalidate frame_info objects, and therefore needs
to prepare_reinflate/reinflate as well. Add those calls, and enhance
the gdb.python/pretty-print-call-by-hand.exp test to test that command.
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Change-Id: I9edaae06d62e97ffdb30938d364437737238a960
|
|
We do it in the move assignment operator, so I think it makes sense to
do it here too for consistency. I don't think it's absolutely necessary
to clear the other object's fields (in other words, copy constructor and
move constructor could be the same), as there is no exclusive resource
being transfered. The important thing is to leave the moved-from object
in an unknown, but valid state. But still, I think that clearing the
fields of the moved-from object is not a bad idea, it helps ensure we
don't rely on the moved-from object after.
Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
When resolving overloaded functions, GDB relies on knowing relationships
between types, i.e. if a type inherits from another. However, some
compilers may not add complete information for given types as a way to
reduce unnecessary debug information. In these cases, GDB would just say
that it couldn't resolve the method or function, with no extra
information.
The problem is that sometimes the user may not know that the type
information is incomplete, and may just assume that there is a bug in
GDB. To improve the user experience, we attempt to detect if the
overload match failed because of an incomplete type, and warn the user
of this.
This commit also adds a testcase confirming that the message is only
triggered in the correct scenario. This test was not developed as an
expansion of gdb.cp/overload.cc because it needed the dwarf assembler,
and porting all of overload.cc seemed unnecessary.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When calling get_func_info inside a test case, it would cause failures
if the function was printed using a C++ style mangled name. The current
patch fixes this by allowing for mangled names along with the current
rules.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
ld/ChangeLog:
* testsuite/ld-size/size.exp: Skip when -shared is not
supported.
|
|
* mach-o.c (bfd_mach_o_canonicalize_reloc): Set bfd_error on
multiply overflow.
|
|
The idea here is the stop tools from allocating up to 32G per section
for the arelent pointer array, only to find a little later that the
section reloc count was fuzzed. This usually doesn't hurt much (on
systems that allow malloc overcommit) except when compiled with asan.
We already do this for ELF targets, and while fixing the logic
recently I decided other targets ought to do the same.
* elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Sanity check
section reloc count against file size.
* mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
* aoutx.h (get_reloc_upper_bound): Likewise, and don't duplicate
check done in bfd_get_reloc_upper_bound.
* pdp11.c (get_reloc_upper_bound): Likewise.
* coffgen.c (coff_get_reloc_upper_bound): Likewise.
|
