Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader
can someone explain what is the intention to have behave different in simulation then in real hardware? A real controller doesn't "terminate" if it runs into , so somulavr currently doesn't behave like real hardware. On the other hand, simulavr has an additional UART for debug output - that's also not, what real hardware does, but very useful. So why not use the undefined instruction as a debug aid, since it mostly points to serious problems? This would give a chance to inspect the machine state. Silently terminating simulavr on is the worst solution. Albrecht On 05.02.2016 12:34, Klaus Rudolph wrote: Hi, can someone explain what is the intention to have behave different in simulation then in real hardware? What is the intended use case of an illegal instruction or simulate undefined behavior? I can't follow at this point. I can only see my use case in the moment which is as follows: Write, compile, link program Verify & Validate on simulation use simulation as regression tool for code maintenance If I see that my code runs into a empty flash region, I will stop immediately with debugging, I simply must fix my code. Maybe you have another situation or you plan very different things. So please give me an idea what is the scenario behind that idea to run over illegal instructions. >From simulation side is very easy to exchange any illegal instruction to nop, but is that the intention and why? If we plan to do this change we must support the current implementation. Maybe a command line switch to extend the instruction set for "undefined" instruction for personal use? Changing the default behavior is not acceptable for my use cases. Regards Klaus Gesendet: Freitag, 05. Februar 2016 um 10:57 Uhr Von: "Albrecht Frenzel" An: "Joerg Wunsch" , simulavr-devel@nongnu.org Betreff: Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader As the AVR (undocumentedly) treats opcode as a NOP, I think the simulator could even just continue. That's a good idea, but why not make it configurable: in normal mode it is NOP, but on demand can act as BREAK? Albrecht On 05.02.2016 08:02, Joerg Wunsch wrote: As Albrecht Frenzel wrote: The strange thing: sometimes pc gets loaded with the correct pc 0x7e00 and it is possible to step through the code using the same .elf-file. You can always set the current PC address in GDB before proceeding: set $pc = 0x7e00 Regarding Illegal opcode 'ff ff': wouldn't it be better to simply stop simulavr instead of terminating? That would give a chance to investigate. As the AVR (undocumentedly) treats opcode as a NOP, I think the simulator could even just continue. There are possible scenarios where this feature could be used deliberately, e. g. by including a patch area in the code that is simply run through as long as it is but which can be written later on to include additional features. ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader
Hi, can someone explain what is the intention to have behave different in simulation then in real hardware? What is the intended use case of an illegal instruction or simulate undefined behavior? I can't follow at this point. I can only see my use case in the moment which is as follows: Write, compile, link program Verify & Validate on simulation use simulation as regression tool for code maintenance If I see that my code runs into a empty flash region, I will stop immediately with debugging, I simply must fix my code. Maybe you have another situation or you plan very different things. So please give me an idea what is the scenario behind that idea to run over illegal instructions. >From simulation side is very easy to exchange any illegal instruction to nop, >but is that the intention and why? If we plan to do this change we must >support the current implementation. Maybe a command line switch to extend the >instruction set for "undefined" instruction for personal use? Changing the >default behavior is not acceptable for my use cases. Regards Klaus > Gesendet: Freitag, 05. Februar 2016 um 10:57 Uhr > Von: "Albrecht Frenzel" > An: "Joerg Wunsch" , simulavr-devel@nongnu.org > Betreff: Re: [Simulavr-devel] simulavr is very unreliable executing a > bootloader > > > As the AVR (undocumentedly) treats opcode as a NOP, I think > > the simulator could even just continue. > > That's a good idea, but why not make it configurable: in normal mode > it is NOP, but on demand can act as BREAK? > > Albrecht > > > On 05.02.2016 08:02, Joerg Wunsch wrote: > > As Albrecht Frenzel wrote: > > > >> The strange thing: sometimes pc gets loaded with the correct pc > >> 0x7e00 and it is possible to step through the code using the same > >> .elf-file. > > You can always set the current PC address in GDB before proceeding: > > > > set $pc = 0x7e00 > > > >> Regarding Illegal opcode 'ff ff': wouldn't it be better to simply > >> stop simulavr instead of terminating? That would give a chance to > >> investigate. > > As the AVR (undocumentedly) treats opcode as a NOP, I think > > the simulator could even just continue. There are possible > > scenarios where this feature could be used deliberately, e. g. > > by including a patch area in the code that is simply run through > > as long as it is but which can be written later on to > > include additional features. > > > ___ > Simulavr-devel mailing list > Simulavr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/simulavr-devel > ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader
As the AVR (undocumentedly) treats opcode as a NOP, I think the simulator could even just continue. That's a good idea, but why not make it configurable: in normal mode it is NOP, but on demand can act as BREAK? Albrecht On 05.02.2016 08:02, Joerg Wunsch wrote: As Albrecht Frenzel wrote: The strange thing: sometimes pc gets loaded with the correct pc 0x7e00 and it is possible to step through the code using the same .elf-file. You can always set the current PC address in GDB before proceeding: set $pc = 0x7e00 Regarding Illegal opcode 'ff ff': wouldn't it be better to simply stop simulavr instead of terminating? That would give a chance to investigate. As the AVR (undocumentedly) treats opcode as a NOP, I think the simulator could even just continue. There are possible scenarios where this feature could be used deliberately, e. g. by including a patch area in the code that is simply run through as long as it is but which can be written later on to include additional features. ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] simulavr is very unreliable executing a bootloader
As Albrecht Frenzel wrote: > The strange thing: sometimes pc gets loaded with the correct pc > 0x7e00 and it is possible to step through the code using the same > .elf-file. You can always set the current PC address in GDB before proceeding: set $pc = 0x7e00 > Regarding Illegal opcode 'ff ff': wouldn't it be better to simply > stop simulavr instead of terminating? That would give a chance to > investigate. As the AVR (undocumentedly) treats opcode as a NOP, I think the simulator could even just continue. There are possible scenarios where this feature could be used deliberately, e. g. by including a patch area in the code that is simply run through as long as it is but which can be written later on to include additional features. -- cheers, Joerg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-) ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
[Simulavr-devel] simulavr is very unreliable executing a bootloader
My command sequence: simulavr -G -d atmega328 -f boot.elf ddd --debugger avr-gdb file boot.elf simulavr-devel@nongnu.org stepi simulavr terminates: -- Sent: $98e1908380830895eddf803219f088e0f5dfffcf84e1dfcfcf93c82fe3dfc150e9f7cf91f1cf282e80e0e8dfe0e0ff2709940206#fb gdb -> Ack Recv: "$m8000,40#c5" Ack -> gdb WARNING: file cmd/gdbserver.cpp: line 883: Invalid memory address: 0x8000. Sent: $E05#aa gdb -> Ack Recv: "$vCont?#49" Ack -> gdb gdb command 'vCont?' not supported Sent: $#00 gdb -> Ack Recv: "$Hc0#db" Ack -> gdb Sent: $#00 gdb -> Ack Recv: "$s#73" Ack -> gdb FATAL: file decoder.cpp: line 1777: Illegal opcode 'ff ff' executed at PC=0x0 (0)! Simulation terminated! -- Reason is, that pc contains 0. On step avr-gdb responds with 'Cannot find bounds of current function' The strange thing: sometimes pc gets loaded with the correct pc 0x7e00 and it is possible to step through the code using the same .elf-file. Regarding Illegal opcode 'ff ff': wouldn't it be better to simply stop simulavr instead of terminating? That would give a chance to investigate. Regards Albrecht ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
