On 27 December 2014 at 15:35, Alexey Brodkin <alexey.brod...@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 <abrod...@synopsys.com> > Cc: Simon Glass <s...@chromium.org> > Cc: Minkyu Kang <mk7.k...@samsung.com> > --- > lib/initcall.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Simon Glass <s...@chromium.org> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot