Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter

[ThomasK]

Hi list,

> > The discussion might be moot. Yesterday I tried to rebase on more
> > recent SimulAVR sources and, unfortunately, it's no longer possible.

I understand, that Markus is a bit ot POS, because the siminfo part is 
his "baby". But on one hand, the change isn't so difficult, the 
mechanism between bfd and ElfIO is nearly the same, especially in the 
for siminfo relevant parts. And on the other hand: I (but "I" isn't 
"simulavr" would think about to use this feature for processor clock and 
processor type, not for the serialio part! The last isn't very flexible 
and, for example for the serial input part,the filename is then hold 
inside elf file! If you want to change this you have to recompile and 
link the target file! And there is no time control, when a byte is sent 
into controller, all will send without gap! Not a realistic scenery. And 
there is one thing in Markus implementation, which (in my opinion) isn't 
good, there is a header file, which is used for build simulavr AND for a 
AVR target file!

> I am also a bit doubtfull for this replacement. My point was, that I
> expect the first problem if something changes in libbfd/iberty without
> changing in ElfIO. A lot of my tooling is also based on bfd directly. I

My experiance with elf files: (not only for AVR built by avr-gcc) this 
is a good defined standard and not only gcc produces elf files. (see 
http://de.wikipedia.org/wiki/Executable_and_Linking_Format) The only one 
part, where I had sometimes problems with reading and parsing elf files 
is debug information content! (but this isn't directly a part of elf 
format) There are sometimes diffs in usage of debug information between 
the different producers of compiler/linker or other elf producing tools! 
Never in segments, never in stringtable, never in section description 
table. So, the risk for this change is minimal by a big benefit to make 
automake configuration more slim and building simulavr on other 
platforms/distributions more easy.

And the usage of ElfIO instead of bfd doesn't forbid usage of bfd in 
tools around or also in a tool, which links libsim itself! (@Klaus) So, 
I think, you'll not have problems with that.

> had no chance to test these features until now. My wish was to get a tag
> in git for the last version BEFORE this big change. Maybe it is better

The tag is a good idea, I'll do that next.

> possible, because the compiler/linker use it and simulavr must be able
> to read exactly what the compiler generate. Thomas think this is not a

I can't see any problems, even if avr-gcc is based on libbfd and (now) 
simulavr not, see below.

> If you have a look into the linker scripts, there is already a signature
> section for the infos. I think any meta data for type of cpu, clock etc
> can go there. There is no need to allocate real memory or any new
> section which must be considered in the linking stage.

One one hand, to use signature section (to not change the linker 
script), this is a good idea. On the other hand ... you'll come in 
trouble, if somebody tries to use both, signature and siminfo. Signature 
is just a array of 3 bytes, siminfo is a structure description, with a 
id tag, a length byte and the payload. Problem is, that depending on the 
link order the signature and the parts of siminfo are mixed, sometimes 
signature is linked first (especially if this is defined in the first 
object file, which is linked), sometimes at end, and, if somebody uses 
different files to define siminfo parts (which isn't forbidden), then 
signature could be mixed in between.

That all would make parsing siminfo (and signature too) very difficult 
and maybe also unstable.

Markus suggests to give linker instructions (and to link in a different 
memory area as signature area) by commandline on link time. But maybe 
the problem there is, that, if the program doesn't use this, this area 
isn't linked. Some linker remove it, I think, even if the relevant 
object files is used by program. Maybe there are some possibilities to 
prevent this (for example as Wojciech proposes), that's to be analyzed.

cu, Thomas