From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934834AbaEFLDg (ORCPT ); Tue, 6 May 2014 07:03:36 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:43447 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934579AbaEFLDa (ORCPT ); Tue, 6 May 2014 07:03:30 -0400 Date: Tue, 6 May 2014 13:03:24 +0200 From: Pavel Machek To: Jiri Slaby Cc: linux-kernel@vger.kernel.org, jirislaby@gmail.com, Vojtech Pavlik , Michael Matz , Jiri Kosina Subject: Re: [RFC 12/16] kgr: add tools Message-ID: <20140506110324.GC15033@xo-6d-61-c0.localdomain> References: <1398868249-26169-1-git-send-email-jslaby@suse.cz> <1398868249-26169-13-git-send-email-jslaby@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1398868249-26169-13-git-send-email-jslaby@suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Cc: Michael Matz > 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