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
next parent 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).