On Thu, Mar 23, 2017 at 08:38:20AM +0100, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > On Wed, Mar 22, 2017 at 08:46:16AM +0100, Ingo Molnar wrote: > > > > > > * Jiri Slaby <jsl...@suse.cz> wrote: > > > > > > > On 03/22/2017, 08:25 AM, Ingo Molnar wrote: > > > > > > > > > > * Pavel Machek <pa...@ucw.cz> wrote: > > > > > > > > > >> Hi! > > > > >> > > > > >>> -ENTRY(saved_rbp) .quad 0 > > > > >>> -ENTRY(saved_rsi) .quad 0 > > > > >>> -ENTRY(saved_rdi) .quad 0 > > > > >>> -ENTRY(saved_rbx) .quad 0 > > > > >>> +SYM_DATA_START(saved_rbp) .quad 0 > > > > >>> +SYM_DATA_START(saved_rsi) .quad 0 > > > > >>> +SYM_DATA_START(saved_rdi) .quad 0 > > > > >>> +SYM_DATA_START(saved_rbx) .quad 0 > > > > >> > > > > >> Does it make sense to call it SYM_DATA_*START* when there's no > > > > >> corresponding end? > > > > > > > > > > That looks like a bug - I think we should strive for them to always > > > > > be in pairs. > > > > > > > > > > Jiri, Josh, could objtool help here perhaps, to detect > > > > > 'non-terminated' > > > > > SYM_*_START() uses? This could be done by emitting debug data into a > > > > > special > > > > > section and then analyzing that section for unpaired entries. The > > > > > section can be > > > > > discarded in the final link, it won't show up in the kernel image. > > > > > > > > It should be easier than that. No introduction of other info needed -- > > > > every global symbol without a ".type" or ".size" (i.e. SYM_*_END) should > > > > be a bug now. > > > > > > I'm all for that! > > > > It would be easy to add this checking to objtool since it already reads > > the symbol table. The hard part is figuring out the logistics. :-) > > > > - Should the warnings be on by default? > > Yes, if objtool is running. Keep it simple. > > > - Part of the "objtool check" command or something else? > > Yes - I think it's still within the 'object file check' functionality. > > > - Separate config option or just include it with > > CONFIG_STACK_VALIDATION? > > Yeah, but I'd rename CONFIG_STACK_VALIDATION to CONFIG_OBJ_VALIDATION or > such. As > I predicted early on, objtool will go beyond stack checking! ;-) > > > - Should all asm files be checked, including those currently skipped by > > objtool with OBJECT_FILES_NON_STANDARD? > > The symbol syntax check should definitely be for all files, yes.
That all sounds reasonable. I'll work something up. > Could we perhaps emit 'non-standard stack frames' information into the .o > itself > (via a flag or a special section?), so that objtool can decide on its own > whether > to complain about any weirdnesses there? For the OBJECT_FILES_NON_STANDARD case, where the whole file is "special", we can just provide a flag to "objtool check" to tell it to skip stack checking for that file, but still do the symbol checks. > > > Can we detect double ends as well - i.e. do a build check of the full > > > syntax of > > > these symbol definition primitives? > > > > Detecting double ends would be a little trickier. The second SYM_*_END > > supersedes the first, so that information isn't in the ELF symbol table. > > Indeed. > > > We could use a special section to annotate all the macro uses and have > > objtool do the checking, similar to what you suggested earlier. > > That might be useful for other purposes as well - such as the non-standard > stack > frame annotations? To start with we can try going without all the special sections (other than the SYM_END double end check). If we end up finding another case which isn't covered then we can always add the special sections later. -- Josh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel