Xbox support question

Xbox support question

[Myria]

I want to add Xbox as a supported target.  I want the Xbox mode of binutils 
to function exactly the same as "i686-pc-mingw32", with the following 
changes:

1. Subsystem type is defaulted to 14 (IMAGE_SUBSYSTEM_XBOX in ~2002+ 
Microsoft header winnt.h)
2. Default PE base address for subsystem xbox is 0x00020000.
3. Default entry point for subsystem xbox is mainCRTStartup.

(Conversion from ld's EXE output to the Xbox's native XBE format is 
straightforward and is handled by an external tool.  It just would be nice 
to use that subsystem number for recognition, and that base address so we 
don't have to do relocation, since binutils stupidly refuses to make a 
relocatable EXE.)

What is the easiest way I can add xbox as a target?  It seems like I would 
have to clone a lot of the mingw32 code in binutils for the Xbox case.

Thanks,

Melissa 

Re: Xbox support question

[Aaron W. LaFramboise]

Myria wrote:

> 1. Subsystem type is defaulted to 14 (IMAGE_SUBSYSTEM_XBOX in ~2002+ 
> Microsoft header winnt.h)
> 2. Default PE base address for subsystem xbox is 0x00020000.
> 3. Default entry point for subsystem xbox is mainCRTStartup.

I am not personally interested in Xbox programming.

However, since you'd need special build machinery in this case to do
conversion from PE to XBE anyway, is it really that much of a burden to
use the command line options that accomplish all of the above?  Also,
Filip Navara recently submitted some fixes towards fixing -pie on PE.

It seems a little odd to add Xbox support to binutils when such support
is only useful for complementing some other unspecified required Xbox tools.

Is it a lot of work to cause binutils to be able to handle XBE directly?
 Is XBE similar to any of the other object formats binutils uses?

Aaron W. LaFramboise

Re: Xbox support question

[Myria]

> However, since you'd need special build machinery in this case to do
> conversion from PE to XBE anyway, is it really that much of a burden to
> use the command line options that accomplish all of the above?  Also,
> Filip Navara recently submitted some fixes towards fixing -pie on PE.

Currently, we need a patch either way, as --subsystem:xbox isn't allowed, 
and ld doesn't accept numbers either (--subsystem:14).  It's just rather 
dangerous to leave EXEs floating around that executing could do who knows 
what to Windows.  Setting subsystem 14 causes an error when trying to run 
one.

> It seems a little odd to add Xbox support to binutils when such support
> is only useful for complementing some other unspecified required Xbox 
> tools.

I guess so...  I suppose --target=i686-pc-mingw32 --program-prefix=xbox- is 
enough, with a patch for --subsystem:xbox support.

> Is it a lot of work to cause binutils to be able to handle XBE directly?
> Is XBE similar to any of the other object formats binutils uses?

For someone that understands ld, probably not.  But I don't, and XBE stuff 
is a little weird, with a million options.

XBE is most like PE, as you probably guessed.  However, to correctly 
implement XBE requires the SHA-1 hash algorithm, which is a significant 
addition.

Melissa 

Re: Xbox support question

[Aaron W. LaFramboise]

Myria wrote:

> Currently, we need a patch either way, as --subsystem:xbox isn't allowed, 
> and ld doesn't accept numbers either (--subsystem:14).  It's just rather 
> dangerous to leave EXEs floating around that executing could do who knows 
> what to Windows.  Setting subsystem 14 causes an error when trying to run 
> one.

I would suspect a patch to accept 'xbox' (and any other missing
subsystem) would be welcome, as well as perhaps a patch to allow the
subsystem parameter to accept arbitrary integers.

>>Is it a lot of work to cause binutils to be able to handle XBE directly?
>>Is XBE similar to any of the other object formats binutils uses?
> 
> For someone that understands ld, probably not.  But I don't, and XBE stuff 
> is a little weird, with a million options.
> 
> XBE is most like PE, as you probably guessed.  However, to correctly 
> implement XBE requires the SHA-1 hash algorithm, which is a significant 
> addition.

There are a lot of SHA-1 implementations availible, but I don't know if
there are any that are completely public domain or have been assigned to
the FSF.  A dependency could on a free third-party library could be
established for the Xbox if the politics were ultimately prohibitive.
The real work would probably be in tweaking PECOFF for XBE, but if its
fairly close, that might not be that big of a deal.

Aaron W. LaFramboise

Re: Xbox support question

[DJ Delorie]

> A dependency could on a free third-party library could be
> established for the Xbox if the politics were ultimately
> prohibitive.

The politics would likely prohibit dependencies on non-free (or at
least GPL-incompatible) libraries as well.

Re: Xbox support question

[Paul Koning]

>>>>> "DJ" == DJ Delorie <dj@redhat.com> writes:

 >> A dependency could on a free third-party library could be
 >> established for the Xbox if the politics were ultimately
 >> prohibitive.

 DJ> The politics would likely prohibit dependencies on non-free (or
 DJ> at least GPL-incompatible) libraries as well.

There certainly are GPL compatible SHA-1 implementations available, in
GNU/Linux, or FreeS/WAN, for example.

	   paul

Re: Xbox support question

[DJ Delorie]

> There certainly are GPL compatible SHA-1 implementations available, in
> GNU/Linux, or FreeS/WAN, for example.

Yeah, then the question becomes how to compromise between bloating the
binutils sources and inconveniencing the user :-P

(that is, after the politics of choosing a suitable implementation)

Re: Xbox support question

[Myria]

>> There certainly are GPL compatible SHA-1 implementations available, in
>> GNU/Linux, or FreeS/WAN, for example.
>
> Yeah, then the question becomes how to compromise between bloating the
> binutils sources and inconveniencing the user :-P
>
> (that is, after the politics of choosing a suitable implementation)

That's what I meant by a "significant addition"...  bloating the binutils 
code by 20k just so maybe 30 people can use OpenXDK.  That's personally why 
I'd just use PE format then convert PE to XBE with another tool. 
Microsoft's and Xbox Linux's PE->XBE tool is named (independently) 
"imagebld"; OpenXDK's current poor design is named "cxbe".

Microsoft's game-developer-only tool uses link.exe with /subsystem:xbox to 
produce PE files for later conversion.  Try it on standard VC7.1, it works:

C:\xboxtest>type meow.c
void mainCRTStartup(void) { }

C:\xboxtest>cl /c meow.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

meow.c

C:\xboxtest>link /out:meow.exe /fixed:no /subsystem:xbox meow.obj
Microsoft (R) Incremental Linker Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

C:\xboxtest>dumpbin /headers meow.exe
Microsoft (R) COFF/PE Dumper Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file meow.exe

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
             14C machine (x86)
               1 number of sections
        416B2639 time date stamp Mon Oct 11 17:32:57 2004
               0 file pointer to symbol table
               0 number of symbols
              E0 size of optional header
             10E characteristics
                   Executable
                   Line numbers stripped
                   Symbols stripped
                   32 bit word machine

OPTIONAL HEADER VALUES
             10B magic # (PE32)
            7.10 linker version
              20 size of code
               0 size of initialized data
               0 size of uninitialized data
             1E0 entry point (004001E0)
             1E0 base of code
             200 base of data
          400000 image base (00400000 to 004001FF)
              20 section alignment
              20 file alignment
            4.00 operating system version
            0.00 image version
            1.00 subsystem version
               0 Win32 version
             200 size of image
             1E0 size of headers
               0 checksum
               E subsystem (Xbox)
               0 DLL characteristics
          100000 size of stack reserve
            1000 size of stack commit
          100000 size of heap reserve
            1000 size of heap commit
               0 loader flags
              10 number of directories
               0 [       0] RVA [size] of Export Directory
               0 [       0] RVA [size] of Import Directory
               0 [       0] RVA [size] of Resource Directory
               0 [       0] RVA [size] of Exception Directory
               0 [       0] RVA [size] of Certificates Directory
               0 [       0] RVA [size] of Base Relocation Directory
               0 [       0] RVA [size] of Debug Directory
               0 [       0] RVA [size] of Architecture Directory
               0 [       0] RVA [size] of Global Pointer Directory
               0 [       0] RVA [size] of Thread Storage Directory
               0 [       0] RVA [size] of Load Configuration Directory
               0 [       0] RVA [size] of Bound Import Directory
               0 [       0] RVA [size] of Import Address Table Directory
               0 [       0] RVA [size] of Delay Import Directory
               0 [       0] RVA [size] of COM Descriptor Directory
               0 [       0] RVA [size] of Reserved Directory


SECTION HEADER #1
   .text name
       5 virtual size
     1E0 virtual address (004001E0 to 004001E4)
      20 size of raw data
     1E0 file pointer to raw data (000001E0 to 000001FF)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
60000020 flags
         Code
         Execute Read

  Summary

          20 .text

C:\xboxtest>meow
The C:\xboxtest\meow.exe application cannot be run in Win32 mode.

Re: Xbox support question

[Aaron W. LaFramboise]

Myria wrote:
>>>There certainly are GPL compatible SHA-1 implementations available, in
>>>GNU/Linux, or FreeS/WAN, for example.
>>
>>Yeah, then the question becomes how to compromise between bloating the
>>binutils sources and inconveniencing the user :-P
> 
> That's what I meant by a "significant addition"...  bloating the binutils 
> code by 20k just so maybe 30 people can use OpenXDK.

In the hypothetical case that someone were willing to add XBE support to
binutils (which, as far as I know, is only hypothetical at this time),
the SHA-1 issue should not be a significant deterant.  There is a
popular, ready-to-use, completely public domain implementation of SHA-1
by Steve Reid that has a source code length of only about 6k, or 2k
compressed.  The object code compiled (and presumably only for the Xbox
target) is about 21k, or 7k without debugging information.  Compared
with a distribution size of 11MB, and a ld which is 3MB even with
dynamic linking, this isn't a big deal.  SHA-1 support would probably be
the easiest part of the port.

If XBE is quite close to PECOFF, I would encourage anyone in the Xbox
community to create a real port.

Aaron W. LaFramboise

RE: Xbox support question

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of DJ Delorie
> Sent: 11 October 2004 21:47

> > A dependency could on a free third-party library could be
> > established for the Xbox if the politics were ultimately
> > prohibitive.
> 
> The politics would likely prohibit dependencies on non-free (or at
> least GPL-incompatible) libraries as well.

Easy:  rip gnupg.

http://www.gnupg.org/(en)/features.html

"Supports ElGamal, DSA, RSA, AES, 3DES, Blowfish, Twofish, CAST5, MD5,
SHA-1, RIPE-MD-160 and TIGER. "


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....