[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data
On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote: > On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote: >> This is a start of series to cleanup macros used for starting functions, >> data, globals etc. across x86. When we have all this sorted out, this >> will help to inject DWARF unwinding info by objtool later. >> >> The goal is forcing SYM_FUNC_START to emit .cfi_startproc and >> SYM_FUNC_END to emit .cfi_endproc. Automatically at best. > > Do we still want to emit .cfi_startproc/endproc from the macro? From > our last discussion, that seemed to be up in the air. > > https://lkml.kernel.org/r/20170217211804.j6l2d7t5mfzqzmbt@treble "Automatically at best" above means "completely from objtool". I am still uncertain whether it will work 100% or we would have to help by generating some pieces from the added macros. In particular, the ALIASes are evil which cause harm here: fun_alias: fun: <code> .size fun, .-fun .type fun STT_FUNC .size fun_alias, .-fun_alias .type fun_alias STT_FUNC Both cannot create (overlapping) .cfi_startproc/endproc, only the inner shall. But it seems so far, that we might be able to deal with all of that from objtool... (I have not been thinking about this particular thing deep enough yet.) Some sort of "from the last label that is marked as STT_FUNC till its .size" might work. > What did you think about making CFI read-only for .c object files and > write-only for .S object files? There are those functions like sync_core() or native_save_fl() with inline asm. And they seem to need a) read-write support, or b) manual annotation. I would like to avoid b) for sure. thanks, -- js suse labs _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |