On 05/23/2016 11:34 AM, Jan Beulich wrote:
On 23.05.16 at 16:51, <dgde...@tycho.nsa.gov> wrote:
--- a/xen/xsm/flask/Makefile
+++ b/xen/xsm/flask/Makefile
@@ -27,6 +27,27 @@ $(FLASK_H_FILES): $(FLASK_H_DEPEND)
$(AV_H_FILES): $(AV_H_DEPEND)
$(CONFIG_SHELL) policy/mkaccess_vector.sh $(AWK) $(AV_H_DEPEND)
+obj-y += policy.o
+
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+ OBJCOPY_ARGS := -I binary -O elf64-x86-64 -B i386:x86-64
+else ifeq ($(XEN_TARGET_ARCH),arm32)
+ OBJCOPY_ARGS := -I binary -O elf32-littlearm -B arm
+else ifeq ($(XEN_TARGET_ARCH),arm64)
+ OBJCOPY_ARGS := -I binary -O elf64-littleaarch64 -B aarch64
+else
+ $(error "Unknown XEN_TARGET_ARCH: $(XEN_TARGET_ARCH)")
+endif
As this is kind of ugly - did you try whether binutils can be talked
into generating an architecture neutral ELF object (using EM_NONE
as the architecture in the ELF header), and whether that could
then be linked? Of course that would be of limited use of the blob
was other than a plain stream of bytes (i.e. endian independent).
Jan
You get EM_NONE when you omit the -B argument, but the linker refuses
to accept this as an input unless passed --accept-unknown-input-arch.
With this flag enabled, the built_in.o is binary equal.
--
Daniel De Graaf
National Security Agency
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
