linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jiri Slaby <jslaby@suse.cz>
Cc: linux-kernel@vger.kernel.org, jirislaby@gmail.com,
	Vojtech Pavlik <vojtech@suse.cz>, Michael Matz <matz@suse.de>,
	Jiri Kosina <jkosina@suse.cz>
Subject: Re: [RFC 12/16] kgr: add tools
Date: Tue, 6 May 2014 13:03:24 +0200	[thread overview]
Message-ID: <20140506110324.GC15033@xo-6d-61-c0.localdomain> (raw)
In-Reply-To: <1398868249-26169-13-git-send-email-jslaby@suse.cz>

On Wed 2014-04-30 16:30:45, Jiri Slaby wrote:
> These are a base which can be used for kgraft patch generation.
> 
> The code was provided by Michael

Should Michael Matz sign it off, then?

> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Michael Matz <matz@suse.de>

>  tools/kgraft/app.c               |   35 +
>  tools/kgraft/app.h               |    7 +

The app is just a dummy to test this on?

> +	./dwarf-inline-tree app.o
> +	@echo "inline pairs"
> +	./dwarf-inline-tree app.o | perl it2rev.pl
> +	@echo "extract stuff"
> +	./objcopy-hacked --strip-unneeded -j .doesntexist. --keep-symbols symlist app.o app-extract.o

Instead of providing local copy of objcopy, should some patch be pushed to FSF?

> +will build most of them, and the check target contains example invocations.
> +The only thing not built automatically is the hacked objcopy (objcopy-hacked),
> +as usually the necessary binutils headers aren't installed.  You'll
> +have to have (recent) binutils sources, apply the patch objcopy.diff
> +and build it yourself.

Ok, I think it should.

> +The seeding symbol list currently needs to come from a human.  It's probably
> +feasible to generate that list for most cases by interpreting a kernel
> +diff.  Binary comparison should _not_ be used to generate it.

And then we reach singularity, because computers will now be able to program
themselves? :-).


> +int global_data;
> +
> +static void __attribute__((noinline)) in_app (void)

in_app(.

> +int main ()

main(int argc, int argv[])

And add a comment that this is dummy app for objdump testing?

> +{
> +  in_app_global();
> +  second_file ();

file(.

> @@ -0,0 +1,7 @@
> +static inline void __attribute__((always_inline)) in_app_inline (void)
> +{
> +  static int local_static_data;
> +  printf ("in_app_inline: %d\n", local_static_data++);
> +}
> +
> +void second_file (void);

Some more spaces before ( need to be deleted.


> +static int __init kgr_patcher_init(void)
> +{
> +        /* removing not supported (yet?) */
> +        __module_get(THIS_MODULE);
> +        /* +4 to skip push rbb / mov rsp,rbp prologue */

What +4 ?

> --- /dev/null
> +++ b/tools/kgraft/dwarf-inline-tree.c
> @@ -0,0 +1,544 @@

GPL, authors would be cool here.


> +#define string char*
> +#include "dwarf_names.h"
> +#undef string

Ouch.

> +    attrib = attr_in;
> +    atname = get_AT_name(dbg, attr);
> +
> +    tres = dwarf_whatform (attrib, &form, &err);
> +    if (tres != DW_DLV_OK)
> +	print_error (dbg, "dwarf_whatform", tres, err);
> +    printf("\t\t%-28s%s\t", atname, get_FORM_name (dbg, form));
> +    /* Don't move over the attributes for the top-level compile_unit
> +     * DIEs.  */
> +    if (tag == DW_TAG_compile_unit)
> +      {
> +	printf ("\n");
> +	return;
> +      }

Is this inherited from GNU code?

> +	case DW_AT_allocated:
> +		if (ellipsis)
> +			return "allocated";
> +		else
> +			return "DW_AT_allocated";
> +	case DW_AT_associated:
> +		if (ellipsis)
> +			return "associated";
> +		else
> +			return "DW_AT_associated";

I have strong feeling that this code is autogenerated, or should be autogenerated. Not 
suitable for kernel git.

Also I believe patch for objdump is best reviewed at GNU mailing lists, and not suitable
for kernel git.

Best regards,
										Pavel

  reply	other threads:[~2014-05-06 11:03 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-30 14:30 [RFC 00/16] kGraft Jiri Slaby
2014-04-30 14:30 ` [RFC 01/16] ftrace: Add function to find fentry of function Jiri Slaby
2014-04-30 14:48   ` Steven Rostedt
2014-04-30 14:58     ` Jiri Slaby
2014-04-30 14:30 ` [RFC 02/16] ftrace: Make ftrace_is_dead available globally Jiri Slaby
2014-04-30 14:30 ` [RFC 03/16] kgr: initial code Jiri Slaby
2014-04-30 14:56   ` Steven Rostedt
2014-04-30 14:57     ` Jiri Slaby
2014-05-01 20:20   ` Andi Kleen
2014-05-01 20:37     ` Jiri Kosina
2014-05-14  9:28   ` Aravinda Prasad
2014-05-14 10:12     ` Jiri Slaby
2014-05-14 10:41       ` Aravinda Prasad
2014-05-14 10:44         ` Jiri Slaby
2014-05-14 11:19           ` Aravinda Prasad
2014-05-20 11:36     ` Jiri Slaby
2014-05-21 18:28       ` Aravinda Prasad
2014-05-26  8:50       ` Jiri Kosina
2014-04-30 14:30 ` [RFC 04/16] kgr: add testing kgraft patch Jiri Slaby
2014-05-06 11:03   ` Pavel Machek
2014-05-12 12:50     ` Jiri Slaby
2014-04-30 14:30 ` [RFC 05/16] kgr: update Kconfig documentation Jiri Slaby
2014-05-03 14:32   ` Randy Dunlap
2014-04-30 14:30 ` [RFC 06/16] kgr: add Documentation Jiri Slaby
2014-05-06 11:03   ` Pavel Machek
2014-05-09  9:31     ` kgr: dealing with optimalizations? (was Re: [RFC 06/16] kgr: add Documentat)ion Pavel Machek
2014-05-09 12:22       ` Michael Matz
2014-04-30 14:30 ` [RFC 07/16] kgr: trigger the first check earlier Jiri Slaby
2014-04-30 14:30 ` [RFC 08/16] kgr: sched.h, introduce kgr_task_safe helper Jiri Slaby
2014-04-30 14:30 ` [RFC 09/16] kgr: mark task_safe in some kthreads Jiri Slaby
2014-04-30 15:49   ` Greg Kroah-Hartman
2014-04-30 16:55   ` Paul E. McKenney
2014-04-30 18:33     ` Vojtech Pavlik
2014-04-30 19:07       ` Paul E. McKenney
2014-05-01 14:24   ` Tejun Heo
2014-05-01 20:17     ` Jiri Kosina
2014-05-01 21:02       ` Tejun Heo
2014-05-01 21:09         ` Tejun Heo
2014-05-14 14:59           ` Jiri Slaby
2014-05-14 15:15             ` Vojtech Pavlik
2014-05-14 15:30               ` Paul E. McKenney
2014-05-14 16:32               ` Tejun Heo
2014-05-15  3:53                 ` Mike Galbraith
2014-05-15  4:06                   ` Tejun Heo
2014-05-15  4:46                     ` Mike Galbraith
2014-05-15  4:50                       ` Tejun Heo
2014-05-15  5:04                         ` Mike Galbraith
2014-05-15  5:09                           ` Tejun Heo
2014-05-15  5:32                             ` Mike Galbraith
2014-05-15  6:05                               ` Tejun Heo
2014-05-15  6:32                                 ` Mike Galbraith
2014-04-30 14:30 ` [RFC 10/16] kgr: kthreads support Jiri Slaby
2014-04-30 14:30 ` [RFC 11/16] kgr: handle irqs Jiri Slaby
2014-04-30 14:30 ` [RFC 12/16] kgr: add tools Jiri Slaby
2014-05-06 11:03   ` Pavel Machek [this message]
2014-04-30 14:30 ` [RFC 13/16] kgr: add MAINTAINERS entry Jiri Slaby
2014-04-30 14:30 ` [RFC 14/16] kgr: x86: refuse to build without fentry support Jiri Slaby
2014-04-30 14:30 ` [RFC 15/16] kgr: add procfs interface for per-process 'kgr_in_progress' Jiri Slaby
2014-04-30 14:30 ` [RFC 16/16] kgr: make a per-process 'in progress' flag a single bit Jiri Slaby

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140506110324.GC15033@xo-6d-61-c0.localdomain \
    --to=pavel@ucw.cz \
    --cc=jirislaby@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matz@suse.de \
    --cc=vojtech@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).