From: "H. Peter Anvin" <hpa@zytor.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
Borislav Petkov <bp@alien8.de>, "H.J. Lu" <hjl.tools@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Ingo Molnar <mingo@kernel.org>,
Jarkko Sakkinen <jarkko.sakkinen@intel.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
Len Brown <len.brown@intel.com>, Len Brown <lenb@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg@redhat.com>, Michal Marek <mmarek@suse.cz>,
Paolo Bonzini <pbonzini@redhat.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
Sam Ravnborg <sam@ravnborg.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [GIT PULL] x86 trampoline rework for 3.5
Date: Tue, 29 May 2012 20:07:42 -0700 [thread overview]
Message-ID: <4FC58EFE.2070705@zytor.com> (raw)
In-Reply-To: <CA+55aFyjcbaRcK5yfi-xLc2W+AAk0EAY9fhNOc+-_uQdDzck6w@mail.gmail.com>
On 05/29/2012 07:37 PM, Linus Torvalds wrote:
>
> but in your branch that "^pa_" pattern is duplicated for S_REL:
>
> /*
> * These symbols are known to be relative, even if the linker marks them
> * as absolute (typically defined outside any section in the linker script.)
> */
> [S_REL] =
> "^pa_",
>
> /*
> * These are 16-bit segment symbols when compiling 16-bit code.
> */
> [S_SEG] =
> "^real_mode_seg$",
>
> /*
> * These are offsets belonging to segments, as opposed to linear addresses,
> * when compiling 16-bit code.
> */
> [S_LIN] =
> "^pa_",
>
> which looks odd.
>
> But that case with three patterns is the one you selected in your
> merge - *not* the current state of relocs.c that you claim should be
> selected.
>
Sorry, you're right. The version with three patterns is correct. The
"^pa_" patterns are linear addresses which should be treated as
relative, and so belong both to S_REL and S_LIN. This didn't surface as
a conflict, so I forgot to flag it.
> So I'm not pulling or merging anything until I understand what's going
> on. Should I take the two-pattern one (which is what I have now, and
> that seems sensible), or should that "^pa_" pattern really be merged
> for two different cases (doesn't that just mean that the last one will
> effectively override the first one)?
>
> Also, your branch adds an "x86-relocs" thing to the scripts/.gitignore
> file that you seem to have removed in the merge. What was going on
> there?
That line should have been removed in checkin f2604c14 but wasn't; since
that was one of the checkins that got folded up into 6520fe55 I cleaned
it up at that time.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
next prev parent reply other threads:[~2012-05-30 3:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-29 23:25 [GIT PULL] x86 trampoline rework for 3.5 H. Peter Anvin
2012-05-30 2:37 ` Linus Torvalds
2012-05-30 3:07 ` H. Peter Anvin [this message]
2012-05-30 3:19 ` Linus Torvalds
2012-05-30 3:38 ` H. Peter Anvin
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=4FC58EFE.2070705@zytor.com \
--to=hpa@zytor.com \
--cc=bp@alien8.de \
--cc=hjl.tools@gmail.com \
--cc=hpa@linux.intel.com \
--cc=jarkko.sakkinen@intel.com \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=len.brown@intel.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=mjg@redhat.com \
--cc=mmarek@suse.cz \
--cc=pbonzini@redhat.com \
--cc=rjw@sisk.pl \
--cc=sam@ravnborg.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 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.