On 7/10/19 4:04 AM, Richard Henderson wrote:
On 7/9/19 6:58 PM, Lucien Murray-Pitts wrote:
Any suggestions on how to obtain pc_next from the "m68k_cpu_do_interrupt(
CPUState *cs)" ?
test
I did have a suggestion. It was fairly detailed.
https://lists.gnu.org/archive/html/qemu-devel/2019-06/
On 7/10/19 7:50 PM, Lucien Murray-Pitts wrote:
>
>
>> On Wed, Jul 10, 2019 at 4:04 AM Richard Henderson
> mailto:richard.hender...@linaro.org>> wrote:
>
> > I did have a suggestion. It was fairly detailed.
> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
>
> Your
On Wed, 10 Jul 2019 at 19:15, Alex Bennée wrote:
> Lucien Murray-Pitts writes:
> > I am very new to TCG, so it does seem there is a lot of code in the
> > translator_loop that appears to be interacting with the CPU model/state.
> > Should I be worried about this, or is this a safe function to cal
Lucien Murray-Pitts writes:
>> On Wed, Jul 10, 2019 at 4:04 AM Richard Henderson <
> richard.hender...@linaro.org> wrote:
>
>> > I did have a suggestion. It was fairly detailed.
>> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
>>
>> Your solution is elegant at about 10
> On Wed, Jul 10, 2019 at 4:04 AM Richard Henderson <
richard.hender...@linaro.org> wrote:
> > I did have a suggestion. It was fairly detailed.
> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
>
> Your solution is elegant at about 10 lines that return getl_ilen(pc), but
it
Hi Richard,
I am so sorry, I was too naive when you suggested this and I misunderstood
the meaning of what you were telling me.
After spending most nights digging through the RTE/Exception process for
the M68000 I now actually get what you
were trying to tell me and its simply genius - I hope it
On 7/9/19 6:58 PM, Lucien Murray-Pitts wrote:
> Any suggestions on how to obtain pc_next from the "m68k_cpu_do_interrupt(
> CPUState *cs)" ?
I did have a suggestion. It was fairly detailed.
https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
r~
On Tue, 9 Jul 2019 at 17:58, Lucien Murray-Pitts
wrote:
> On Mon, Jul 1, 2019 at 9:11 PM Peter Maydell wrote:
>> > Yes, that's a known bug for arm -- we treat "single step" as
>> > "execute one instruction", whereas I think most debuggers will
>> > treat "we took an exception" as a reason to stop
On Mon, Jul 1, 2019 at 9:11 PM Peter Maydell
wrote:
> > On Mon, 1 Jul 2019 at 13:04, Lucien Anti-Spam
> > wrote:
> > > Further to my initial problem I noticed that TRAP #0 also jumps to the
> handlers +1 instruction.
> > > Same behavior can also be seen with ARM "SWI #0".(PC shows 0x0C vs
>
On Mon, 1 Jul 2019 at 13:04, Lucien Anti-Spam
wrote:
> Further to my initial problem I noticed that TRAP #0 also jumps to the
> handlers +1 instruction.
> Same behavior can also be seen with ARM "SWI #0".(PC shows 0x0C vs the
> expected 0x08)
Yes, that's a known bug for arm -- we treat "sin
>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
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. Are
you working with an out-of-date version of QEMU ?
thanks
-- PMM
On 6/29/19 6:36 PM, Lucien Murray-Pitts wrote:
> On Sat, Jun 29, 2019 at 12:15:44PM +0200, Richard Henderson wrote:
>> On 6/28/19 5:50 PM, Lucien Murray-Pitts wrote:
>>> op_helper.c
>>>static void m68k_interrupt_all(CPUM68KState *env, int is_hw)
>>>...
>>> if (cs->exception_index == E
On Sat, Jun 29, 2019 at 12:15:44PM +0200, Richard Henderson wrote:
> On 6/28/19 5:50 PM, Lucien Murray-Pitts wrote:
> > op_helper.c
> >static void m68k_interrupt_all(CPUM68KState *env, int is_hw)
> >...
> > if (cs->exception_index == EXCP_ACCESS) {
> > ...
> > do_stack_fra
On 6/28/19 5:50 PM, Lucien Murray-Pitts wrote:
> op_helper.c
>static void m68k_interrupt_all(CPUM68KState *env, int is_hw)
>...
> if (cs->exception_index == EXCP_ACCESS) {
> ...
> do_stack_frame(env, &sp, 7, oldsr, 0, retaddr /*LMP: BROKEN - needs PC
> NEXT*/);
>
> Actua
On Fri, Jun 28, 2019 at 11:35:48AM +0200, Richard Henderson wrote:
> On 6/28/19 2:27 AM, Lucien Murray-Pitts wrote:
> >
> > [snip] ... the "return" address is the instruction that causes the
> > exception.
> > So it immediately does return to the ISR.
> > This is a different issue, but I think in
On 6/28/19 2:27 AM, Lucien Murray-Pitts wrote:
> The original way of handling it was causing single step to malfunction, I dont
> rightly know why but the effect was that step would step twice and end up
> inside the ISR function again OR just stepping past the RTE as if it didnt
> exist.
>
> I ha
On Thu, Jun 27, 2019 at 07:09:39PM +0200, Richard Henderson wrote:
> On 6/27/19 3:22 PM, Lucien Anti-Spam wrote:
> > 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
On 6/27/19 3:22 PM, Lucien Anti-Spam wrote:
> 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 functi
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);
21 matches
Mail list logo
