On Mo, Aug 24, 2015 at 10:53:24 -0600, Martin Sebor wrote:
> >/* Define a symbol to mark the start of the code region we need to copy.
> > */
> >static void clone_region_start (void)
> >{
> >}
> ...
> >/* Define a symbol to mark the end of the code region we need to copy.
> > */
> >static void clone_region_end (void)
> >{
> >}
[ ... ]
> These computations assume the symbols in the program image will
> be emitted in the same order as those in the source file. That's
> not a safe assumption since neither the compiler nor the linker
> guarantee any particular order of symbols. IIRC, in my last job,
> I saw the same assumption break after switching from gcc 4.2 to
> 4.5 and binutils 2.18 to 2.21.
I think you're right.
I already had this suspect when I originally stumbled over this
problem. At that time, I upgraded from gcc-3.4.0/binutils-2.16 to
gcc-4.4.3/binutils-2.20. So this matches the version range you mention.
If the functions are reordered, chances are that clone_region_start and
clone_region_end would span not all of the required functions and the
consequence would be that not all of the required code would be copied to RAM
and non-existing code would be called eventually.
So the question is: how can I ensure the ordering of the functions?
Am I really the first one to upgrade a running system this way? How have other
people solved this problem?
--
Josef Wolf
jw@xxxxxxxxxxxxx
