Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
On Sun, 2 Mar 2014, Klaus Rudolph wrote: Was the idea to simplify the usage of all the tools? It is easier to give: avr-gcc -g -O2 -mmcu=atmega16 -o fred.elf -Wl,--section-start=.siminfo=0x90 fred.c instead of including only a header file? The given command line looks much more complicated than the command line for simulavr itself with needed info parms. I dislike this solution! Manually adding linker infos on the command line is never an option for me. Introducing such very secial solutions to "simplify" the usage of simulavr looks not the perfect way :-) So please do not introduce this feature in that way. It is terrible! That is why Odin invented make files and wrapper scripts: LDFLAGS+= -Wl,--section-start=.siminfo=0x90 or simulavr-gcc: avr-gcc -Wl,--section-start=.siminfo=0x90 "$*" -- Michael henne...@web.cs.ndsu.nodak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Was the idea to simplify the usage of all the tools?
It is easier to give:
avr-gcc -g -O2 -mmcu=atmega16 -o fred.elf
-Wl,--section-start=.siminfo=0x90 fred.c
instead of including only a header file?
The given command line looks much more complicated than the command line
for simulavr itself with needed info parms.
I dislike this solution! Manually adding linker infos on the command
line is never an option for me. Introducing such very secial solutions
to "simplify" the usage of simulavr looks not the perfect way :-) So
please do not introduce this feature in that way. It is terrible!
Regards
Klaus
ThomasK schrieb:
> Hi,
>
> to clarify one part of the discussion about siminfo: with the
> information from Markus I have made some tests about .signature and
> .siminfo section in elf file. Result: get .siminfo section into elf file
> is easy, just a command line option on compile/link. Markus has found
> out this and he has also created an example in his patches, where you
> can see this. (see below for the results)
>
>> Other tools might not use __signature .
>> Anyone know for sure?
>> They might just use the first 1, 2 or 3 bytes of .signature .
>> Those might be siminfo bytes instead of signature bytes.
>> For that matter, if .signature has no signature data, but it has siminfo
>> data,
>> said data would likely be mistaken for signature data.
>
> That's the point in my opinion not to use signature section. And as you
> can see below, it's not necessary.
>
> cu, Thomas
>
> -
>
> I use the examples/simple_ex1/fred.c as source. Compile and link:
>
>> avr-gcc -g -O2 -mmcu=atmega16 -o fred.elf fred.c
>
> will give the following:
>
>> readelf -S fred.elf
>
> Section Headers:
> [Nr] Name Type Addr OffSize ES Flg Lk Inf Al
> [ 0] NULL 00 00 00 0 0 0
> [ 1] .textPROGBITS 74 f6 00 AX 0 0 2
> [ 2] .dataPROGBITS 00800060 00016a 58 00 WA 0 0 1
> [ 3] .stabPROGBITS 0001c4 000954 0c 4 0 4
> [ 4] .stabstr STRTAB 000b18 000376 00 0 0 1
> [ 5] .shstrtabSTRTAB 000e8e 36 00 0 0 1
> [ 6] .symtab SYMTAB 001004 000410 10 7 17 4
> [ 7] .strtab STRTAB 001414 0002d0 00 0 0 1
>
> (result is shortend!) Now I add in fred.c on line 8 (after the heading
> comment):
>
> #include
>
> Compile and link will show:
>
>> readelf -S fred.elf
>
> Section Headers:
> [Nr] Name Type Addr OffSize ES Flg Lk Inf Al
> [ 0] NULL 00 00 00 0 0 0
> [ 1] .textPROGBITS 94 f6 00 AX 0 0 2
> [ 2] .dataPROGBITS 00800060 00018a 58 00 WA 0 0 1
> [ 3] .signature PROGBITS 0084 0001e2 03 00 A 0 0 1
> [ 4] .stabPROGBITS 0001e8 000b64 0c 5 0 4
> [ 5] .stabstr STRTAB 000d4c 00083b 00 0 0 1
> [ 6] .shstrtabSTRTAB 001587 41 00 0 0 1
> [ 7] .symtab SYMTAB 001730 000430 10 8 18 4
> [ 8] .strtab STRTAB 001b60 0002dc 00 0 0 1
>
>> readelf -x .signature fred.elf
>
> Hex dump of section '.signature':
> 0x0084 03941e ...
>
> Now I add BEFORE the include statement:
>
> const unsigned long _test_ __attribute__((section (".signature"))) =
> 0x11223344;
> #include
>
> This brings:
>
> Hex dump of section '.signature':
> 0x0084 44332211 03941e D3"
>
> This shows the problem with .signature section, even with the order
> inside of one file or if this is spread over a few object files, which
> are linked later.
>
> Markus solution is to give the linker some information, how to work with
> .siminfo:
>
> Instead of the changes before I add to line 8 in fred.c:
>
> const unsigned long _test_ __attribute__((section (".siminfo"))) =
> 0x11223344;
>
> The compile-and-link command:
>
> avr-gcc -g -O2 -mmcu=atmega16 -o fred.elf
> -Wl,--section-start=.siminfo=0x90 fred.c
>
> Readelf shows:
>
>> readelf -S fred.elf
>
> Section Headers:
> [Nr] Name Type Addr OffSize ES Flg Lk Inf Al
> [ 0] NULL 00 00 00 0 0 0
> [ 1] .siminfo PROGBITS 0090 0001e2 04 00 A 0 0 1
> [ 2] .textPROGBITS 94 f6 00 AX 0 0 2
> [ 3] .dataPROGBITS 00800060 00018a 58 00 WA 0 0 1
> [ 4] .stabPROGBITS 0001e8 000960 0c 5 0 4
> [ 5] .stabstr STRTAB 000b48 00038c 00 0 0 1
> [ 6] .shstrtabSTRTAB 000ed4 3f 00 0 0 1
> [ 7] .symtab SYMTAB
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Hi,
to clarify one part of the discussion about siminfo: with the
information from Markus I have made some tests about .signature and
.siminfo section in elf file. Result: get .siminfo section into elf file
is easy, just a command line option on compile/link. Markus has found
out this and he has also created an example in his patches, where you
can see this. (see below for the results)
Other tools might not use __signature .
Anyone know for sure?
They might just use the first 1, 2 or 3 bytes of .signature .
Those might be siminfo bytes instead of signature bytes.
For that matter, if .signature has no signature data, but it has siminfo
data,
said data would likely be mistaken for signature data.
That's the point in my opinion not to use signature section. And as you
can see below, it's not necessary.
cu, Thomas
-
I use the examples/simple_ex1/fred.c as source. Compile and link:
> avr-gcc -g -O2 -mmcu=atmega16 -o fred.elf fred.c
will give the following:
> readelf -S fred.elf
Section Headers:
[Nr] Name Type Addr OffSize ES Flg Lk Inf Al
[ 0] NULL 00 00 00 0 0 0
[ 1] .textPROGBITS 74 f6 00 AX 0 0 2
[ 2] .dataPROGBITS 00800060 00016a 58 00 WA 0 0 1
[ 3] .stabPROGBITS 0001c4 000954 0c 4 0 4
[ 4] .stabstr STRTAB 000b18 000376 00 0 0 1
[ 5] .shstrtabSTRTAB 000e8e 36 00 0 0 1
[ 6] .symtab SYMTAB 001004 000410 10 7 17 4
[ 7] .strtab STRTAB 001414 0002d0 00 0 0 1
(result is shortend!) Now I add in fred.c on line 8 (after the heading
comment):
#include
Compile and link will show:
> readelf -S fred.elf
Section Headers:
[Nr] Name Type Addr OffSize ES Flg Lk Inf Al
[ 0] NULL 00 00 00 0 0 0
[ 1] .textPROGBITS 94 f6 00 AX 0 0 2
[ 2] .dataPROGBITS 00800060 00018a 58 00 WA 0 0 1
[ 3] .signature PROGBITS 0084 0001e2 03 00 A 0 0 1
[ 4] .stabPROGBITS 0001e8 000b64 0c 5 0 4
[ 5] .stabstr STRTAB 000d4c 00083b 00 0 0 1
[ 6] .shstrtabSTRTAB 001587 41 00 0 0 1
[ 7] .symtab SYMTAB 001730 000430 10 8 18 4
[ 8] .strtab STRTAB 001b60 0002dc 00 0 0 1
> readelf -x .signature fred.elf
Hex dump of section '.signature':
0x0084 03941e ...
Now I add BEFORE the include statement:
const unsigned long _test_ __attribute__((section (".signature"))) =
0x11223344;
#include
This brings:
Hex dump of section '.signature':
0x0084 44332211 03941e D3"
This shows the problem with .signature section, even with the order
inside of one file or if this is spread over a few object files, which
are linked later.
Markus solution is to give the linker some information, how to work with
.siminfo:
Instead of the changes before I add to line 8 in fred.c:
const unsigned long _test_ __attribute__((section (".siminfo"))) =
0x11223344;
The compile-and-link command:
avr-gcc -g -O2 -mmcu=atmega16 -o fred.elf
-Wl,--section-start=.siminfo=0x90 fred.c
Readelf shows:
> readelf -S fred.elf
Section Headers:
[Nr] Name Type Addr OffSize ES Flg Lk Inf Al
[ 0] NULL 00 00 00 0 0 0
[ 1] .siminfo PROGBITS 0090 0001e2 04 00 A 0 0 1
[ 2] .textPROGBITS 94 f6 00 AX 0 0 2
[ 3] .dataPROGBITS 00800060 00018a 58 00 WA 0 0 1
[ 4] .stabPROGBITS 0001e8 000960 0c 5 0 4
[ 5] .stabstr STRTAB 000b48 00038c 00 0 0 1
[ 6] .shstrtabSTRTAB 000ed4 3f 00 0 0 1
[ 7] .symtab SYMTAB 00107c 000430 10 8 18 4
[ 8] .strtab STRTAB 0014ac 0002d7 00 0 0 1
> readelf -x .siminfo fred.elf
Hex dump of section '.siminfo':
0x0090 44332211D3".
So, it's not a problem at all to create the .siminfo section and link it
together into a elf file.
___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
On Fri, 28 Feb 2014, Klaus Rudolph wrote:
Michael Hennebry schrieb:
I thought the signature had a symbol associated with it.
Could not symbols be used to ascertain the
locations of the data in the section?
One could still have a problem if other tools
do not use the symbol for the signature.
The simplest solution to that might be to always ensure
that the siminfo stuff is always fed to the linker last.
Another solution might be to make this the first input file to avr-ld:
/* first input file. do not use -T */
SECTIONS
{
.siminfo : { KEEP(*(.siminfo)) }
} > signature
If avr-ld will accept a second SECTIONS command,
that will make .siminfo a separate section within the signature memory
space.
I'm pretty sure that there are other solutions
involving multiple links and possibly objcopy.
Maybe my English is to bad to understand, but again:
you simply can read each data for each symbol you want in each section.
That is certainly the preferred method for us.
Why we need a new section? The section must be added to all linker
Other tools might not use __signature .
Anyone know for sure?
They might just use the first 1, 2 or 3 bytes of .signature .
Those might be siminfo bytes instead of signature bytes.
For that matter, if .signature has no signature data, but it has siminfo data,
said data would likely be mistaken for signature data.
scripts which is part of gcc! .signature is already existing and working
and additional content can simply be added by a new source file. It
seems much easier to add a standard extension for siminfo data to avr
libc instead of gcc. And there is no need to add this data to avr libc
but this will make it easier for all users.
But if all people want a new section with a new address range with new
linker scripts with new header files with next compiler version which is
supported by next avr libs... do it :-)
To me, the issue is what we can do without
messing up .signature's use by other tools.
If other tools use __signature , we are in like Flynn.
If not, a separate section might be necessary.
A tool that does not use __signature , but checks the section length,
might do decide that it is not a signature and therefore ignore it.
That would be the wrong thing if .signature
had both signature and siminfo data.
BTW it seems to me that avr/signature.h should be avr/signature.c .
It's clearly not a header file.
Its contents are not used by a file that #includes it.
It should only be used once in an application.
--
Michael henne...@web.cs.ndsu.nodak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Michael Hennebry schrieb:
> On Fri, 28 Feb 2014, ThomasK wrote:
>
>> 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.
>
> I thought the signature had a symbol associated with it.
> Could not symbols be used to ascertain the
> locations of the data in the section?
> One could still have a problem if other tools
> do not use the symbol for the signature.
> The simplest solution to that might be to always ensure
> that the siminfo stuff is always fed to the linker last.
> Another solution might be to make this the first input file to avr-ld:
> /* first input file. do not use -T */
> SECTIONS
> {
> .siminfo : { KEEP(*(.siminfo)) }
> } > signature
>
> If avr-ld will accept a second SECTIONS command,
> that will make .siminfo a separate section within the signature memory
> space.
>
> I'm pretty sure that there are other solutions
> involving multiple links and possibly objcopy.
>
Maybe my English is to bad to understand, but again:
you simply can read each data for each symbol you want in each section.
Why we need a new section? The section must be added to all linker
scripts which is part of gcc! .signature is already existing and working
and additional content can simply be added by a new source file. It
seems much easier to add a standard extension for siminfo data to avr
libc instead of gcc. And there is no need to add this data to avr libc
but this will make it easier for all users.
But if all people want a new section with a new address range with new
linker scripts with new header files with next compiler version which is
supported by next avr libs... do it :-)
Regards
Klaus
___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
On Fri, 28 Feb 2014, ThomasK wrote:
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.
I thought the signature had a symbol associated with it.
Could not symbols be used to ascertain the
locations of the data in the section?
One could still have a problem if other tools
do not use the symbol for the signature.
The simplest solution to that might be to always ensure
that the siminfo stuff is always fed to the linker last.
Another solution might be to make this the first input file to avr-ld:
/* first input file. do not use -T */
SECTIONS
{
.siminfo : { KEEP(*(.siminfo)) }
} > signature
If avr-ld will accept a second SECTIONS command,
that will make .siminfo a separate section within the signature memory space.
I'm pretty sure that there are other solutions
involving multiple links and possibly objcopy.
--
Michael henne...@web.cs.ndsu.nodak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods
___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Am 28.02.2014 13:22, schrieb Klaus Rudolph: > you also can add yourself any kind of data to any kind of section by > simply adding the section to your source code with > __attribute__(section...) Looking at the code, that's what I actually did. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Hi all, > > Seeing the somewhat tricky nature of embedding metadata inside ELF I > thought about other ways to achieve this goal. The result of this > investigation was to extend the configuration file used for signal > tracing. With a dead simple syntax, of course. As the ELF issues appear > now to be solvable universally, I no longer think this is needed. > > There is really nothing difficult or undocumented or mysterious to add data to elf. All you need is to extend the avr libc header file which is no problem and you also can add yourself any kind of data to any kind of section by simply adding the section to your source code with __attribute__(section...). And we have not to use the three signature bytes, we have to ADD! new information's to the section. You can add any kind of data to any kind of section. There is no tricky thing behind the scene. There is nothing a tool must parse, the tool simply reads the elf section, the labels and thats it. It is not necessary to keep any order or to have all information always. Simply add the structures you need to the section and go ahead. Please do not add a new way for already implemented things! Regards Klaus ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Am 28.02.2014 07:19, schrieb ThomasK: > 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! Handling I/O this way is in the best tradition of the Unix concept where you use additional files, pipes and tools for controlling what gets written to a program and when. And what's the difference between hardcoding a file name into the ELF binary vs. hardcoding it in a Phyton script? That said, you can hardcode I/O to stdin/stdout, of course, and connect pipes or redirections to one or both of them. Right from the command line. > Not a realistic scenery. D'oh. It works already. You can use the same host software for driving simulator and real hardware. You even have the same data loss issues as with real hardware, which I consider to be a good thing. > 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! That's actually intentional. Splitting this up would be trivial, but also making things more complicated like in requiring a header for every AVR project. And if you have two files in different projects (SimulAVR and target), these two can become incompatible, of course. SIMINFO doesn't mean to replace scripting. TCL and Python stuff works just as before. Experts, please continue with your favourite flavour of scripting. It means to make simple simulation cases more simple for those those hobbyists who don't do simulations 40 hours a week, 200 days a year. Looking at the bug reports, quite a number of people have tried already, probably because "type this command line, then use the tools you're used to" is a concept they understand. Seeing the somewhat tricky nature of embedding metadata inside ELF I thought about other ways to achieve this goal. The result of this investigation was to extend the configuration file used for signal tracing. With a dead simple syntax, of course. As the ELF issues appear now to be solvable universally, I no longer think this is needed. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
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 mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Michael Hennebry schrieb:
> On Wed, 26 Feb 2014, Markus Hitter wrote:
>
>> Am 26.02.2014 20:31, schrieb Klaus Rudolph:
>> The tricky thing here is to make the linker keeping this section.
>> Typically, code for AVRs is compiled into a binary as small as possible
>> and this also means removing unused sections. So far I couldn't find a
>> linker option to do heavy optimisation _except_ for the .siminfo section.
>
> Isn't that what KEEP in a linker script is for?
Exactly! And there is allready a section for that kind of use:
MEMORY
{
text (rx) : ORIGIN = 0, LENGTH = 8K
data (rw!x) : ORIGIN = 0x800060, LENGTH = 0
eeprom (rw!x) : ORIGIN = 0x81, LENGTH = 64K
fuse (rw!x) : ORIGIN = 0x82, LENGTH = 1K
lock (rw!x) : ORIGIN = 0x83, LENGTH = 1K
signature (rw!x) : ORIGIN = 0x84, LENGTH = 1K
}
The signature section can be used for that. To extend the information
there for the clock frequency etc. is not a problem but must be checked
against other tools which reading these sections.
To write inside this section take a look in
#include
I expect that is no problem to add any needed information behind the
already defined content.
Regards
Klaus
___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Hi all, > The discussion might be moot. Yesterday I tried to rebase on more > recent SimulAVR sources and, unfortunately, it's no longer possible. > A few days ago somebody replaced the entire ELF reading stuff with > something completely different (commit "substitute libbfd and > libiberty, read elf file by ElfIO"), so the SIMINFO mechanism would > have to be rewritten and re-tested from scratch, too. 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 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 to let ElfIO in a development branch. As I know the idea was to remove the dependency for libbfd, but from my point of few this is not really 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 problem?! I have never played with ElfIO, so I can't give there any hint. But I was very comfortable with the libbfd solution. Coming back to the problem regarding the sections of the elf file to place any additional informations in. The question is not, if partial linking is provided or not. The information will be linked in the target files if the linker script has a section for that purpose. 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. But maybe I am on the wrong track?! Regards Klaus ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
On Wed, 26 Feb 2014, Markus Hitter wrote: Am 26.02.2014 20:31, schrieb Klaus Rudolph: The tricky thing here is to make the linker keeping this section. Typically, code for AVRs is compiled into a binary as small as possible and this also means removing unused sections. So far I couldn't find a linker option to do heavy optimisation _except_ for the .siminfo section. Isn't that what KEEP in a linker script is for? -- Michael henne...@web.cs.ndsu.nodak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
The discussion might be moot. Yesterday I tried to rebase on more recent SimulAVR sources and, unfortunately, it's no longer possible. A few days ago somebody replaced the entire ELF reading stuff with something completely different (commit "substitute libbfd and libiberty, read elf file by ElfIO"), so the SIMINFO mechanism would have to be rewritten and re-tested from scratch, too. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
On Wed, Feb 26, 2014 at 2:03 PM, Markus Hitter wrote: > The tricky thing here is to make the linker keeping this section. > Typically, code for AVRs is compiled into a binary as small as possible > and this also means removing unused sections. So far I couldn't find a > linker option to do heavy optimisation _except_ for the .siminfo section. Does the AVR version of ld support partial linking? You can try partially linking just normal code/data with optimization, then call ld again to link in .siminfo with no optimizations this time. ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Am 26.02.2014 20:31, schrieb Klaus Rudolph: > If this information will be written to any non text or data section it > seems ok. To add any kind of meta data section like debug and config > sections to an elf file can not disturb any other feature, so I think it > is a good way. The tricky thing here is to make the linker keeping this section. Typically, code for AVRs is compiled into a binary as small as possible and this also means removing unused sections. So far I couldn't find a linker option to do heavy optimisation _except_ for the .siminfo section. > But I personally want to overwrite the informations from the elf file by > config options on the command line. Maybe I want a different clock > frequency or maybe a smaller controller. This MUST be possible without > rebuilding the elf file. As is, command line options, if existing, always take precedence over stuff in the .siminfo section, so this part should be solved. Markus -- - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
Re: [Simulavr-devel] Discussion: siminfo feature as proposed by Markus Hitter
Hi all, > http://savannah.nongnu.org/bugs/?40594 and Markus repo with this feature > on https://github.com/Traumflug/simulavr) I have not looked in the sources until now. > > What does it do? In a similar way as avr signature it's possible to link > into elf file some mor information about the program and how to simulate > this. The idea comes from simavr: https://gitorious.org/simavr. > > The information are: > > - controller name (e.g. "atmega32") > - clock frequency > - serial input from file and serial output to file > - simavr holds too VCD configuration, tracefile, core voltage > - ... there are many more thing, which **could** be hold there > If this information will be written to any non text or data section it seems ok. To add any kind of meta data section like debug and config sections to an elf file can not disturb any other feature, so I think it is a good way. But I personally want to overwrite the informations from the elf file by config options on the command line. Maybe I want a different clock frequency or maybe a smaller controller. This MUST be possible without rebuilding the elf file. Simply the information can be read out from elf and if any options are on the command line they overwrite the infos from file. If so: Do it :-) Regards Klaus ___ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel
