llvm dev - Oct 2010 - [LLVMdev] [PATCH] Configurable machine type in ELFObjectWriter

I've been working on ELF object support for the MicroBlaze backend and found
that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch
that makes the 16-bit e_machine value in the ELF header configurable by the
target backend.

Right now the target backend simply passes the 16-bit value that it would like
to use in the ELF header. I have considered a second approach where ArchType
would be passed to ELFObjectWriter and decoded into the correct 16-bit value.
The way I see, the second approach has the advantage of being similar to the way
OSType is currently handled by ELFObjectWriter but has the disadvantage of
requiring backends to edit the ELFObjectWriter source file if they want to add
ELF support. I suppose that this is no different from editing ADT/Triple.h when
you want to add a new ArchType.

If the second approach is more desirable, then I can rework the patch as
appropriate.




--
Wesley Peck
University of Kansas
SLDG Laboratory


-- Wesley Peck

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/2bc46d2f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elf-emachine.patch
Type: application/octet-stream
Size: 5470 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/2bc46d2f/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101022/2bc46d2f/attachment-0001.html>

You can probably delete the FIXME above the Write16(Emachine) line,
since this fixes it.  :)

Reid

On Fri, Oct 22, 2010 at 9:13 AM, Wesley Peck <peckw at wesleypeck.com>
wrote:
> I've been working on ELF object support for the MicroBlaze backend and
found
> that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a
> patch that makes the 16-bit e_machine value in the ELF header configurable
> by the target backend.
> Right now the target backend simply passes the 16-bit value that it would
> like to use in the ELF header. I have considered a second approach where
> ArchType would be passed to ELFObjectWriter and decoded into the correct
> 16-bit value. The way I see, the second approach has the advantage of being
> similar to the way OSType is currently handled by ELFObjectWriter but has
> the disadvantage of requiring backends to edit the ELFObjectWriter source
> file if they want to add ELF support. I suppose that this is no different
> from editing ADT/Triple.h when you want to add a new ArchType.
> If the second approach is more desirable, then I can rework the patch as
> appropriate.
>
>
>
> --
> Wesley Peck
> University of Kansas
> SLDG Laboratory
>
> -- Wesley Peck
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

Hello Wesley,
> file if they want to add ELF support. I suppose that this is no different
> from editing ADT/Triple.h when you want to add a new ArchType.
> If the second approach is more desirable, then I can rework the patch as
> appropriate.
Well, we already have EM_* stuff, I don't see why one should duplicate it,
so
just passing a single uint16_t value looks ok for me. Please commit.

Thanks!

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University