On 27 December 2014 at 15:35, Alexey Brodkin Alexey.Brodkin@synopsys.com wrote:
Commit "initcall: Improve debugging support" makes sense and indeed simplifies process of matching initcalls executed with static disassembly.
Until you are debugging relocation functionality.
Existign output may make you think that at some point execution somehow returned back to non-relocated area. And there're many reasons/problems that may provoke this behavior.
In order to make things clear let's add explicit mention in case initall was actually relocated like this: --->--- initcall: 810015f8 Relocation Offset is: 0efcf000 Relocating to 8ffcf000, new gd at 8fdced3c, sp at 8fdced20 initcall: 810015b8 initcall: 8ffd093c initcall: 8ffd0a14 initcall: 81001940 (relocated to 8ffd0940) initcall: 81001958 (relocated to 8ffd0958) --->---
Note "unexpected" jump from 0x8f... area to 0x81... area. Without explanation this raises many questions: execution jumped in relocated area right as expected and then for some reason returned back?
But I hope comment in brackets will save some time for those curious developers who are careful enough to catch "unexpected jump to pre-reloc area" or those unlucky ones who'll have to deal with relocation debugging.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Cc: Simon Glass sjg@chromium.org Cc: Minkyu Kang mk7.kang@samsung.com
lib/initcall.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org