On Wed, Aug 26, 2015 at 09:07:23AM +0200, Ingo Molnar wrote:
>
> * Josh Poimboeuf <jpoim...@redhat.com> 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 linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
