Mike Frysinger [Sun, 1 Jan 2023 15:07:28 +0000 (10:07 -0500)]
sim: replace -I$srcroot/bfd include with -I$srcroot
Clean up includes a bit by making ports include bfd/ headers
explicitly. This matches other projects, and makes it more clear
where these headers are coming from.
Mike Frysinger [Sun, 1 Jan 2023 14:55:07 +0000 (09:55 -0500)]
sim: replace -I$srcroot/opcodes include with -I$srcroot
Clean up includes a bit by making ports include opcodes/ headers
explicitly. This matches other projects, and makes it more clear
where these headers are coming from.
Alan Modra [Fri, 23 Dec 2022 07:13:21 +0000 (17:43 +1030)]
obsolete target tidy
Delete a few files only used for obsolete targets, and tidy config,
xfails and other pieces of support specific to those targets. And
since I was editing target triplets in test files, fix the nm
alpha-linuxecoff fails.
Mike Frysinger [Sun, 1 Jan 2023 19:05:57 +0000 (14:05 -0500)]
sim: iq2000: drop unused cpu define logic
These defines seem to have been added in anticipation of adding another
cpu port (IQ10BF?), but that was over 20 years ago, and that port has
yet to materialize. So drop these compile flags since they don't do
anything to the generated code. If another port ever shows up, it's
easy enough to readd things as needed.
... by hand as instructed by the gdb/copyright.py script.
The update by hand is needed because the copyright headers
to update are actually nested inside those files, rather
than located at the start of the file.
Joel Brobecker [Sun, 1 Jan 2023 12:49:04 +0000 (16:49 +0400)]
Update copyright year range in header of all files managed by GDB
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
Joel Brobecker [Sun, 1 Jan 2023 12:47:26 +0000 (16:47 +0400)]
gdb/copyright.py: Adjust following rename of sim/ppc/ppc-instructions...
... to sim/ppc/powerpc.igen
This file is in the NOT_FSF_LIST because this file has a copyright
which is not assigned to the FSF. Since the file got renamed,
the corresponding entry in NOT_FSF_LIST needs to be renamed as well.
Joel Brobecker [Sun, 1 Jan 2023 12:43:39 +0000 (16:43 +0400)]
Update copyright year in help message of gdb, gdbserver, gdbreplay
This commit updates the copyright year displayed by gdb, gdbserver
and gdbreplay's help message from 2022 to 2023, as per our Start
of New Year procedure. The corresponding source files' copyright
header are also updated accordingly.
Alan Modra [Sun, 1 Jan 2023 12:31:20 +0000 (23:01 +1030)]
Update year range in gprofng copyright notices
This adds 'Innovative Computing Labs' as an external author to
update-copyright.py, to cover the copyright notice in
gprofng/common/opteron_pcbe.c, and uses that plus another external
author 'Oracle and' to update gprofng copyright dates. I'm not going
to commit 'Oracle and' as an accepted author, but that covers the
string "Copyright (c) 2006, 2012, Oracle and/or its affiliates. All
rights reserved." found in gprofng/testsuite/gprofng.display/jsynprog
files.
Alan Modra [Sun, 1 Jan 2023 06:08:42 +0000 (16:38 +1030)]
Update year range in copyright notice of binutils files
The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
Alan Modra [Sun, 1 Jan 2023 06:03:14 +0000 (16:33 +1030)]
Update etc/update-copyright.py
This picks up some improvements from gcc/contrib. exceptions must
derive from BaseException, port to python3, retain original file mode,
fix name of script in examples.
Adds libsframe to list of default dirs. I would have added gprofng
too but there are some files claiming copyright by authors other than
the Free Software Foundation.
Tom de Vries [Sat, 31 Dec 2022 09:23:06 +0000 (10:23 +0100)]
[gdb/cli] Add maintenance ignore-probes
There's a command "disable probes", but SystemTap probes, for instance
libc:longjmp cannot be disabled:
...
$ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$"
...
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
...
Add a command "maintenance ignore-probes" that ignores probes during
get_probes, such that we can easily pretend to use a libc without the
libc:longjmp probe:
...
(gdb) maint ignore-probes -verbose libc ^longjmp$
ignore-probes filter has been set to:
PROVIDER: 'libc'
PROBE_NAME: '^longjmp$'
OBJNAME: ''
(gdb) start ^M
...
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
...
The "Ignoring ..." messages can be suppressed by not using -verbose.
Note that as with "disable probes", running simply "maint ignore-probes"
ignores all probes.
The ignore-probes filter can be reset by using:
...
(gdb) maint ignore-probes -reset
ignore-probes filter has been reset
...
For now, the command is only supported for SystemTap probes.
Mark Harmstone [Mon, 26 Dec 2022 20:47:49 +0000 (20:47 +0000)]
ld: Handle extended-length data structures in PDB types
A few fixes to minor issues I've discovered in my PDB patches.
* If sizes or offsets are greater than 0x8000, they get encoded as
extended values in the same way as for enum values - e.g. a LF_ULONG
.short followed by a .long.
* I've managed to coax MSVC to produce another type, LF_VFTABLE, which
is seen when dealing with COM. I don't think LLVM emits this. Note that
we can't just implement everything in Microsoft's header files, as most
of it is obsolete.
* Fixes a stupid bug in the test program, where I was adding an index to
a size. The index was hard-coded to 0, so this didn't cause any actual
issues.
Tom de Vries [Sat, 31 Dec 2022 07:51:40 +0000 (08:51 +0100)]
[gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32
[ Partial resubmission of an earlier submission by Andrew (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
listing him as co-author. ]
With x86_64-linux and target board unix/-m32, we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
The following scenario happens:
- set breakpoint in throw_exception_1, a function that throws an exception
- continue
- hit breakpoint, with call stack main.c:38 -> throw_exception_1
- set a finish breakpoint
- continue
- hit the breakpoint again, with call stack main.c:48 -> throw_exception
-> throw_exception_1
Due to the exception, the function call did not properly terminate, and the
finish breakpoint didn't trigger. This is expected behaviour.
However, the intention is that gdb detects this situation at the next stop
and calls the out_of_scope callback, which would result here in this test-case
in a rather confusing "exception did not finish" message. So the problem is
that this message doesn't show up, in other words, the out_of_scope callback
is not called.
[ Note that the fact that the situation is detected only at the next stop
(wherever that happens to be) could be improved upon, and the earlier
submission did that by setting a longjmp breakpoint. But I'm considering this
problem out-of-scope for this patch. ]
Note that the message does show up later, at thread exit:
...
[Inferior 1 (process 20046) exited with code 0236]^M
exception did not finish ...^M
...
The decision on whether to call the out_of_scope call back is taken in
bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
...
if (b->pspace == current_inferior ()->pspace
&& (!target_has_registers ()
|| frame_find_by_id (b->frame_id) == NULL))
bpfinishpy_out_of_scope (finish_bp);
...
In the case of the thread exit, the callback triggers because
target_has_registers () == 0.
So why doesn't the callback trigger in the case of the breakpoint?
Well, the b->frame_id is the frame_id of the frame of main (the frame
in which the finish breakpoint is supposed to trigger), so AFAIU
frame_find_by_id (b->frame_id) == NULL will only be true once we've
left main, at which point I guess we don't stop till thread exit.
Fix this by saving the frame in which the finish breakpoint was created, and
using frame_find_by_id () == NULL on that frame instead, such that we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23 throw new int (e);^M
exception did not finish ...^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
Still, the test-case is failing because it's setup to match the behaviour that
we get on x86_64-linux with target board unix/-m64:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
stopped at ExceptionFinishBreakpoint^M
(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
check FinishBreakpoint in catch()
...
So what happens here? Again, due to the exception, the function call did not
properly terminate, but the finish breakpoint still triggers. This is somewhat
unexpected. This happens because it just so happens to be that the frame
return address at which the breakpoint is set, is also the first instruction
after the exception has been handled. This is a know problem, filed as
PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
callback.
Also add a breakpoint after setting the finish breakpoint but before throwing
the exception, to check that we don't call the out_of_scope callback too early.
Tested on x86_64-linux, with target boards unix/-m32.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
PR python/27247
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247
Tom de Vries [Sat, 31 Dec 2022 06:35:56 +0000 (07:35 +0100)]
[gdb/testsuite] Fix gdb.base/print-symbol-loading.exp on ubuntu 22.04.1
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
set print symbol-loading off
sharedlibrary .*^M
Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
(gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
...
The test-case expects the libc.so line, but not the libpthread.so line.
However, we have:
...
$ ldd /lib/x86_64-linux-gnu/libc.so.6
linux-vdso.so.1 (0x00007ffd7f7e7000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
...
so it's not unexpected that libpthread.so is loaded if libc.so is loaded.
Tom de Vries [Sat, 31 Dec 2022 06:31:17 +0000 (07:31 +0100)]
[gdb/testsuite] Replace deprecated pthread_yield in gdb.threads/watchpoint-fork.exp
On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
...
watchpoint-fork-mt.c: In function 'start':^M
watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
pthread_yield is deprecated, use sched_yield instead \
[-Wdeprecated-declarations]^M
67 | i = pthread_yield ();^M
| ^^M
...
Fix this as suggested, by using sched_yield instead.
Tom de Vries [Sat, 31 Dec 2022 06:26:53 +0000 (07:26 +0100)]
[gdb/testsuite] Fix gdb.base/corefile.exp with glibc 2.35
On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
...
(gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
bt^M
#0 __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
#2 __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
#3 0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
#4 0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
#5 0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
#6 0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
#7 0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
(gdb) PASS: gdb.base/corefile.exp: backtrace
up^M
#1 __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
78 in ./nptl/pthread_kill.c^M
(gdb) FAIL: gdb.base/corefile.exp: up
...
The problem is that the regexp used here:
...
gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
...
does not fit the __pthread_kill_internal line which lacks the instruction
address due to inlining.
Tom de Vries [Fri, 30 Dec 2022 15:53:51 +0000 (16:53 +0100)]
[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc
On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) info probes all rtld rtld_map_complete^M
No probes matched.^M
(gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
...
This has been filed as PR testsuite/17016.
The problem is that the name rtld_map_complete is used, which was only
available in Fedora 17, and upstream the name map_complete was used.
In the email thread discussing a proposed patch (
https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
suggested to make the test-case handle both names.
So, handle both names: map_complete and rtld_map_complete.
This exposes the following FAIL:
...
(gdb) info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
$hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M
$hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
...
due to using a glibc (v2.35) that has libpthread integrated into libc.
Tom de Vries [Fri, 30 Dec 2022 15:48:07 +0000 (16:48 +0100)]
[gdb/testsuite] Fix gdb.reverse/step-indirect-call-thunk.exp with -fcf-protection
On Ubuntu 22.04.1 x86_64, I run into:
...
gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
'-fcf-protection' are not compatible^M
22 | { /* inc.1 */^M
| ^^M
...
Fix this by forcing -fcf-protection=none, if supported.
Tom de Vries [Fri, 30 Dec 2022 13:00:39 +0000 (14:00 +0100)]
[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with -fcf-protection
On Ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
next^M
51 if (t != NULL^M
(gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
...
This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
... 0000000000001180 <_Z13get_alias_setP4tree>:
1180: f3 0f 1e fa endbr64
1184: 48 85 ff test %rdi,%rdi
...
so the extra insn gets an is-stmt line number entry:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001180 Y
12 50 0x0000000000001180
13 51 0x0000000000001184 Y
14 54 0x0000000000001184
...
and when stepping into get_alias_set we step to line 50:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
50 {^M
...
In contrast, with -fcf-protection=none, we get:
... 0000000000001170 <_Z13get_alias_setP4tree>:
1170: 48 85 ff test %rdi,%rdi
...
and:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
...
11 50 0x0000000000001170 Y
12 51 0x0000000000001170 Y
13 54 0x0000000000001170
...
so when stepping into get_alias_set we step to line 51:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
51 if (t != NULL^M
...
Fix this by rewriting the gdb_test issuing the step command to check which
line the step lands on, and issuing an extra next if needed.
Tested on x86_64-linux, both with and without -fcf-protection=none.
Alan Modra [Fri, 30 Dec 2022 01:11:16 +0000 (11:41 +1030)]
PR29948, heap-buffer-overflow in display_debug_lines_decoded
This fixes a couple of places in display_debug_lines_decoded that were
off by one in checking DWARF5 .debug_line directory indices. It also
displays the DWARF5 entry 0 for the program current directory rather
than "." as is done for pre-DWARF5. I decided against displaying
DW_AT_comp_dir for pre-DWARF5 since I figure it is better for readelf
to minimally interpret debug info.
binutils/
PR 29948
* dwarf.c (display_debug_lines_decoded): Display the given
directory entry 0 for DWARF5. Properly check directory index
against number of entries in the table. Revert to using
unsigned int for n_directories and associated variables.
Correct warning messages.
gas/
* testsuite/gas/elf/dwarf-5-loc0.d: Update.
Tom Tromey [Tue, 27 Dec 2022 23:34:44 +0000 (16:34 -0700)]
Fix "set debug timestamp"
PR cli/29945 points out that "set debug timestamp 1" stopped working
-- this is a regression due to commit b8043d27 ("Remove a ui-related
memory leak").
This patch fixes the bug and adds a regression test.
I think this should probably be backported to the gdb 13 branch.
Tom Tromey [Thu, 15 Dec 2022 21:12:05 +0000 (14:12 -0700)]
Handle SIGSEGV in gdb selftests
The gdb.gdb self-tests were timing out for me, which turned out to be
PR testsuite/29325. Looking into it, the problem is that the version
of the Boehm GC that is used by Guile on my machine causes a SEGV
during stack probing. This unexpected stop confuses the tests and
causes repeated timeouts.
This patch adapts the two failing tests. This makes them work for me,
and reduces the running time of gdb.gdb from 20 minutes to about 11
seconds.
Mike Frysinger [Sun, 25 Dec 2022 07:37:10 +0000 (02:37 -0500)]
sim: mips: rename "igen" generation mode to "single"
The naming in here has grown organically and is confusing to follow.
Originally there was only one set of rules for generating code from
the igen sources, so calling it "tmp-igen" and such made sense. But
when other multigen modes were added ("m16" & "multi") which also
used igen, it's not clear what's common igen and what's specific to
this generation mode. So rename the set of rules from "igen" to
"single" so it's easier to follow.
Mike Frysinger [Sun, 25 Dec 2022 06:48:01 +0000 (01:48 -0500)]
sim: mips: unify itable generation (a bit)
The m16 & multi targets generate itable once even when all the other
modules are generated multiple times. The default igen target will
generate itable with everything else out of convenience. This means
flags are passed which don't affect the generated itable there.
We can unify the itable generation by making sure the right -F/-M
filter variables are passed down. Since there's already a dedicated
rule & variable in the multi build mode, generalize that and switch
the m16 & igen builds over too.
I spent a lot of time staring at this code, building for diff mips
targets, and exploring all the shell code paths. I think this is
safe, but only time (and users) will really tell.
Mike Frysinger [Sun, 25 Dec 2022 06:44:27 +0000 (01:44 -0500)]
sim: mips: rename multi_flags to igen_itable_flags
This variable is only used to generate the itable files. In preparation
for merging the itable logic among all ports, rename "multi_flags" to a
more appropriate "igen_itable_flags" variable. There should be no real
chagnes here otherwise.
Mike Frysinger [Sun, 25 Dec 2022 06:23:21 +0000 (01:23 -0500)]
sim: mips: drop unused micromips igen logic
This code appears to be unused since it was first merged. When
micromips was enabled, it was via the "MULTI" config, not the
"MICROMIPS" config, and the multi configs have sep vars. Since
nothing sets SIM_MIPS_GEN=MICROMIPS in the config, all of this
should be unreachable, so punt it to simplify. Further, the
SIM_MIPS_MICROMIPS16_FLAGS & SIM_MIPS_MICROMIPS_FLAGS settings
rely on sim_mips_micromips{,16}_{filter,machine} variables that
are never set in the configure script.
Tom Tromey [Sat, 16 Jul 2022 01:05:29 +0000 (19:05 -0600)]
Add initializers to comp_unit_head
PR symtab/29343 points out that it would be beneficial if
comp_unit_head had a constructor and used initializers. This patch
implements this. I'm unsure if this is sufficient to close the bug,
but at least it's a step.
Alan Modra [Fri, 23 Dec 2022 12:52:32 +0000 (23:22 +1030)]
bfd/dwarf2.c: allow use of DWARF5 directory entry 0
I think the test for table->files[file].dir being non-zero is wrong
for DWARF5 where index zero is allowed and is the current directory of
the compilation. Most times this will be covered by the use of
table->comp_dir (from DW_AT_comp_dir) in concat_filename but the point
of putting the current dir in .debug_line was so the section could
stand alone without .debug_info.
Also, there is no need to check for table->dirs non-NULL, the
table->num_dirs test is sufficient.
* dwarf2.c (concat_filename): Correct and simplify tests of
directory index.
Indu Bhagat [Sun, 25 Dec 2022 08:06:22 +0000 (00:06 -0800)]
libsframe: write out SFrame FRE start address correctly
The following test was failing on ppc64 and s390x:
"FAIL: encode-1: Encode buffer match"
The offending stub was how we memcpy the FRE start address to the buffer
(on-disk format). When the host is big-endian, the address of the
source buffer for the memcpy needs to point to the uint8_t/uint16_t sized
value of the FRE start addr, not uint32_t sized value; we intend to copy
out only the fre_start_addr_sz number of bytes.
ChangeLog:
* libsframe/sframe.c (sframe_encoder_write_fre_start_addr): New
function.
(sframe_encoder_write_fre): Use it instead of memcpy.
Mike Frysinger [Sun, 25 Dec 2022 06:05:09 +0000 (01:05 -0500)]
sim: smp: plumb igen flag down to all users
While mips has respected sim_igen_smp at configure time (which was
always empty since it defaulted smp to off), no other igen port did.
Move this to a makefile variable and plumb it through the common
IGEN_RUN variable instead so everyone gets it by default. We also
clean up some redundant -N0 setting with multirun mips.
Mike Frysinger [Sun, 25 Dec 2022 05:53:25 +0000 (00:53 -0500)]
sim: cpu: change default init to handle all cpus
All the runtimes were only initializing a single CPU. When SMP is
enabled, things quickly crash as none of the other CPU structs are
setup. Change the default from 0 to the compile time value.
Mike Frysinger [Sun, 25 Dec 2022 05:32:49 +0000 (00:32 -0500)]
sim: v850: fix SMP compile
The igen tool sets up the SD & CPU defines for code fragments to use,
but v850 was expecting "sd". Change all the igen related code to use
SD so it actually compiles, and fix a few places to use "CPU" instead
of hardcoding cpu0.
Mike Frysinger [Sun, 25 Dec 2022 05:28:55 +0000 (00:28 -0500)]
sim: mn10300: fix SMP compile
The igen tool sets up the SD define for code fragments to use, but
mn10300 was expecting "sd". Change all the igen related code to use
SD so it actually compiles.
Mike Frysinger [Sun, 25 Dec 2022 04:43:18 +0000 (23:43 -0500)]
sim: cpu: fix SMP msg prefix helper
This code fails to compile when SMP is enabled due to some obvious
errors. Fix those and change the logic to avoid CPP to prevent any
future rot from creeping back in.
Mike Frysinger [Sun, 25 Dec 2022 02:28:03 +0000 (21:28 -0500)]
sim: mips: move igen settings to top-level configure
This is the last bit of logic that exists in the mips configure
script, so move it to the top-level configure to kill it off.
We still have to move the Makefile.in igen logic to local.mk,
but this is a required first step for that.
Mike Frysinger [Sun, 25 Dec 2022 00:38:44 +0000 (19:38 -0500)]
sim: mips: namespace igen configure vars
To prepare moving this logic to the top-level configure, the vars
need to be namespaced. Do that here to make it easier to review.
Basically sim_xxx -> SIM_MIPS_XXX when a var is exported from the
configure script to the Makefile, and sim_xxx -> sim_mips_xxx when
the var is internal in the configure script.
Mike Frysinger [Sun, 25 Dec 2022 02:25:50 +0000 (21:25 -0500)]
sim: mips: add igen recursive dep
Make sure the igen tool exists before trying to compile the mips
subdir. This happens to work when mips has a subconfigure, but
hits a race condition when that is removed.
Mike Frysinger [Sat, 24 Dec 2022 20:02:00 +0000 (15:02 -0500)]
sim: igen: support in-place updates ourself
Every file that igen outputs is then processed with the move-if-changed
shell script. This creates a lot of boilerplate in the build and not an
insignificant amount of build-time overhead. Move the simple "is the file
changed" logic into igen itself.
gdb/testsuite: new test for recent dwarf reader issue
A new test (gdb.base/signed-builtin-types.exp) was added that made use
of 'info sources' to figure out if the debug information for a
particular object file had been fully expanded or not. Unfortunately
some lines of the 'info sources' output can be very long, this was
observed on some systems where the debug information for the
dynamic-linker was installed, in this case, the list of source files
associated with the dynamic linker was so long it would cause expect's
internal buffer to overflow.
This commit switches from using 'info sources' to 'maint print
objfile', the output from the latter command is more compact, but
also, can be restricted to a single named object file.
With this change in place I am no longer seeing buffer overflow errors
from expect when running gdb.base/signed-builtin-types.exp.
Mike Frysinger [Sat, 24 Dec 2022 01:51:39 +0000 (20:51 -0500)]
sim: or1k: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to the existing or1k-sim.h.
Unfortunately, we can't yet drop the or1k-sim.h include from sim-main.h
as many of the generated CGEN files refer only to sim-main.h. We'll
have to improve the CGEN interface before we can make more progress,
but this is at least a minor improvement.
Indu Bhagat [Fri, 23 Dec 2022 21:04:06 +0000 (13:04 -0800)]
libsframe: fix a memory leak in sframe_decode
sframe_decode () needs to malloc a temporary buffer of the same size as
the input buffer (containing the SFrame section bytes) when endian
flipping is needed. The decoder keeps the endian flipped contents in
this buffer for its usage. This code is necessary when the target
endianneess is not the same as host endianness.
The malloc'd buffer needs to be kept track of, so that it can freed up in
sframe_decoder_free () later.
ChangeLog:
* libsframe/sframe-impl.h (struct sframe_decoder_ctx): Add new
member to keep track of the internally malloc'd buffer.
* libsframe/sframe.c (sframe_decoder_free): Free it up.
(sframe_decode): Update the reference to the buffer.
Simon Marchi [Thu, 22 Dec 2022 15:10:24 +0000 (10:10 -0500)]
gdb/testsuite: remove MPFR detection in gdb.base/float128.exp
I see this fail since commit 991180627851 ("Use toplevel configure for
GMP and MPFR for gdb"):
FAIL: gdb.base/float128.exp: show configuration
The test fails to find --with-mpfr or --without-mpfr in the "show
configuration" output. Since MPFR has become mandatory, we can just
remove that check and simplify the test to assume MPFR support is there.
Change-Id: I4f3458470db0029705b390dfefed3a66dfc0633a Approved-By: Tom de Vries <tdevries@suse.de>
Mike Frysinger [Fri, 23 Dec 2022 05:49:09 +0000 (00:49 -0500)]
sim: m32r: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to the existing m32r-sim.h.
Unfortunately, we can't yet drop the m32r-sim.h include from sim-main.h
as many of the generated CGEN files refer only to sim-main.h. We'll
have to improve the CGEN interface before we can make more progress,
but this is at least a minor improvement.
Mike Frysinger [Fri, 23 Dec 2022 05:10:35 +0000 (00:10 -0500)]
sim: bfin: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so drop the bfin.h include and move the remaining
bfin-specific settings into it.
Mike Frysinger [Fri, 23 Dec 2022 05:07:47 +0000 (00:07 -0500)]
sim: m68hc11: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 05:01:43 +0000 (00:01 -0500)]
sim: sh: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 05:00:07 +0000 (00:00 -0500)]
sim: mcore: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 04:56:19 +0000 (23:56 -0500)]
sim: h8300: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 04:52:24 +0000 (23:52 -0500)]
sim: pru: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so drop the pru.h include and move the remaining
pru-specific settings into it.
Mike Frysinger [Fri, 23 Dec 2022 04:47:50 +0000 (23:47 -0500)]
sim: mn10300: standardize the arch-specific settings a little
Rename mn10300_sim.h to mn10300-sim.h to match other ports, and move most
of the arch-specific content out of sim-main.h to it. This isn't a big
win though as we still have to include the header in sim-main.h due to the
igen interface: it hardcodes including sim-main.h in its files. So until
we can fix that, we have to keep bleeding these settings into the common
codes.
Also take the opportunity to purge a lot of unused headers from these.
The local modules should already include the right headers, so there's
no need to force everyone to pull them in. A lot of this is a hold over
from the pre-igen days of this port.
Mike Frysinger [Fri, 23 Dec 2022 04:29:21 +0000 (23:29 -0500)]
sim: microblaze: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 04:15:39 +0000 (23:15 -0500)]
sim: example-synacor: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 04:13:54 +0000 (23:13 -0500)]
sim: moxie: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
Mike Frysinger [Fri, 23 Dec 2022 04:10:38 +0000 (23:10 -0500)]
sim: riscv: move arch-specific settings to internal header
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
We can also move the machs.h include out since the model logic was all
generalized from compile-time to runtime last year.