All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.