Ori, simply, end-to-beginning when moving up. Or always end-to-beginning since we are expected to always move up (upper than the target address it can't run).
Since the 'issue' is caused by the code assuming one direction, I'd prefer it not to assume the other now; I prefer choosing end-to-beginning if target is dest than source, beginning-to-end otherwise.
but the calculation is done to move to end of ram, so dest is always higher than source.
Actually no, copying and fixing is not done in a single run. There is the copying of the text+data+const area, then the fixing which runs through the relocation table area; they are different.
Yes, that's what I meant. It's not a memcpy, you also use the data after the copy so any overlap is an issue, indepentend of the order of copying.
Or, easier: if we are already high enough to overlap, don't relocate at all. If it's acceptable, I'll patch for taht.
But then comes the question of how enough is "high enough". :)
If there's no overlap, you can relocate. If the areas overal, you keep the current address which also is "high enough".
If you ack (even offlist) I'll submit a patch tomorrow (monday) /alessandro