On Mon, Jan 28, 2013 at 04:23:37PM +0000, David Woodhouse wrote:
From: David Woodhouse David.Woodhouse@intel.com
Not-yet-signed-off-by: David Woodhouse David.Woodhouse@intel.com
src/post.c | 10 +++++----- src/post.h | 11 +++++++++++ 2 files changed, 16 insertions(+), 5 deletions(-) create mode 100644 src/post.h
diff --git a/src/post.c b/src/post.c index dbf4944..b53f1eb 100644 --- a/src/post.c +++ b/src/post.c @@ -158,7 +158,7 @@ bda_init(void) StackPos = (void*)(&ExtraStack[BUILD_EXTRA_STACK_SIZE] - datalow_base); }
-static void +void VISIBLE32INIT
The sprinkling of VISIBLE32INIT is non-optimal and pretty ugly. Ideally, only handle_elf_post(), handle_post(), and handle_csm32() would have this flag. Then the build would automatically propagate the flag to all functions and data only reachable via one of these entry points.
Unfortunately, the CSM has to return back to UEFI from the init code and that complicates the implementation. The init code is running at one address prior to relocation and at another address after relocation - when unwinding the call stack to return to UEFI the code pointers on the stack could have a mix of old and new init code locations. That's going to be complex and error prone. Patch 1 of this series avoids that by making sure that reloc_preinit() and maininit() are only called from non-init code - thus ensuring a sane return path. However, it leads to the sprinkling of VISIBLE32INIT definitions.
I'm not sure how to best address this. One way is to go forward and sprinkle VISIBLE32INIT. Another way would be to revert patch 1, pass a function pointer to reloc_preinit() instead of hard-coding maininit, and teach the CSM code how to "longjmp" back to UEFI after relocation so it doesn't have to unwind the stack. I'm not sure that would be any less "ugly" though.
Any other ideas?
-Kevin