On Wed, Oct 16, 2019 at 12:18:15PM -0600, Martin Sebor wrote:
[ ... ]
> > extern unsigned long _sidata; /* Set by the linker */
> > extern unsigned long _sdata; /* Set by the linker */
> > extern unsigned long _sbss; /* Set by the linker */
> > extern unsigned long _ebss; /* Set by the linker */
> > void Reset_Handler (void)
> > {
> > unsigned long *src = &_sidata
> > unsigned long *dst = &_sdata
> >
> > /* Copy data segment into RAM */
> > if (src != dst) {
> > while (dst < &_edata)
> > *(dst++) = *(src++);
> > }
> >
> > /* Zero BSS segment */
> > dst = &_sbss;
> > while (dst < &_ebss)
> > *(dst++) = 0;
> >
> > main();
> > }
> GCC doesn't issue a warning for this bug yet but it might in
> the future. To avoid the undefined behavior and future
> warnings, convert the addresses to uintptr_t first and compare
> those instead.
I still have a hard time to fully understand this one.
_sbss and friends are symbols defined by the linker. They are never ever used
to store any data. They are only used to get their addresses. Therefore, it
should not matter which data type they have, as long as alignment requirements
are met.
I am using "unsigned long" here because this is convenient for
copying/deleting the sections. Why would a pointer to "unsigned long" be
insufficient to point a an array of "unsigned long"?
Given the fact that there is no way to communicate the length of a section
from the linker to the runtime, this is the most clean code I can think of.
What am I missing here?
--
Josef Wolf
jw@xxxxxxxxxxxxx
