public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH] x86: clean up vdso-layout.lds.S
Date: Tue,  9 Jun 2009 00:52:47 -0700 (PDT)	[thread overview]
Message-ID: <20090609075247.DA95CFC3B2@magilla.sf.frob.com> (raw)
In-Reply-To: Petr Tesarik's message of  Tuesday, 9 June 2009 09:26:58 +0200 <1244532418.5199.24.camel@nathan.suse.cz>

> > I am wondering why we need -P -C here - but we do not need it for lds.S files?
> > Seems like something we could let go.

AFAIK these only affect readability of the lds.s output files.
The difference should be entirely cosmetic.

> > > >  	.altinstructions	: { *(.altinstructions) }
> > > > @@ -43,9 +42,49 @@ SECTIONS
> > > >  	 */
> > > >  	. = ALIGN(0x100);
> > 
> > What is 0x100?
> 
> Um. No idea. Roland, you added this line in commit
> f6b46ebf904f69a73907a5e6b1ed2228e3f03d9e. Can you shed some light on
> this magic constant?

You mean this one:

	/*
	 * Align the actual code well away from the non-instruction data.
	 * This is the best thing for the I-cache.
	 */
	. = ALIGN(0x100);

Reading the comment might make it obvious that it's intended for optimal
code alignment.  I suspect someone at the time told me 256 is as big as an
I-cache line was ever likely to get.  You could use L1_CACHE_BYTES instead
I suppose.

> What would you expect? The linker script language is quite limited in
> its capabilities... Best I could do is split the ".broken" section into
> several sections and move the descriptions from the individual comments
> above here. If this muckle of empty ".broken.*" sections gets correctly
> discarded and triggers no bug in binutils, I can probably do it.

Adding more sections and section names unnecessarily bloats the size of the
vDSO image.  Keep the set of output sections to the necessary minimum.


Thanks,
Roland

  reply	other threads:[~2009-06-09  7:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-01 14:05 [PATCH] x86: clean up vdso-layout.lds.S Petr Tesarik
2009-06-05 15:25 ` Petr Tesarik
2009-06-05 16:27   ` Andi Kleen
2009-06-05 16:24     ` H. Peter Anvin
2009-06-09  7:32       ` Petr Tesarik
2009-06-05 20:07   ` Sam Ravnborg
2009-06-09  7:26     ` Petr Tesarik
2009-06-09  7:52       ` Roland McGrath [this message]
2009-06-09  7:57         ` Petr Tesarik
2009-06-09  8:09           ` Roland McGrath
2009-06-09  8:29             ` Petr Tesarik
2009-06-09 15:41         ` H. Peter Anvin
2009-06-09 18:11       ` Sam Ravnborg
2009-06-09 18:16         ` H. Peter Anvin
2009-06-09 19:22           ` 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=20090609075247.DA95CFC3B2@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=ptesarik@suse.cz \
    --cc=sam@ravnborg.org \
    --cc=tglx@linutronix.de \
    /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