This is what ends up in the si_addr field of the siginfo_t that gets passed to my signal handler. Since this is at the application level, I don't really know what's happening at the "hardware" level in QEMU, or how it translates that into signal stuff. Right now I'm trying out crosstool-ng to build a SPARC toolchain since that was also broken for some weird, toolchain looking reason, but once I have that handled I'll see if I can get ahold of the QEMU folks. Thanks!
Gabe On Thu, Apr 9, 2020 at 5:38 AM Giacomo Travaglini < [email protected]> wrote: > Agree with Ciro. > > What do you mean by PC here anyway? > > "Also I notice that the thumb version traps, but gives me some other PC > which doesn't actually correspond to the illegal instruction" > > Are you referring to the value stored in the ELR_EL1 (Exception link > register) or the PC of the exception handler? > > Giacomo > > -----Original Message----- > From: gem5-dev <[email protected]> On Behalf Of Ciro Santilli > Sent: 09 April 2020 13:30 > To: gem5 Developer List <[email protected]> > Subject: Re: [gem5-dev] qemu ARM not dying on m5 ops? > > Send an email to the QEMU mailing list with the instruction encoding, > possibly CC Peter Maydell, he usually replies super fast 🙂 > ________________________________ > From: gem5-dev <[email protected]> on behalf of Gabe Black < > [email protected]> > Sent: Thursday, April 9, 2020 1:24 PM > To: gem5 Developer List <[email protected]> > Subject: [gem5-dev] qemu ARM not dying on m5 ops? > > Hi ARM folks. I'm trying to run my shiny new instruction based m5 op test > on QEMU for ARM, and it's not actually exploding with an illegal > instruction when it tries to run an m5 op. I've tried this with the older > version of the utility as well, and I see the same behavior. > > I've dug into it, and the encoding is doing a move from a coprocessor > register into a regular register I think, and operating on coprocessor 1. I > *think* if the coprocessor doesn't exist, the CPU is supposed to trap > somehow, and not just plow ahead. > > Is this something wrong with QEMU? Do I need to pass it some magical flag > to get it to work like I expect? I'm not super worried about how correct > QEMU is, but I want to make sure the code in the m5 utility is correct. It > would be nice if QEMU ran it correctly too, since that would be a nice > independent way to verify that the utility is still working. > > Any help would be appreciated! > > Also I notice that the thumb version traps, but gives me some other PC > which doesn't actually correspond to the illegal instruction. I'm not sure > what's going on there. I'll probably try running these on real ARM hardware > I have with me to see if they do what I want there. > > Gabe > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
