From: Adrian Bunk <bunk@kernel.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
Franck Bui-Huu <vagabon.xyz@gmail.com>,
linux-arch@vger.kernel.org, linux-mips@linux-mips.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Discardable strings for init and exit sections
Date: Fri, 12 Oct 2007 20:15:44 +0200 [thread overview]
Message-ID: <20071012181544.GC6476@stusta.de> (raw)
In-Reply-To: <20071012175209.GA1110@linux-mips.org>
On Fri, Oct 12, 2007 at 06:52:10PM +0100, Ralf Baechle wrote:
> On Fri, Oct 12, 2007 at 07:19:38PM +0200, Adrian Bunk wrote:
>
> > I have an objection against this approach:
> >
> > Our __*init*/__*exit* annotations are already a constant source of bugs,
> > and adding more pifalls (e.g. forgotten removal of _i()/_e() when a
> > function is no longer __*init*/__*exit*) doesn't sound like a good plan.
> >
> > Shouldn't it be possible to automatically determine where to put the
> > strings? I don't know enough gcc/ld voodoo for being able to tell
> > whether it is currently possible, and if yes how, but doing it
> > automatically sounds like the only solution that wouldn't result in an
> > unmaintainable mess.
>
> gcc tends to place data such as strings or jump tables generated from
> switches not into a place were it would be easily discardable. The
> latter is the reason that on MIPS we can't discard __exit functions
> at all - a switch table in .rodata might be referencing discarded code
> in .exit.text which makes ld fail. When I discussed this with some gcc
> people a while ago nobody really had a good suggestion to solve this.
- Most of the string annotations are (naturally) dev{init,exit}
annotations, and bugs there are therefore in configurations that have
only extremely low testing coverage during -rc.
- I'm counting 22 annotations in the driver Maciej converted as an
example. When estimating the number of possible annotations based
on the number of C files in the kernel I'm getting a six digit
number.
No matter how hard it would be to teach gcc about it, when thinking of
the amount of __*init*/__*exit* bugs we already have I simply can't
imagine the string annotations as a maintainable solution.
> Ralf
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
next prev parent reply other threads:[~2007-10-12 18:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-12 16:50 [PATCH] Discardable strings for init and exit sections Maciej W. Rozycki
2007-10-12 17:19 ` Adrian Bunk
2007-10-12 17:52 ` Ralf Baechle
2007-10-12 18:15 ` Adrian Bunk [this message]
2007-10-23 16:57 ` Maciej W. Rozycki
2007-10-23 17:12 ` Adrian Bunk
2007-10-23 17:25 ` Sam Ravnborg
2007-10-12 17:45 ` Sam Ravnborg
2007-10-23 17:23 ` Maciej W. Rozycki
2007-10-23 17:27 ` Sam Ravnborg
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=20071012181544.GC6476@stusta.de \
--to=bunk@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=macro@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=vagabon.xyz@gmail.com \
/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.