From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v2 2/3] x86/boot: Move some __high_start
 code and data into init sections
Date: Mon, 28 Apr 2014 15:49:16 +0100
Message-ID: <535E6A6C.40407@citrix.com>
References: <1398690404-9559-1-git-send-email-andrew.cooper3@citrix.com>
	<1398690404-9559-3-git-send-email-andrew.cooper3@citrix.com>
	<535E7C27020000780000D04E@nat28.tlf.novell.com>
	<535E612D.2080705@citrix.com>
	<535E858C020000780000D0FD@nat28.tlf.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <535E858C020000780000D0FD@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 28/04/14 15:45, Jan Beulich wrote:
>>>> On 28.04.14 at 16:09, <andrew.cooper3@citrix.com> wrote:
>> On 28/04/14 15:04, Jan Beulich wrote:
>>>>>> On 28.04.14 at 15:06, <andrew.cooper3@citrix.com> wrote:
>>>> --- a/xen/arch/x86/boot/x86_64.S
>>>> +++ b/xen/arch/x86/boot/x86_64.S
>>>> @@ -29,7 +29,11 @@
>>>>  
>>>>          test    %ebx,%ebx
>>>>          jnz     start_secondary
>>>> +        jmp     start_bsp
>>>>  
>>>> +        .section .init.text, "ax", @progbits
>>>> +
>>>> +GLOBAL(start_bsp)
>>> I'm sorry, I'm afraid I overlooked this in v1 - why GLOBAL()? (The other
>>> two patches look fine to me now, so no need to re-send those in case
>>> this one needs changing.)
>> There is an explanation below the --- in the patch.
> Oops, sorry, stopped reading that part after the v2 sentence.
>
>> The issues is that start_bsp and trampoline_end have the same address,
>> leading to a confusing disassembly.
> Is that really defined behavior - trampoline_end is a global too? Which
> one would get used if their addresses are the same may depend on
> both linker and disassembler. I therefore don't agree to this needless
> global.
>
> Jan
>

trampoline_end is a valid global, as it is referenced in the C code.

I can drop the global.  This is not the only instance of overlapping
symbols, and anyone looking at the disassembly will have reference to
the code as well.

v3 on its way.

~Andrew