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

[Michael Hennebry]

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   address@hidden
"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