I have a stupid question:
Is it possible to convert a x86_64 application to a 32bit one?
I mean, for example, as Qemu can emulate a 64bit processor (on a 32bit machine),
and can run the linux kernel for that arch, is possible to dump in some way the full data and collect it in order to make a translated code which work as the first
(by running the same on a 32bit machine ) ??
Related
I have multiple questions regarding debugging a Raspberry pi 3 from a linux x64 host using gdb-multiarch, as well as writing bare metal programs in general. We are currently facing a problem where our code appears to not be loaded into memory. When we begin debugging in GDB we start at address 0. 3 instructions down we jump into 0x10000. If I modify my linker script to put the Raspberry pi into either address I get the same result, we jump into 0x10000 and our code isn't loaded there. Instead we get this
We noticed also that GDB is using 32 bit register names here when we're supposed to be debugging 64 bit code.
Again a recap of what we're using:
QEMU with versatile-pb machine.
An aarch64 GCC cross-compiler.
GDB-multiarch.
We've tried on two different hosts: Ubuntu 16.04 x64 Host running in virtualbox. Mint x64 running natively.
We also tried the arm-none-eabi toolchain but were running into problems not having our code compiled as 64 bit.
Help is much appreciated! Thanks!
You don't give your command line, but "versatile-pb" is a 32-bit only board type, so trying to run 64-bit code on it is going to misbehave in confusing ways. You need to tell QEMU to emulate a 64-bit capable board that matches what your bare-metal code is expecting to run on.
In QEMU 2.12 there will be a "raspi3" QEMU board which may be helpful for you; you'd need to try building the latest 2.12 release candidate tarball at the moment if you wanted to experiment with that (2.12 release isn't due for another couple of weeks). Otherwise you could use the "virt" board if you made sure your bare metal code was built to be able to run on that board.
I'm about to do a clean get of 32 bit source code onto my new Windows 7 64 bit machine. Is there anything special I need to do (switch to 32 bit mode, etc) or will Windows detect this and adapt accordingly?
The "bitness" of the operating system has nothing to do with getting source code. Your IDE determines what the target is of your compile of the source code, and most IDEs now can target either.
In other words, Windows doesn't have to do anything, and neither do you. Your development environment uses the source code, and determines what happens with it. Windows has absolutely nothing to do with it, except to run any resulting executable that's produced if it's compatible with that version of Windows. (And Win64 runs 32-bit applications just fine.)
Just as a note: You can't "switch to 32-bit mode" with a 64-bit operating system. It's always going to be a 64-bit operating system, even if you're running a 32-bit application. The application may not know it's running on a 64-bit OS, but it will be despite it's ignorance of that fact. :)
Attempting to call SetupDiCallClassInstaller from a program compiled in 32 bit mode fails on 64 bit Windows.
Apparently this is by design, but I'd like to know the reason.
According to MSDN:
Device Installations on 64-Bit Systems:
The 32-bit version of the application must check the value returned by UpdateDriverForPlugAndPlayDevices. If the return value is ERROR_IN_WOW64, the 32-bit application is executing on a 64-bit platform and cannot update inbox drivers. Instead, it must call CreateProcess (described in the Windows SDK documentation) to start the 64-bit version of the application. The 64-bit version can then call UpdateDriverForPlugAndPlayDevices, specifying a FullInfPath parameter that identifies the location of the 64-bit versions of all files.
So it looks like any API that is designed to report ERROR_IN_WOW64 is specifically intended NOT to work in WOW64, a 32bit process has to invoke a 64bit process to call the API.
If you are making that call from a 32bit process on a 64bit OS, it fails because it has to modify some registry keys in the 64bit portion of the registry. Where else if you were to make that call from a 64bit process on a 64bit OS, it would succeed likewise with 32bit process on a 32bit OS.
My development machine has a 64 bit proc, running a 32 bit distribution.
I would like to compile and test a kernel module with a 64 bit kernel. My question is :
Is there a 64 bit liveCD with kernel development package included ?
If it does not exist, How can I build a module for a 64 bit kernel ? Then I can eventually test it with a liveCD
You can install a 64-bit VM on a 32-bit operating system, provided the CPU supports it. I know this is possible with VMWare, don't know about anything else.
If you're doing any system development nowadays, I'd say use a VM, regardless of the target platform. Just use a VM.
It might be more technical than you would want to try, but, if you can get a 64bit toolchain installed, you should be able to compile the kernel through:
make ARCH=amd64 CROSS_COMPILE=x86_64-pc-linux-gnu- menuconfig
You should be able to boot your regular 32bit userland with a 64bit kernel (if you select the appropriate binary compatibility options)
Cheers!
http://www.ubuntu.com/desktop/get-ubuntu/download has links for 64-bit download, and the "make USB on windows" option includes screenshots showing how to make a bootable 64-bit ubuntu USB memory stick. (None of the other options in the {CD, USB} x {Windows, Mac, Ubuntu} instructions mention anything about only working for x86 vs x86-64.)
I'm limited to ObjectAda 7.2 for particular reason. Do i need to install a 64 bit OS (Win 64x in my case) to write and run such programs?
Is your goal just to write multi-threaded programs in Ada that can run concurrently on the multiple cores?
It depends on how your compiler handles Ada tasks, but IIRC that compiler maps Ada tasks to Windows threads, so it should work just fine with a 32-bit OS. The program itself probably wouldn't generate any different code for a 64-bit Windows than for 32-bit. To get any different, you'd need a 64-bit version of the compiler (which probably won't be OA 7.2). Aonix's current datasheet for OA doesn't even say anything about Vista or Win7 support.
You might consider going 64 bit to get more than 3 Gig of accessible RAM, but I don't think it will help your Ada code any.