Hi Mark, Thanks for review! On 2022/6/30 1:47, Mark Brown wrote: > On Thu, Jun 23, 2022 at 09:49:02AM +0800, Chen Zhongjin wrote: >> Code symbols not following the aarch64 procedure call convention should >> be annotated with SYM_CODE_* instead of SYM_FUNC_* >> >> Mark relevant symbols as generic code symbols. > >> -SYM_CODE_START(tramp_exit_native) >> +SYM_CODE_START_LOCAL(tramp_exit_native) >> tramp_exit >> SYM_CODE_END(tramp_exit_native) >> >> -SYM_CODE_START(tramp_exit_compat) >> +SYM_CODE_START_LOCAL(tramp_exit_compat) > > The commit log says this is fixing things mistakenly lablelld SYM_FUNC > but this bit of the actual change is making some symbols local. > It makes sense. I'll remove this because whether this symbol is global makes few difference here. >> -SYM_FUNC_START_LOCAL(__create_page_tables) >> +SYM_CODE_START_LOCAL(__create_page_tables) >> mov x28, lr >> >> /* >> @@ -389,7 +389,7 @@ SYM_FUNC_START_LOCAL(__create_page_tables) >> bl dcache_inval_poc >> >> ret x28 >> -SYM_FUNC_END(__create_page_tables) >> +SYM_CODE_END(__create_page_tables) > > This is removed by Ard's recent refactoring, the others that are still > present look valid enough (for things that don't use the stack IIRC they > could be seen as conforming but equally this is all running in non > standard environments). You are right, for SYM_CODE_, objtool won't generate ORC automatically as other normal functions, unless UNWIND_HINT is explicitly specified for non-standard stack frames.
