Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Feb 15, 2021
    • Peter Maydell's avatar
      target/m68k: Drop use of gdb_get_float64() and ldfq_p() · 7ed51401
      Peter Maydell authored 
      
We used to make a distinction between 'float64'/'float32' types and
the 'uint64_t'/'uint32_t' types, requiring special conversion
operations to go between them.  We've now dropped this distinction as
unnecessary, and the 'float*' types remain primarily for
documentation purposes when used in places like the function
prototypes of TCG helper functions.

This means that there's no need for a special gdb_get_float64()
function to write a float64 value to the GDB protocol buffer; we can
just use gdb_get_reg64().

Similarly, for reading a value out of the GDB buffer into a float64
we can use ldq_p() and need not use ldfq_p().

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: default avatarLaurent Vivier <laurent@vivier.eu>
Message-Id: <20210208113428.7181-3-peter.maydell@linaro.org>
Message-Id: <20210211122750.22645-12-alex.bennee@linaro.org>
      7ed51401
  3. Feb 11, 2021
  5. Feb 05, 2021
  7. Jan 18, 2021
  9. Dec 12, 2020
  11. Dec 10, 2020
  13. Nov 13, 2020
    • Kevin Wolf's avatar
      hmp: Pass monitor to mon_get_cpu_env() · e7cff9c6
      Kevin Wolf authored 
      
mon_get_cpu_env() is indirectly called monitor_parse_arguments() where
the current monitor isn't set yet. Instead of using monitor_cur_env(),
explicitly pass the Monitor pointer to the function.

Without this fix, an HMP command like "x $pc" crashes like this:

  #0  0x0000555555caa01f in mon_get_cpu_sync (mon=0x0, synchronize=true) at ../monitor/misc.c:270
  #1  0x0000555555caa141 in mon_get_cpu (mon=0x0) at ../monitor/misc.c:294
  #2  0x0000555555caa158 in mon_get_cpu_env () at ../monitor/misc.c:299
  #3  0x0000555555b19739 in monitor_get_pc (mon=0x555556ad2de0, md=0x5555565d2d40 <monitor_defs+1152>, val=0) at ../target/i386/monitor.c:607
  #4  0x0000555555cadbec in get_monitor_def (mon=0x555556ad2de0, pval=0x7fffffffc208, name=0x7fffffffc220 "pc") at ../monitor/misc.c:1681
  #5  0x000055555582ec4f in expr_unary (mon=0x555556ad2de0) at ../monitor/hmp.c:387
  #6  0x000055555582edbb in expr_prod (mon=0x555556ad2de0) at ../monitor/hmp.c:421
  #7  0x000055555582ee79 in expr_logic (mon=0x555556ad2de0) at ../monitor/hmp.c:455
  #8  0x000055555582eefe in expr_sum (mon=0x555556ad2de0) at ../monitor/hmp.c:484
  #9  0x000055555582efe8 in get_expr (mon=0x555556ad2de0, pval=0x7fffffffc418, pp=0x7fffffffc408) at ../monitor/hmp.c:511
  #10 0x000055555582fcd4 in monitor_parse_arguments (mon=0x555556ad2de0, endp=0x7fffffffc890, cmd=0x555556675b50 <hmp_cmds+7920>) at ../monitor/hmp.c:876
  #11 0x00005555558306a8 in handle_hmp_command (mon=0x555556ad2de0, cmdline=0x555556ada452 "$pc") at ../monitor/hmp.c:1087
  #12 0x000055555582df14 in monitor_command_cb (opaque=0x555556ad2de0, cmdline=0x555556ada450 "x $pc", readline_opaque=0x0) at ../monitor/hmp.c:47

After this fix, nothing is left in monitor_parse_arguments() that can
indirectly call monitor_cur(), so the fix is complete.

Fixes: ff04108a
Reported-by: default avatarlichun <lichun@ruijie.com.cn>
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Message-Id: <20201113114326.97663-4-kwolf@redhat.com>
Reviewed-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      e7cff9c6
  15. Sep 18, 2020
  17. Sep 09, 2020
  19. Aug 21, 2020
  21. Jul 06, 2020
  23. Jun 26, 2020
    • Joseph Myers's avatar
      softfloat: merge floatx80_mod and floatx80_rem · 6b8b0136
      Joseph Myers authored 
      
The m68k-specific softfloat code includes a function floatx80_mod that
is extremely similar to floatx80_rem, but computing the remainder
based on truncating the quotient toward zero rather than rounding it
to nearest integer.  This is also useful for emulating the x87 fprem
and fprem1 instructions.  Change the floatx80_rem implementation into
floatx80_modrem that can perform either operation, with both
floatx80_rem and floatx80_mod as thin wrappers available for all
targets.

There does not appear to be any use for the _mod operation for other
floating-point formats in QEMU (the only other architectures using
_rem at all are linux-user/arm/nwfpe, for FPA emulation, and openrisc,
for instructions that have been removed in the latest version of the
architecture), so no change is made to the code for other formats.

Signed-off-by: default avatarJoseph Myers <joseph@codesourcery.com>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-Id: <alpine.DEB.2.21.2006081654280.23637@digraph.polyomino.org.uk>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      6b8b0136
  25. Jun 02, 2020
    • Laurent Vivier's avatar
      target/m68k: implement opcode fetoxm1 · 250b1da3
      Laurent Vivier authored 
      Example provided in the launchpad bug fails with:

   qemu: uncaught target signal 4 (Illegal instruction) - core dumped
   Illegal instruction (core dumped)

It appears fetoxm1 is not implemented:

   IN: expm1f
   0x800005cc: fetoxm1x %fp2,%fp0
   Disassembler disagrees with translator over instruction decoding
   Please report this to qemu-devel@nongnu.org

   (gdb) x/2hx 0x800005cc
   0x800005cc: 0xf200 0x0808

This patch adds the instruction.

Bug: https://bugs.launchpad.net/qemu/+bug/1881450


Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-Id: <20200531131951.631902-1-laurent@vivier.eu>
Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
      250b1da3
    • Laurent Vivier's avatar
      target/m68k: implement fmove.l #<data>,FPCR · 6a0e8bb4
      Laurent Vivier authored 
      
The immediate value mode was ignored and instruction execution
ends to an invalid access mode.

This was found running 'R' that set FPSR to 0 at startup with
a 'fmove.l #0,FPSR' in qemu-system-m68k emulation and triggers a
kernel crash:

[   56.640000] *** ADDRESS ERROR ***   FORMAT=2
[   56.640000] Current process id is 728
[   56.640000] BAD KERNEL TRAP: 00000000
[   56.640000] Modules linked in: sg evdev mac_hid ip_tables x_tables sha1_generic hmac ipv6 nf_defrag_ipv6 autofs4 ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common sr_mod cdrom mac_esp macsonic esp_scsi
[   56.640000] PC: [<00016a2c>] X_UNSUPP+0x2c/0x3c
[   56.640000] SR: 2004  SP: 3eb5e68c  a2: c02e239a
[   56.640000] d0: 00000040    d1: 00000002    d2: 8002adec    d3: 8002ad50
[   56.640000] d4: 8002c768    d5: 0000000d    a0: ffffffc2    a1: ffffffc1
[   56.640000] Process R (pid: 728, task=a3dfda5d)
[   56.640000] Frame format=2 instr addr=00000000
[   56.650000] Stack from 3a4d9f30:
[   56.650000]         41000000 00000002 00000002 ffffffc2 ffffffc1 1fff0000 80000000 00000000
[   56.650000]         3fbf0000 80000000 00000000 00000000 20000000 00000000 7fff0000 ffffffff
[   56.650000]         ffffffff 00000000 00050008 00000000 8000067c c02c2000 efffee20 000002d8
[   56.650000]         00002a28 3a4d9f98 00000002 00000014 fffffffe 8002c768 00000002 00000041
[   56.650000]         00000002 c041fc58 c0743758 ffffffff 00000000 0008c075 00002b24 00000012
[   56.650000]         000007d0 00000024 00000002 c05bef04 c05bef04 0000005e 00000077 c28aca70
[   56.650000] Call Trace: [<00050008>] copy_overflow+0x10/0x28
[   56.650000]  [<00002a28>] buserr+0x20/0x28
[   56.650000]  [<0008c075>] bpf_check+0x57f/0x1cfa
[   56.650000]  [<00002b24>] syscall+0x8/0xc
[   56.650000]  [<0000c019>] dn_sched_init+0x75/0x88
[   56.650000] Code: 1017 0200 00f0 0c00 0040 66ff 0000 05ac <f23c> 8800 0000 0000 f23c 9000 0000 0000 222e ff84 082e 0005 ff1c 6600 000a 0281
[   56.650000] Disabling lock debugging due to kernel taint
...

Reported-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
Tested-by: default avatarJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Message-Id: <20200531110231.620711-1-laurent@vivier.eu>
Signed-off-by: default avatarLaurent Vivier <laurent@vivier.eu>
      6a0e8bb4
  27. May 19, 2020
  29. May 06, 2020
    • KONRAD Frederic's avatar
      target/m68k: fix gdb for m68xxx · a976ed3f
      KONRAD Frederic authored 
      
Currently "cf-core.xml" is sent to GDB when using any m68k flavor.  Thing is
it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects
a coldfire FPU instead of the default m68881 FPU.

This is not OK because the m68881 floats registers are 96 bits wide so it
crashes GDB with the following error message:

(gdb) target remote localhost:7960
Remote debugging using localhost:7960
warning: Register "fp0" has an unsupported size (96 bits)
warning: Register "fp1" has an unsupported size (96 bits)
...
Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes):    \
  00000000000[...]0000

With this patch: qemu-system-m68k -M none -cpu m68020 -s -S

(gdb) tar rem :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x00000000 in ?? ()
(gdb) p $fp0
$1 = nan(0xffffffffffffffff)

Signed-off-by: default avatarKONRAD Frederic <frederic.konrad@adacore.com>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: default avatarLaurent Vivier <laurent@vivier.eu>
Message-Id: <1588094279-17913-3-git-send-email-frederic.konrad@adacore.com>
Message-Id: <20200430190122.4592-10-alex.bennee@linaro.org>
      a976ed3f
    • Philippe Mathieu-Daudé's avatar
      gdbstub: Introduce gdb_get_float64() to get 64-bit float registers · 38c1c098
      Philippe Mathieu-Daudé authored 
      
When converted to use GByteArray in commits 462474d7 and
a010bdbe, the call to stfq_p() was removed. This call
serialize a float.
Since we now use a GByteArray, we can not use stfq_p() directly.
Introduce the gdb_get_float64() helper to load a float64 register.

Fixes: 462474d7 ("target/m68k: use gdb_get_reg helpers")
Fixes: a010bdbe ("extend GByteArray to read register helpers")
Signed-off-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Message-Id: <20200414163853.12164-3-philmd@redhat.com>
Message-Id: <20200430190122.4592-3-alex.bennee@linaro.org>
      38c1c098
  31. Apr 15, 2020
  33. Mar 17, 2020
    • Peter Maydell's avatar
      cpu: Use DeviceClass reset instead of a special CPUClass reset · 781c67ca
      Peter Maydell authored 
      
The CPUClass has a 'reset' method.  This is a legacy from when
TYPE_CPU used not to inherit from TYPE_DEVICE.  We don't need it any
more, as we can simply use the TYPE_DEVICE reset.  The 'cpu_reset()'
function is kept as the API which most places use to reset a CPU; it
is now a wrapper which calls device_cold_reset() and then the
tracepoint function.

This change should not cause CPU objects to be reset more often
than they are at the moment, because:
 * nobody is directly calling device_cold_reset() or
   qdev_reset_all() on CPU objects
 * no CPU object is on a qbus, so they will not be reset either
   by somebody calling qbus_reset_all()/bus_cold_reset(), or
   by the main "reset sysbus and everything in the qbus tree"
   reset that most devices are reset by

Note that this does not change the need for each machine or whatever
to use qemu_register_reset() to arrange to call cpu_reset() -- that
is necessary because CPU objects are not on any qbus, so they don't
get reset when the qbus tree rooted at the sysbus bus is reset, and
this isn't being changed here.

All the changes to the files under target/ were made using the
included Coccinelle script, except:

(1) the deletion of the now-inaccurate and not terribly useful
"CPUClass::reset" comments was done with a perl one-liner afterwards:
  perl -n -i -e '/ CPUClass::reset/ or print' target/*/*.c

(2) this bit of the s390 change was done by hand, because the
Coccinelle script is not sophisticated enough to handle the
parent_reset call being inside another function:

| @@ -96,8 +96,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
|     S390CPU *cpu = S390_CPU(s);
|     S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
|     CPUS390XState *env = &cpu->env;
|+    DeviceState *dev = DEVICE(s);
|
|-    scc->parent_reset(s);
|+    scc->parent_reset(dev);
|     cpu->env.sigp_order = 0;
|     s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);

Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
Message-Id: <20200303100511.5498-1-peter.maydell@linaro.org>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Tested-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      781c67ca
    • Alex Bennée's avatar
      gdbstub: extend GByteArray to read register helpers · a010bdbe
      Alex Bennée authored 
      
Instead of passing a pointer to memory now just extend the GByteArray
to all the read register helpers. They can then safely append their
data through the normal way. We don't bother with this abstraction for
write registers as we have already ensured the buffer being copied
from is the correct size.

Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Acked-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: default avatarDamien Hedde <damien.hedde@greensocs.com>

Message-Id: <20200316172155.971-15-alex.bennee@linaro.org>
      a010bdbe
    • Alex Bennée's avatar
      target/m68k: use gdb_get_reg helpers · 462474d7
      Alex Bennée authored 
      
This is cleaner than poking memory directly and will make later
clean-ups easier.

Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: default avatarLaurent Vivier <laurent@vivier.eu>
Reviewed-by: default avatarPhilippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20200316172155.971-13-alex.bennee@linaro.org>
      462474d7
  35. Jan 24, 2020
  37. Jan 21, 2020
  39. Jan 16, 2020