public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: Marcelo Tosatti <marcelo@kvack.org>
Cc: binutils@sources.redhat.com
Subject: Re: [binutils patch]: -print-gc-sections option: print garbage collected sections
Date: Fri, 07 Jul 2006 22:21:00 -0000	[thread overview]
Message-ID: <20060707222120.GA29900@lucon.org> (raw)
In-Reply-To: <20060701231428.GA23415@dmt>

I am forwarding it to the binutils mailing list.


H.J.
On Sat, Jul 01, 2006 at 08:14:28PM -0300, Marcelo Tosatti wrote:
> Hi H.J.Lu,
> 
> I have been working on a Linux kernel patch to use -gc-sections option
> along with -ffunction-sections to waste unused functions (which are
> pretty common in the kernel due to the many possible configuration).
> 
> http://lkml.org/lkml/2006/6/4/169
> 
> I came up with the need to be informed about what sections ld is
> removing, so I added the followed option: -print-gc-sections.
> 
> The other possible way to know which sections are dumped is to two
> images: once with "gc-sections", once without, and compare. Which is
> rather dumb.
> 
> Do you think its good for inclusion or it would be better to specify a
> file instead of printing to stdout?
> 
> Against recent binutils...
> 
> --- ./ld/ldmain.c.orig	2006-05-21 17:18:46.000000000 -0300
> +++ ./ld/ldmain.c	2006-05-21 17:18:55.000000000 -0300
> @@ -316,6 +316,7 @@ main (int argc, char **argv)
>    link_info.relax_pass = 1;
>    link_info.warn_shared_textrel = FALSE;
>    link_info.gc_sections = FALSE;
> +  link_info.print_gc_sections = FALSE;
>  
>    ldfile_add_arch ("");
>  
> --- ./ld/lexsup.c.orig	2006-05-21 17:06:21.000000000 -0300
> +++ ./ld/lexsup.c	2006-05-21 17:18:27.000000000 -0300
> @@ -124,6 +124,7 @@ enum option_values
>    OPTION_FORCE_EXE_SUFFIX,
>    OPTION_GC_SECTIONS,
>    OPTION_NO_GC_SECTIONS,
> +  OPTION_PRINT_GC_SECTIONS,
>    OPTION_HASH_SIZE,
>    OPTION_CHECK_SECTIONS,
>    OPTION_NO_CHECK_SECTIONS,
> @@ -370,6 +371,9 @@ static const struct ld_option ld_options
>    { {"no-gc-sections", no_argument, NULL, OPTION_NO_GC_SECTIONS},
>      '\0', NULL, N_("Don't remove unused sections (default)"),
>      TWO_DASHES },
> +  { {"print-gc-sections", no_argument, NULL, OPTION_PRINT_GC_SECTIONS},
> +    '\0', NULL, N_("Print removed unused sections"),
> +    TWO_DASHES },
>    { {"hash-size=<NUMBER>", required_argument, NULL, OPTION_HASH_SIZE},
>      '\0', NULL, N_("Set default hash table size close to <NUMBER>"),
>      TWO_DASHES },
> @@ -812,6 +816,9 @@ parse_args (unsigned argc, char **argv)
>  	case OPTION_GC_SECTIONS:
>  	  link_info.gc_sections = TRUE;
>  	  break;
> +	case OPTION_PRINT_GC_SECTIONS:
> +	  link_info.print_gc_sections = TRUE;
> +	  break;
>  	case OPTION_HELP:
>  	  help ();
>  	  xexit (0);
> --- ./include/bfdlink.h.orig	2006-05-21 17:16:54.000000000 -0300
> +++ ./include/bfdlink.h	2006-05-21 17:17:21.000000000 -0300
> @@ -324,6 +324,9 @@ struct bfd_link_info
>    /* TRUE if unreferenced sections should be removed.  */
>    unsigned int gc_sections: 1;
>  
> +  /* TRUE if should print removed unreferenced sections. */
> +  unsigned int print_gc_sections: 1;
> +
>    /* What to do with unresolved symbols in an object file.
>       When producing executables the default is GENERATE_ERROR.
>       When producing shared libraries the default is IGNORE.  The
> --- ./bfd/elflink.c.orig	2006-05-21 17:20:57.000000000 -0300
> +++ ./bfd/elflink.c	2006-05-21 18:41:19.000000000 -0300
> @@ -8978,6 +8978,9 @@ elf_gc_sweep (bfd *abfd, struct bfd_link
>  	     to remove a section from the output.  */
>  	  o->flags |= SEC_EXCLUDE;
>  
> +	  if (info->print_gc_sections == TRUE)
> +		printf("%s:%s\n", sub->filename, o->name);
> +
>  	  /* But we also have to update some of the relocation
>  	     info we collected before.  */
>  	  if (gc_sweep_hook

       reply	other threads:[~2006-07-07 22:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060701231428.GA23415@dmt>
2006-07-07 22:21 ` H. J. Lu [this message]
2006-08-04 14:50   ` Nick Clifton

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=20060707222120.GA29900@lucon.org \
    --to=hjl@lucon.org \
    --cc=binutils@sources.redhat.com \
    --cc=marcelo@kvack.org \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).