>On Monday, July 1, 2019, 06:10:55 PM GMT+9, Peter Maydell
wrote: > > On Sat, 29 Jun 2019 at 17:37, Lucien
Murray-Pitts> > wrote:
> > However for the m68k the do_transaction_failed function pointer field
> > has not been implemented.>Er, I implemented that in commit
> > e1aaf3a88e95ab007
Hi Laurent / Richard,
(resent email )
Does anyone have any knowledge why gen_exception(s, s->base.pc_next,
EXCP_RTE);
is generated for "RTE" instruction, where as the "RTS" goes a gen_jmp?( note
see target/m68k/translate.c in functions DISAS_INSN(rte) and DISAS_INSN(rts)
Cheers,Luc
Hi folks,
Does anyone have any knowledge why
gen_exception(s, s->base.pc_next, EXCP_RTE);
Hi Richard/Laurent,
Great catch, I also just stumbled on this problem as well which I didnt see
with my other application code.
But I have another problem after applying the changes from your email, "RTE"
and breakpoints around a MOV/BusException/RTE behave oddly.
I would like to test with the s
> On Sunday, May 26, 2019, 10:10:39 PM GMT+9, Laurent Vivier
wrote: > On 26/05/2019 09:28, Lucien Murray-Pitts wrote:
>> On CPU32 and the early 68000 and 68010 the ISP doesnt exist.
>> These CPUs only have SSP/USP.
>> [SNIP]
>> The movec instruction when accessing these shadow registers
>> i
> On Sunday, May 26, 2019, 4:45:26 PM GMT+9, wrote: >
Subject; [Qemu-devel] [PATCH] Incorrect Stack Pointer shadow register support
on some m68k CPUs > .> snip> .> === OUTPUT BEGIN ===
> ERROR: Author email address is mangled by the mailing list
> #2:
> Author: Lucien Murray-Pitts
> On Friday, March 22, 2019, 11:01:34 PM GMT+9, Luc Michel
wrote: > Lucien: do you plan to send a re-roll?
Otherwise I'll do it on next
> Monday (25/03) because I would like this bug to be fixed before it hits 4.0.
I am on assignment in China which is why I havent gotten to it, I will att
On 24/01/2019 14.38, Alex Bennée wrote:
>
> Lucien Anti-Spam via Qemu-devel writes:
>
>> > On Thursday, January 24, 2019, 3:08:07 AM GMT+9, Emilio G. Cota
>> wrote: > > On Wed, Jan 23, 2019 at 15:58:27 +, Lucien
>>Anti-Spam via Qemu-devel wrote:&g
Hi Luc,
Great feedback from both you and Eric - im blown away, I dont thinktheres a
single 1byte ascii character left unturned there :)My coding style snuck in
erywhere, as did my Scottish English!
On Friday, February 1, 2019, 10:33:18 PM GMT+9, Luc Michel
wrote: > > + GDBThreadIdKind v
On Thursday, January 31, 2019, 12:47:23 PM GMT+9, Eric Blake
wrote:
On 1/30/19 6:41 PM, Lucien Anti-Spam via Qemu-devel wrote:
> > This fixes a regression in rsp packet vCont due to recently added
> > multiprocess support. (Short commit hash: e40e520).
> >
> Y
This fixes a regression in rsp packet vCont due to recently added multiprocess
support. (Short commit hash: e40e520).
The result is that vCont now does not recognise the case where no
process/thread is provided after the action.
This may not show up with GDB, but using Lauterbach Trace32, and He
Hi gdbstub maintainers (CC: Luc Michel as he wrote the patch that probably
caused this issue)
I have found an issue with IDA Pro when moving to QEMU3.x where RUN/PAUSE has
stopped working.
I am pretty sure its to do with this debugger sending no thread-id with the
vCont packet action
That is tha
> On Thursday, January 24, 2019, 3:08:07 AM GMT+9, Emilio G. Cota
wrote: > > On Wed, Jan 23, 2019 at 15:58:27 +0000, Lucien
Anti-Spam via Qemu-devel wrote:> > Hi folks,
> > I noticed that with 3.x release that the GDB options (-S -s) for certain
> >
Hi folks,
I noticed that with 3.x release that the GDB options (-S -s) for certain CPU
results in very weird stepping.Usually stops afer a few steps, whilst the stub
continues responding the PC doesnt update, however, I have only deeply looked
at the m68k.
In the case of the m68K the SR gets the
14 matches
Mail list logo
