This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: NOLOAD, s-record and other questions
- From: Nick Clifton <nickc at redhat dot com>
- To: massimiliano cialdi <cialdi at gmail dot com>
- Cc: binutils at sources dot redhat dot com
- Date: Wed, 02 Feb 2005 10:50:22 +0000
- Subject: Re: NOLOAD, s-record and other questions
- References: <17201dc705013113595058cabe@mail.gmail.com>
Hi Massimiliano,
using NOLOAD the external-ram addresses are no longer present in mot
file (and I think in the elf too), but I wonder if the NOLOAD has some
unwanted side effect.
It depends upon what you mean by "unwanted". Any section with the
NOLOAD qualifier will not have the ALLOCATE attribute set, which means
that the program loader will not allocate memory space for that section,
nor load it from the file when the program is started. (This is why
your .external section has no contents in the srec file - the elf to
srec conversion has determined that the .external section does not
contribute to the in-memory image of the running program and so has
skipped it).
I also found in the documentation the /DISCARD/ section name
http://sources.redhat.com/binutils/docs-2.15/ld/Output-Section-Discarding.html#Output%20Section%20Discarding
but there is no example.
How is used and what are the effects of /DISCARD/ section name?
If you have a look in the linker sources you will find examples of the
/DISCARD/ section name being used. eg in ld/scripttempl/pe.sc:
/DISCARD/ :
{
*(.debug\$S)
*(.debug\$T)
*(.debug\$F)
*(.drectve)
}
Its affects are documented in the linker documentation which you have
already quoted. Basically it means that any input sections which are
assigned to the output section with the /DISCARD/ name will be ignored
when the final executable is generated. So for example in the linker
script fragment above any section named .drectve or .debug$S or .debug$T
or .debug$F in any input file given to the linker will be ignored and
not copied into the output file.
finally: I wonder if mot file produced from elf with obj-copy, could
have the addresses in the s1 or s2 record without an order.
All my mot file are sorted.
Since I'm writing an s-record file interpreter to program the micro
flash, I need to know if the s-record file specifications allows the
unsorted records s1, s2 or s3.
The specification does allow for unsorted records. This is mentioned at
the start of the bfd/srec.c file:
The only interesting thing is that S-Records may come out of
order and there is no header, so an initial scan is required
to discover the minimum and maximum addresses used to create
the vma and size of the only section we create.
Cheers
Nick