[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus H
From: |
ThomasK |
Subject: |
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter |
Date: |
Fri, 28 Feb 2014 07:19:28 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 |
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
- [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, ThomasK, 2014/02/26
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Klaus Rudolph, 2014/02/26
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Markus Hitter, 2014/02/26
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Wojciech Stryjewski, 2014/02/26
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Markus Hitter, 2014/02/27
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Klaus Rudolph, 2014/02/27
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter,
ThomasK <=
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Markus Hitter, 2014/02/28
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Klaus Rudolph, 2014/02/28
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Markus Hitter, 2014/02/28
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Michael Hennebry, 2014/02/28
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Klaus Rudolph, 2014/02/28
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Michael Hennebry, 2014/02/28
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Michael Hennebry, 2014/02/27
- Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter, Klaus Rudolph, 2014/02/27