Re: [Simulavr-devel] New feature: read in signatue, lock bits and fuses from elf, if available

[Raphaël Martin]

Le dimanche 06 jun 2010 à 17:33:03 (+0200), ThomasK écrivait : 
> Hi list,
>
> I've started now to implement this. If simulavr commandline application  
> read a given elf file, it reads now too signature, fuses and lock bits  

I think it's a very good thing, probably because my use of simulavr is
dedicated to automated unit and acceptance testing. So every
functionality that can improve the testing of the final binary is good
for use.

For the moment, simulavr can load and run tests with a so called "Atmel
production file" (meaning only one ELF file storing everything necessary
for production programming, using special sections), but will ignore
those special sections.

Controlling those sections, even if it's only to fire an error if inconsistent, 
is
good in term of buildtime control.

> One question is, is there a need to disable this feature? (maybe on  
> avr-libc tests?) 

Well I would say that no inconsistencies should ever be ignored. I would at
least log a warning in that "disabled mode".

But to be honest, I won't really offer that mode if I could. That's additional
work to handle unproper binary or error in command line, even if I understand 
that your goal is
to keep backward compatibility with historical behaviour, which is always smart.

Let's imagine you instead change the '-d' option behaviour, and make it 
non-mandatory option :
- if not present, ELF signature should be present, and will be used to
  define the AVR. If no signature in ELF : exit and error "can't guess device, 
use -d"
- if '-d' given,
  - (*)if EFL signature found : should match, or exit and descriptive error is 
fired 'signature 
    mismatch: ELF says xxx, and you asked for xxx'
  - if no signature found (that's kinda 'historical' behaviour), '-d' works as
    before

(*) In that case, as you said, backward compatibility may be broken. An atmel 
ELF
production file containing atmega16 (for example) signature that
previously loaded with '-d atmega32' option would now fail, requiring
either to fix the ELF, on the command line.
Never good to break compatibility, I fight for that...but only if it's
not to fix a 'bug'.

So the real questions are : 
- is this case rare, so handling it is work for very few
- was this permissive behaviour a 'functionality' (meaning that it adds
  something to users), or sort of a 'bug' (meaning that it's mainly
  dangerous)

My personal answers would be that yes it's probably rare, and that I
consider it as a 'bug' because if someone invested time in giving an ELF
signature, there was probably a good reason.
Soathat's why, as I said, I wouldn't implement that 'disabled mode'.

> In the moment, this code resides in my repository, if someone wants to  
> review it or try it, I can upload it in a development branch. Please let  
> me know, if I should do this.

Yes, I'm interested in trying it, as I'm right now dealing with thoses
special sections.

> Planed next step is, to extend (E)LPM instruction to read - depending on  
> controller - fuses, lockbits and signature by program.

Very interested in that too ;)
Especially lockbits control, wich is a strong security matter. So easy
to release without noticing it a binary that will end as not
read-protected AVRs...

-- 
Raphaël
.
%{-----------------------------------------------------------------------+
 | Linus Torvalds takes one look at your desktop and knows which porn    |
 | sites you visited. In the last ten years.                             |
 | -- Linus Torvalds facts                                               |
 +-----------------------------------------------------------------------%}