[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] fix of vmxassist.ld


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
  • Date: Tue, 15 Aug 2006 09:57:43 +0800
  • Delivery-date: Tue, 15 Aug 2006 01:51:06 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aca/btMIXnH79aIBSC+Yqq7s+eOBcAAVB0YyABK1TtA=
  • Thread-topic: [Xen-devel] [PATCH] fix of vmxassist.ld

>> Currently there's one bug in tools/firmware/vmxassist/vmxassist.ld.
It
>> intends to put all uninitialized globe variables in object files into
>> between _bbss and _ebss. In head.S, it sets memory between _bbss and
>> _ebss to 0. But for gcc, compiler will put uninitialized globe
variables
>> (e.g: int a;) into a section called COMMON, rather than .bss, and
linker
>> collects variables in COMMON section of all objects and puts them in
>> .bss. So it results in uninitialized globe variables are behind
_ebss,
>> rather than in front of it, which will not be set to 0. This patch
fixes
>> it.
>
>Usual way around this is to define the start/end labels outside the
>.section{} region. This is what the Xen and Linux linker scripts do, so
it's
>the fix I checked in for this issue.
>
Yes, this is a more general solution! 

Thanks, 
-Xiaowei

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.