On Wed, Aug 26, 2015 at 09:07:23AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > BTW, since I'm planning on adding a CFI generation option to this tool, I wonder > > if "stackvalidate" is a misnomer. I can't think of anything better. Any naming > > ideas are welcome :-) > > I'd suggest 'debuginfo' and a Git-alike set of subcommands: > > debuginfo help > debuginfo check > debuginfo check framepointers > debuginfo check cfi > > Such a command scheme keeps open various future commands, such as: > > debuginfo show > debuginfo size > debuginfo compress > debuginfo strip > > etc. > > I also checked that there does not appear to be such a Linux tool with such a name > at the moment. My feeling is that the subcommand model wouldn't fit this tool very well. Its core functionality is to analyze code paths -- which it does in a single pass, regardless of whether it's checking frame pointers, checking CFI, generating CFI, or some combination. Splitting it up into subcommands would mean having to repeat the same code analysis pass multiple times unnecessarily. Also, since it's really focused on stack-related code path analysis, I wouldn't expect it to be branching out into other debuginfo-related tasks. As far as naming goes, "debuginfo" usually refers to DWARF metadata. But this tool isn't DWARF-specific, so that would be confusing IMO. I also agree with Jiri that re-using a generic name which already has another meaning would add to the confusion. The goal of this tool is to fix stack traces, so how about "stackfix"? usage: stackfix [options] <file.o> -f, --frame-pointers Validate frame pointer usage -c, --cfi Validate CFI if it exists -g, --cfi-gen Generate CFI if it doesn't already exist The options could all be combinable. -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html