On Thu, 30 Sept 2021 at 12:34, abhijeet inamdar
wrote:
> Actually the ELF generates the .bin file which is being used to run on the
> target (hardware). It's address starts from zero when I see the starting
> frames of it. As follows:
>
> IN:
> 0x0002: c0de stm r0!, {r1, r2, r3,
The above is when I load the .bin instead of ELF in the machine.
On Thu, Sep 30, 2021 at 1:33 PM abhijeet inamdar <
abhijeetinamdar3...@gmail.com> wrote:
> Actually the ELF generates the .bin file which is being used to run on the
> target (hardware). It's address starts from zero when I see the
Actually the ELF generates the .bin file which is being used to run on the
target (hardware). It's address starts from zero when I see the starting
frames of it. As follows:
IN:
0x0002: c0de stm r0!, {r1, r2, r3, r4, r6, r7}
0x0004: 0003 movs r3, r0
0x0006: 000
On Thu, 30 Sept 2021 at 07:17, abhijeet inamdar
wrote:
>
> But this very ELF file runs on the target(real hardware) perfectly. So how
> different should it be to emulate?
Real hardware doesn't have a magic ELF file loader. The
details of what a debug environment or whatever mechanism
you're usin
But this very ELF file runs on the target(real hardware) perfectly. So how
different should it be to emulate?
Thank you,
Abhijeet.
On Wed, Sep 29, 2021 at 10:31 PM Peter Maydell
wrote:
> On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar
> wrote:
> >
> > I tried to add -d in_asm,out_asm,guest_err
On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar
wrote:
>
> I tried to add -d in_asm,out_asm,guest_errors it gives out as follows:
'int,exec,cpu' are probably also helpful.
> [New Thread 0x7fffe700 (LWP 44283)]
>
> IN:
> 0x: andeqr0, r0, r0
We started
I tried to add -d in_asm,out_asm,guest_errors it gives out as follows:
PROLOGUE: [size=45]
0x70849000: 55 pushq%rbp
0x70849001: 53 pushq%rbx
0x70849002: 41 54pushq%r12
0x70849004: 41 55
On Thu, 16 Sept 2021 at 20:13, abhijeet inamdar
wrote:
>
> Is there any way/s to check where actually is it failing or point which file?
Use the usual debugging facilities -- gdbstub or -d debug logging.
-- PMM
Is there any way/s to check where actually is it failing or point which
file?
Thank you,
Abhijeet.
On Thu, Sep 16, 2021 at 8:49 PM Peter Maydell
wrote:
> On Thu, 16 Sept 2021 at 19:46, Peter Maydell
> wrote:
> >
> > On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar
> > wrote:
> > > How do I fix
On Thu, 16 Sept 2021 at 19:46, Peter Maydell wrote:
>
> On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar
> wrote:
> > How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I
> > load ELF.
> >
> > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> >
> > R
On Thu, 16 Sept 2021 at 17:52, abhijeet inamdar
wrote:
> How do I fix it ? it's for cortex-m3 and the below is the gdb trace when I
> load ELF.
>
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> R00= R01= R02= R03=
> R04= R05=0
11 matches
Mail list logo
