How to run macos universal built binary on 32 bit boot of macbook pro

Question

Level 1

0 points

How to run macos universal built binary on 32 bit boot of macbook pro

I have lot of doubts using universal built binary. I didnt get required information about universal binary from google or documentation provided by macos on universal binary.

Here are the steps I followed:

1) I compiled my application selecting architectures i386 and x86_64 (from xcode).

2) I see application is built as fat binary which supports i386 and x86_64 (using file command).

TestApp: Mach-O universal binary with 2 architectures
TestApp (for architecture x86_64): Mach-O 64-bit executable x86_64
TestApp (for architecture i386): Mach-O executable i386

3) Now the problem is when I boot 32 bit kernel on macbook pro and try to execute my universal binary, it is behaving as 64 bit architecture application( sizeof(long) and sizeof(char *) is coming as 8 bytes).

For this I found a way how to run universal binary selecting architecture:

arch -i386 ./TestApp

This selects i386 architecture from fat binary and runs the application(sizeof(long) and sizeof(char *) is 4 bytes).

However, my requirement is I should run universal binary on i386 as i386 application without using arch command.

Are there any xcode settings to be made to make universal binary run as i386 application on 32 bit macos boot ??? Can we select architectural preferences for running universal binary application ??

Please help.

Regards,
Sumanth

macbook pro, Mac OS X (10.6.4)

Posted on Jul 21, 2010 11:47 PM

Reply

Answer 1

sumanth Author

Level 1

0 points

Jul 22, 2010 7:11 AM in response to sumanth

Any updates!! pls help

Reply

Answer 2

Jul 22, 2010 10:56 AM in response to sumanth

The term "universal binary" refers to a binary that contains code for more than one CPU architecture. For the Mac, this usually means an Intel and a PowerPC architecture compiled into one binary. What you've built is a binary that instead of being PowerPC and Intel are i386 and x86_64 -- which is perfectly valid.

The source of your confusion is the assumption that a 32-bit kernel will run 32-bit binaries. While it can, the default and proper behavior is to run applications in 64-bit (x86_64) on CPUs that support it. Only the very first series of Intel Macs (ca. 2006) used 32-bit CPUs. Any contemporary Mac should run 64-bit application binaries if available.

Reply

Answer 3

sumanth Author

Level 1

0 points

Jul 23, 2010 12:48 AM in response to J D McIninch

Hi,

There is no problem in terms of execution of universal built application on 32 bit boot(By default its picking 64 bit arch from universal binary).

The problem is because, as 64 bit arch is being picked from universal built executable(TestApp) for execution(on 32 bit boot), the ioctl call buffers sent by this app will be of structures(having pointers of 64 bit).

Because of this IOCTL calls made to our driver are failing as it considers structures(with pointers) are based on 32 bit as 32 bit OS is running.

Please ask me if its not clear! Please help!!

Reply

Answer 4

Jul 23, 2010 6:51 AM in response to sumanth

So, it's an issue with a device driver and ioctl. Since the pointer is converted from a user-space pointer to a physical address by the kernel, it ought not matter whether it's a 64-bit or 32-bit pointer. What is the base class for the driver object you are using? When you override the ioctl method, do you dump out the parameters? The address may be different because it's in kernel space, but you can dump out a chunk of memory the size of the data structure you're sending and see if it's got all the right bits.

Reply

Answer 5

sumanth Author

Level 1

0 points

Jul 23, 2010 7:42 AM in response to J D McIninch

This is the thing I am doing with my application:

ioctlBuff.pvInputBuffer = Address of some structure;
ioctlBuff.ulInputLength = sizeof(some structure);

ioctlBuff.pvOutputBuffer = pOutputBuffer;
ioctlBuff.ulOutputLength = dwOutputBufferLength;

and calling: ioctl((int)pDevIO->m_hDevice, dwIoctl,&ioctlBuff);

If I make sure driver is hit with the ioctl code I am calling(by maintaining sizeof third parameter in _IOWR('k', 0x854, typedef structure) to be same in driver and application), driver is getting hit with that ioctl code.

And here is the main issue:

now driver does:

copy fromuser(&sRdmBuffer, psIoBuffer->InputBuffer, psIoBuffer->InputLength), it fails to copy as InputBuffer passed by user space is 64 bit pointer!!

I conformed values i pass to copy fromuser are valid.

BUT I DONT SEE ANY OF THESE ISSUES IF I USE
arch -i386 ./TestApp

for my universal binary as i386 set of text code is picked for execution!

Thats why I wanted to load i386 arch of my universal binary. I dont want to use arch command.

Reply

Answer 6

sumanth Author

Level 1

0 points

Jul 25, 2010 10:49 PM in response to sumanth

Any updates!

Reply

Answer 7

sumanth Author

Level 1

0 points

Jul 30, 2010 4:35 AM in response to sumanth

No body is answering.. pls ask if you want more information

Reply