| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
While reading the interface of gdb::array_view, I realized that the
constructor that builds an array_view on top of a contiguous container
(such as std::vector, std::array or even gdb::array_view) can be
missused.
Lets consider the following code sample:
struct Parent
{
Parent (int a): a { a } {}
int a;
};
std::ostream &operator<< (std::ostream& os, const Parent & p)
{ os << "Parent {a=" << p.a << "}"; return os; }
struct Child : public Parent
{
Child (int a, int b): Parent { a }, b { b } {}
int b;
};
std::ostream &operator<< (std::ostream& os, const Child & p)
{ os << "Child {a=" << p.a << ", b=" << p.b << "}"; return os; }
template <typename T>
void print (const gdb::array_view<const T> &p)
{
std::for_each (p.begin (), p.end (), [](const T &p) { std::cout << p << '\n'; });
}
Then with the current interface nothinng prevents this usage of
array_view to be done:
const std::array<Child, 3> elts = {
Child {1, 2},
Child {3, 4},
Child {5, 6}
};
print_all<Parent> (elts);
This compiles fine and produces the following output:
Parent {a=1}
Parent {a=2}
Parent {a=3}
which is obviously wrong. There is nowhere in memory a Parent-like
object for which the A member is 2 and this call to print_all<Parent>
shold not compile at all (calling print_all<Child> is however fine).
This comes down to the fact that a Child* is convertible into a Parent*,
and that an array view is constructed to a pointer to the first element
and a size. The valid type pointed to that can be used with this
constructor are restricted using SFINAE, which requires that a
pointer to a member into the underlying container can be converted into a
pointer the array_view's data type.
This patch proposes to change the constraints on the gdb::array_view
ctor which accepts a container now requires that the (decayed) type of
the elements in the container match the (decayed) type of the array_view
being constructed.
Applying this change required minimum adjustment in GDB codebase, which
are also included in this patch.
Tested by rebuilding.
|
|
This commits adds const versions for the GET and AS_ARRAX_VIEW methods
of gdb_argv. Those methods will be required in the following patch of
the series.
|
|
Change-Id: I04403bd85ec3fa75ea14130d68daba675a2a8aeb
|
|
non-stop
When doing "continue -a" in non-stop mode, each thread is individually
resumed while the commit resumed state is enabled. This forces the
target to commit each resumption immediately, instead of being able to
batch things.
The reason is that there is no scoped_disable_commit_resumed around the
loop over threads in continue_1, when "non_stop && all_threads" is true.
Since the proceed function is called once for each thread, the
scoped_disable_commit_resumed in proceed therefore forces commit-resumed
between each thread resumption. Add the necessary
scoped_disable_commit_resumed in continue_1 to avoid that.
I looked at the MI side of things, the function exec_continue, and found
that it was correct. There is a similar iteration over threads, and
there is a scoped_disable_commit_resumed at the function scope. This is
not wrong, but a bit more than we need. The branches that just call
continue_1 do not need it, as continue_1 takes care of disabling commit
resumed. So, move the scoped_disable_commit_resumed to the inner scope
where we iterate on threads and proceed them individually.
Here's an example debugging a multi-threaded program attached by
gdbserver (debug output trimmed for brevity):
$ ./gdb -nx -q --data-directory=data-directory -ex "set non-stop" -ex "tar rem :1234"
(gdb) set debug remote
(gdb) set debug infrun
(gdb) c -a
Continuing.
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[remote] Sending packet: $vCont;c:p14388.14388#90
[infrun] reset: reason=proceeding
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[infrun] proceed: exit
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[remote] Sending packet: $vCont;c:p14388.1438a#b9
[infrun] reset: reason=proceeding
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[infrun] proceed: exit
... and so on for each thread ...
Notice how we send one vCont;c for each thread. With the patch applied, we
send a single vCont;c at the end:
[infrun] scoped_disable_commit_resumed: reason=continue all threads in non-stop
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[infrun] reset: reason=proceeding
[infrun] proceed: exit
[infrun] clear_proceed_status_thread: Thread 85790.85792
[infrun] proceed: enter
[infrun] scoped_disable_commit_resumed: reason=proceeding
[infrun] reset: reason=proceeding
[infrun] proceed: exit
... proceeding threads individually ...
[infrun] reset: reason=continue all threads in non-stop
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[remote] Sending packet: $vCont;c#a8
Change-Id: I331dd2473c5aa5114f89854196fed2a8fdd122bb
|
|
While reading another patch, I saw that this function didn't need to
take a dwarf2_per_objfile, but could take a dwarf2_per_bfd instead.
It doesn't change the behavior, but doing this shows that this function
is objfile-independent (can work with only the shared per-bfd data).
Change-Id: I58f9c9cef6688902e95226480285da2d0005d77f
|
|
I don't find that the bpstat typedef, which hides a pointer, is
particularly useful. In fact, it confused me many times, and I just see
it as something to remember that adds cognitive load. Also, with C++,
we might want to be able to pass bpstats objects by const-reference, not
necessarily by pointer.
So, remove the bpstat typedef and rename struct bpstats to bpstat (since
it represents one bpstat, it makes sense that it is singular).
Change-Id: I52e763b6e54ee666a9e045785f686d37b4f5f849
|
|
It's been a long time since most of this was written: it's long past
time to put it in the binutils source tree. It's believed correct and
complete insofar as it goes: it documents format v3 (the current
version) but not the libctf API or any earlier versions. (The
earlier versions can be read by libctf but not generated by it, and you
are highly unlikely ever to see an example of any of them.)
libctf/ChangeLog
2021-11-08 Nick Alcock <nick.alcock@oracle.com>
* doc/ctf-spec.texi: New file.
* configure.ac (MAKEINFO): Add.
(BUILD_INFO): Likewise.
(AC_CONFIG_FILES) [doc/Makefile]: Add.
* Makefile.am [BUILD_INFO] (SUBDIRS): Add doc/.
* doc/Makefile.am: New file.
* doc/Makefile.in: Likewise.
* configure: Regenerated.
* Makefile.in: Likewise.
|
|
|
|
Goes with commit 68bbb9f788d0
* ld.texi (Input Section Wildcards): Delete paragraph incorrectly
saying '*' does not match '/'.
|
|
On LLP64 targets where sizeof(long) != sizeof(void*), this code fails:
sim/sh/interp.c:704:24: error: cast from pointer to integer of different size -Werror=pointer-to-int-cast]
704 | do { memstalls += ((((long) PC & 3) != 0) ? (n) : ((n) - 1)); } while (0)
| ^
Since this code simply needs to check alignment, cast it using uintptr_t
which is the right type for this.
|
|
Casting 0 to a pointer via (long *) doesn't work on LLP64 targets:
error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
It's also unnecessary here. We can simply pass NULL like every other
bit of code does.
|
|
Some _WIN32 targets provide utime (like mingw), so move the header
include out from _WIN32 and under the specific HAVE_UTIME_H check.
|
|
This isn't needed on any reasonable target nowadays, and no other
source does this, and breaks with some mingw targets, so punt the
extern entirely.
|
|
The code assumes that all _WIN32 targets are the same and can
define isnan to _isnan. For mingw targets, they provide an isnan
define already, so no need for the fallback here.
|
|
Some targets (like cygwin) will export page size defines that clash
with our local usage here. Undefine the system one to fix building
for these targets.
|
|
Drop our compat code and assume environ exists to simplify.
We did this for all other targets already, but ppc was missed.
|
|
With most of the warnings fixed in interp.c, we can enable -Werror
here too now. There are some -Wmaybe-uninitialized warnings still
lurking that look legitimate, but we don't flag those are fatal,
and I don't have the expertise to dive into each opcode to figure
out the right way to clean them up.
|
|
This block of code relies on i to control which bits to test and how
many times to run through the loop, but it never actually initialized
it. There is another chunk of code that handles the pdmsb instruction
that sets i to 16, so use that here too assuming it's correct. The
programming manual suggests this is the right value too, but I am by
no means a SuperH DSP expert. The tests are still passing though ...
|
|
|
|
Add parentheses to a bunch of places where the compiler suggests we
do to avoid confusion to most readers.
|
|
These macro expansions are deliberate in not using the computed value
so that they trigger side-effects (possible invalid memory accesses)
but while otherwise being noops. Add a (void) cast so the compiler
knows these are intentional.
|
|
Now that we require C11, we can leverage anonymous unions & structs
to fix a long standing issue with the SH register layout. The use
of sregs.i for sh-dsp has generated a lot of compiler warnings about
the access being out of bounds -- it only has 7 elements declared,
but code goes beyond that to reach into the fregs that follow. But
now that we have anonymous unions, we can reduce the nested names
and have sregs cover all of these registers.
|
|
|
|
Since the first argument type is unsigned32 or unsigned64, just use
sim_fpu_to{32,64}u instead of sim_fpu_to{32,64}i to fix the following
build warnings:
CC cp1.o
.../sim/mips/cp1.c: In function 'convert':
.../sim/mips/cp1.c:1425:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
status |= sim_fpu_to32i (&result32, &wop, round);
^~~~~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
^~~~~~~~~~~~~
.../sim/mips/cp1.c:1429:32: warning: pointer targets in passing argument 1 of 'sim_fpu_to64i' differ in signedness [-Wpointer-sign]
status |= sim_fpu_to64i (&result64, &wop, round);
^~~~~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:274:22: note: expected 'signed64 *' {aka 'long int *'} but argument is of type 'unsigned64 *' {aka 'long unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to64i (signed64 *i, const sim_fpu *f,
^~~~~~~~~~~~~
.../sim/mips/cp1.c: In function 'convert_ps':
.../sim/mips/cp1.c:1528:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
status_u |= sim_fpu_to32i (&res_u, &wop_u, round);
^~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
^~~~~~~~~~~~~
.../sim/mips/cp1.c:1529:34: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
status_l |= sim_fpu_to32i (&res_l, &wop_l, round);
^~~~~~
In file included from .../sim/mips/sim-main.h:67,
from .../sim/mips/cp1.c:46:
.../sim/mips/../common/sim-fpu.h:270:22: note: expected 'signed32 *' {aka 'int *'} but argument is of type 'unsigned32 *' {aka 'unsigned int *'}
INLINE_SIM_FPU (int) sim_fpu_to32i (signed32 *i, const sim_fpu *f,
^~~~~~~~~~~~~
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
Newer versions of bison emit a prototype for yyerror
void yyerror (const char *);
This clashes with some of our old code that declares yyerror to return
an int. Fix that in most cases by modernizing yyerror. bfin-parse.y
uses the return value all over the place, so for there disable
generation of the prototype as specified by posix.
binutils/
* arparse.y (yyerror): Return void.
* dlltool.c (yyerror): Likewise.
* dlltool.h (yyerror): Likewise.
* sysinfo.y (yyerror): Likewise.
* windmc.h (yyerror): Likewise.
* mclex.c (mc_error): Extract from ..
(yyerror): ..here, both now returning void.
gas/
* config/bfin-parse.y (yyerror): Define.
(yyerror): Make static.
* itbl-parse.y (yyerror): Return void.
ld/
* deffilep.y (def_error): Return void.
|
|
This one was logically wrong too. If file_ptr was 64 bits, then -1U
is extended to 0x00000000ffffffff, probably not what was intended
here.
* mach-o.c (FILE_ALIGN): Correct expression.
|
|
readelf -r dumping support is not added in this patch.
include/
* elf/common.h: Add SHT_RELR, DT_RELR{,SZ,ENT}
bfd/
* elf.c (_bfd_elf_print_private_bfd_data): Add DT_RELR{,SZ,ENT}.
binutils/
* readelf.c (get_dynamic_type): Add DT_RELR{,SZ,ENT}.
(get_section_type_name): Add SHT_RELR.
|
|
The output now looks like:
- 0x0000000000000021 (PREINIT_ARRAYSZ) 0x10
+ 0x0000000000000021 (PREINIT_ARRAYSZ) 16 (bytes)
0x0000000000000019 (INIT_ARRAY) 0xbefc90
0x000000000000001b (INIT_ARRAYSZ) 536 (bytes)
* readelf.c (process_dynamic_section): Handle DT_PREINIT_ARRAYSZ.
|
|
The project has been using GPL v3 for a while now in the source files,
and the arm & ppc ports have carried a copy of the COPYING file. Lets
move those up to the top sim dir like other projects to make it clear.
Also drop the ppc/COPYING.LIB as it's not really referenced by any
source as everything is GPL v3.
|
|
|
|
This adds a new make_unique_xstrndup function, which is the "n"
analogue of make_unique_xstrdup. It also updates a couple existing
places to use this function.
|
|
PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent
failure) shows that GDB can hit an unexpected scenario -- it can
happen that the kernel manages to open a /proc/PID/task/LWP/mem file,
but then reading from the file returns 0/EOF, even though the process
hasn't exited or execed.
"0" out of read/write is normally what you get when the address space
of the process the file was open for is gone, because the process
execed or exited. So when GDB gets the 0, it returns memory access
failure. In the bad case in question, the process hasn't execed or
exited, so GDB fails a memory access when the access should have
worked.
GDB has code in place to gracefully handle the case of opening the
/proc/PID/task/LWP/mem just while the LWP is exiting -- most often the
open fails with EACCES or ENOENT. When it happens, GDB just tries
opening the file for a different thread of the process. The testcase
is written such that it stresses GDB's logic of closing/reopening the
/proc/PID/task/LWP/mem file, by constantly spawning short lived
threads.
However, there's a window where the kernel manages to find the thread,
but the thread exits just after and clears its address space pointer.
In this case, the kernel creates a file successfully, but the file
ends up with no address space associated, so a subsequent read/write
returns 0/EOF too, just like if the whole process had execed or
exited. This is the case in question that GDB does not handle.
Oleg Nesterov gave this suggestion as workaround for that race:
gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm.
If statm reports something non-zero, then open() was "successfull".
I think that might work. However, I didn't try it, because I realized
we have another nasty race that that wouldn't fix.
The other race I realized is that because we close/reopen the
/proc/PID/task/LWP/mem file when GDB switches to a different inferior,
then it can happen that GDB reopens /proc/PID/task/LWP/mem just after
a thread execs, and before GDB has seen the corresponding exec event.
I.e., we can open a /proc/PID/task/LWP/mem file accessing the
post-exec address space thinking we're accessing the pre-exec address
space.
A few months back, Simon, Oleg and I discussed a similar race:
[Bug gdb/26754] Race condition when resuming threads and one does an exec
https://sourceware.org/bugzilla/show_bug.cgi?id=26754
The solution back then was to make the kernel fail any ptrace
operation until the exec event is consumed, with this kernel commit:
commit dbb5afad100a828c97e012c6106566d99f041db6
Author: Oleg Nesterov <oleg@redhat.com>
AuthorDate: Wed May 12 15:33:08 2021 +0200
Commit: Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Wed May 12 10:45:22 2021 -0700
ptrace: make ptrace() fail if the tracee changed its pid unexpectedly
This however, only applies to ptrace, not to the /proc/pid/mem file
opening case. Also, even if it did apply to the file open case, we
would want to support current kernels until such a fix is more wide
spread anyhow.
So all in all, this commit gives up on the idea of only ever keeping
one /proc/pid/mem file descriptor open. Instead, make GDB open a
/proc/pid/mem per inferior, and keep it open until the inferior exits,
is detached or execs. Make GDB open the file right after the inferior
is created or is attached to or forks, at which point we know the
inferior is stable and stopped and isn't thus going to exec, or have a
thread exit, and so the file open won't fail (unless the whole process
is SIGKILLed from outside GDB, at which point it doesn't matter
whether we open the file).
This way, we avoid both races described above, at the expense of using
more file descriptors (one per inferior).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065
Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419
|
|
Replaces a hard coded line number with a use of gdb_get_line_number.
I suspect that the line number has, over time, come adrift from where
it was supposed to be stopping. When the test was first added, line
770 pointed at the final 'return 0' in function main. Over time, as
things have been added, line 770 now points at some random location in
the middle of main.
So, I've marked the 'return 0' with a comment, and now the test will
always stop there.
I also removed an old comment from 1997 talking about how these tests
will only pass with the HP compiler, followed by an additional comment
from 2000 saying that the tests now pass with GCC.
I get the same results before and after this change.
|
|
Calculating "0 - pointer" can indeed result in seeming randomness as
the pointer address varies.
PR 28541
* dwarf.c (display_debug_frames): Don't print cie offset when
invalid, print "invalid" instead. Remove now redundant warning.
|
|
* aarch64-dis.c (extract_fields): Invoke va_end.
|
|
Investigating the PR28530 testcase, which has a fuzzed compression
header with an enormous size, I noticed that decompress_contents is
broken when the size doesn't fit in strm.avail_out. It wouldn't be
too hard to support larger sizes (patches welcome!) but for now just
stop decompress_contents from returning rubbish.
PR 28530
* compress.c (decompress_contents): Fail when uncompressed_size
is too big.
(bfd_init_section_decompress_status): Likewise.
|
|
* vms-alpha.c (evax_bfd_print_desc): Sanity check buffer access.
(evax_bfd_print_valspec, evax_bfd_print_typspec): Likewise.
(evax_bfd_print_dst): Likewise.
|
|
|
|
The "set index-cache" command is used at the same time as a prefix
command (prefix for "set index-cache directory", for example), and a
boolean setting for turning the index-cache on and off. Even though I
did introduce that, I now don't think it's a good idea to do something
non-standard like this.
First, there's no dedicated CLI command to show whether the index-cache
is enabled, so it has to be custom output in the "show index-cache
handler". Also, it means there's no good way a MI frontend can find out
if the index-cache is enabled. "-gdb-show index-cache" doesn't show it
in the MI output record:
(gdb) interpreter-exec mi "-gdb-show index-cache"
~"\n"
~"The index cache is currently disabled.\n"
^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}
Fix this by introducing "set/show index-cache enabled on/off", regular
boolean setting commands. Keep commands "set index-cache on" and "set
index-cache off" as deprecated aliases of "set index-cache enabled",
with respectively the default arguments "on" and "off".
Update tests using "set index-cache on/off" to use the new command.
Update the regexps in gdb.base/maint.exp to figure out whether the
index-cache is enabled or not. Update the doc to mention the new
commands.
Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3
|
|
The getter and setter in struct setting always receive and return values
by const reference. This is not necessary for scalar values (like bool
and int), but more importantly it makes it a bit annoying to write a
getter, you have to use a scratch static variable or something similar
that you can refer to:
const bool &
my_getter ()
{
static bool value;
value = function_returning_bool ();
return value;
}
Change the getter and setter function signatures to receive and return
value by value instead of by reference, when the underlying data type is
scalar. This means that string-based settings will still use
references, but all others will be by value. The getter above would
then be re-written as:
bool
my_getter ()
{
return function_returning_bool ();
}
This is useful for a patch later in this series that defines a boolean
setting with a getter and a setter.
Change-Id: Ieca3a2419fcdb75a6f75948b2c920b548a0af0fd
|
|
The class_deprecated enumerator isn't assigned anywhere, so remove it.
Commands that are deprecated have cmd_list_element::cmd_deprecated set
instead.
Change-Id: Ib35e540915c52aa65f13bfe9b8e4e22e6007903c
|
|
Remove two unnecessary nullptr checks. If aliases is nullptr, then the
for loops will simply be skipped.
Change-Id: I9132063bb17798391f8d019af305383fa8e0229f
|
|
I get some diffs when running autoconf in gdbserver, probably leftovers
from commit 5dfe4bfcb969 ("Fix format_pieces selftest on Windows").
Re-generate configure in that directory.
Change-Id: Icdc9906af95fbaf1047a579914b2983f8ec5db08
|
|
This reverts commit e0f7ea91436dd308a094c4c101fd4169e8245a91.
|
|
Always check sections with the corrupt size for non-MMO files. Skip MMO
files for compress_status == COMPRESS_SECTION_NONE since MMO has special
handling for COMPRESS_SECTION_NONE.
PR binutils/28530
* compress.c (bfd_get_full_section_contents): Always check
sections with the corrupt size.
|
|
Add/Remove the rvc extension to/from the riscv_subsets once the
.option rvc/norvc is set. So that we don't need to always check
the riscv_opts.rvc in the riscv_subset_supports, just call the
riscv_lookup_subset to search the subset list is enough.
Besides, we will need to dump the instructions according to the
elf architecture attributes. That means the dis-assembler needs
to parse the architecture string from the elf attribute before
dumping any instructions, and also needs to recognized the
INSN_CLASS* classes from riscv_opcodes. Therefore, I suppose
some functions will need to be moved from gas/config/tc-riscv.c
to bfd/elfxx-riscv.c, including riscv_multi_subset_supports and
riscv_subset_supports. This is one of the reasons why we need
this patch.
This patch passes the gcc/binutils regressions of rv32emc-elf,
rv32i-elf, rv64gc-elf and rv64gc-linux toolchains.
bfd/
* elfxx-riscv.c (riscv_remove_subset): Remove the extension
from the subset list.
(riscv_update_subset): Add/Remove an extension to/from the
subset list. This is used for the .option rvc or norvc.
* elfxx-riscv.h: Added the extern bool riscv_update_subset.
gas/
* config/tc-riscv.c (riscv_set_options): Removed the unused
rve flag.
(riscv_opts): Likewise.
(riscv_set_rve): Removed.
(riscv_subset_supports): Removed the riscv_opts.rvc check.
(riscv_set_arch): Don't need to call riscv_set_rve.
(reg_lookup_internal): Call riscv_subset_supports to check
whether the rve is supported.
(s_riscv_option): Add/Remove the rvc extension to/from the
subset list once the .option rvc/norvc is set.
|
|
The multi-run logic for mips involves a bit of codegen and rewriting
of files to include per-architecture prefixes. That can result in
files with missing prototypes which cause compiler errors. In the
case of mips-sde-elf targets, we have:
$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
sim_engine_run -> m16mips64r2_engine_run
$srcdir/micromipsrun.c -> micromipsmicromips_run.c
sim_engine_run -> micromips64micromips_engine_run
micromipsmicromips_run.c:80:1: error: no previous prototype for 'micromips64micromips_engine_run' [-Werror=missing-prototypes]
80 | micromips64micromips_engine_run (SIM_DESC sd, int next_cpu_nr, int nr_cpus,
We generate headers for those prototypes in the configure script,
but only include them in the generated multi-run.c file. Update the
rewrite logic to turn the sim-engine.h include into the relevant
generated engine include so these files also have their prototypes.
$srcdir/m16run.c -> $builddir/m16mips64r2_run.c
sim-engine.h -> m16mips64r2_engine.h
$srcdir/micromipsrun.c -> micromipsmicromips_run.c
sim-engine.h -> micromips64micromips_engine.h
|
|
PR 28540
* objdump.c (dump_bfd): Don't attempt load_separate_debug_files
when byte_get is NULL.
|
|
|
|
We will never bother building w/out a ../common/ sim directory,
so drop ancient logic supporting that method.
|
