I found that Linux and GNU Binutils define a special machine type EM_SPARC32PLUS in ELF header. Why is it needed? What makes SPARC V8+ so special that it can not use EM_SPARC?
I think there should be an important reason for new machine type, because it breaks compatibility with old programs, and all other architectures tend to use the old machine type as long as possible.
Starting with elf-em.h, we see the following (cherry-picked) entries:
#define EM_SPARC 2
#define EM_SPARC32PLUS 18 /* Sun's "v8plus" */
#define EM_SPARCV9 43 /* SPARC v9 64-bit */
Some Googling led me to this reference page for Sun Studio 12, which says:
v8plus
Compile for the V8plus version of the SPARC-V9 ISA. By definition, V8plus means the V9 ISA, but limited to the 32–bit subset defined by the V8plus ISA specification, without the Visual Instruction Set (VIS), and without other implementation-specific ISA extensions.
This option enables the compiler to generate code for good performance on the V8plus ISA.
The resulting object code is in SPARC-V8+ ELF32 format and only executes in a Solaris UltraSPARC environment—it does not run on a V7 or V8 processor.
Example: Any system based on the UltraSPARC chip architecture
It seems to be essentially the 32-bit version of the V9 architecture for the UltraSPARC.
See also:
Can 32-bit SPARC V8 application run on 64-bit SPARC V9?
Related
I am trying to enable 64 bit integer size for a sample hello world kind of Fortran test code, in an MPI setup.
OS: Windows 10
Compilers used: Intel OneAPI 2021.4.0
MPI: Intel MPI
There are 2 scenarios I tried to test,
using a single line command to compile an executable directly,
mpiifort -o test.exe -i8 test.f90
using a CmakeLists file to compile the test with necessary Fortran 64 bit "-i8" option and find_package(MPI). I made sure MPI libraries are picked (impi.lib, libmpi_ilp64.lib) and MPI_Fortran_Compiler points to mpiifort
I use a test of determining the size of MPI_INTEGER using an API MPI_Type_size( ) to check if 64 bit environment is enabled for Fortran/MPI setup.
call MPI_Type_size(MPI_INTEGER, sz, ierrsiz)
print *, 'sizeof(MPI_INTEGER) ', sz
Scenario 1 prints correct size of 8 bytes (64 bit)
Scenario 2 prints incorrect size of 4 bytes ( 32 bit)
I do use "-i8" option in Cmake build system to enable 64 bit environment. But MPI still seems to be 32 bit.
Kindly help.
OS: windows 10
Perl6: This is Rakudo Star version 2018.04.1 built on MoarVM version 2018.04.1
implementing Perl 6.c.
Example:
perl6 C:\Users\quest\Desktop\example.pl
# sucess
perl6 "C:\Users\quest\Desktop\яп\Perl 6\web-scraping\request.pl"
# Could not open C:\Users\quest\Desktop\╤П╨┐\Perl 6\web-scraping\request.pl. Failed to open file C:\Users\quest\Desktop\╤П╨┐\Perl 6\web-scraping\request.pl: No such file or directory
Python 3 example:
py "C:\Users\quest\Desktop\яп\py\3\timetest.py"
# sucess
As you have realized, Windows 10 supports UTF-8 for non-Unicode (ie non-UTF-16) apps (according to Wikipedia, this feature was added with build 17035, released in April 2018, and is still marked 'beta'). This makes Rakudo happy.
However, not respecting your locale while Python manages to do so still seems worthy of a bug report to me.
I have got very similar problem to this one stated here : Intel CPU OpenCL in Mono killed by SIGXCPU (Ubuntu)
Essentially, I have a very simple C# application using OpenCL (through OpenCL.Net wrapper, but it shouldn't make a difference as it is merely wrapping native functions and nothing more). In the code I just build kernel and then allocate a big array of floats.
To be more specific my platform: It is Ubuntu 12.04, OpenCL 1.1 (with CUDA) and mono 3.0.3.
Problem: When running my code through mono i get CPU LIMIT EXCEEDED error
Few things:
If I set a breakpoint (in monodevelop) somewhere between building the kernel and allocation it works..
Changing array size to small one also makes it work
Strace doesn't show anything useful. I tried also passing a callback to ClBuildProgram (to note: if I comment out line with ClBuildProgram it works).
Any ideas?
That's what worked for me in the end.
There is a major problem with mono - it uses SIGXCPU for GC handling (which is strange btw). Unfortunately OpenCL uses it as well so it conflicts.
Workaround is to modify mono code.
Go to source directory and grep -r SIGXCPU . In my mono (3.0.3) there were 2 imporant files
./libgc/pthread_stop_world.c:# define SIG_THR_RESTART SIGXCPU
./mono/metadata/sgen-os-posix.c:const static int restart_signal_num = SIGXCPU;
Replace SIGXCPU with SIGWINCH and recompile. One note is that I am not sure if it didn't break something, but for now looks OK and OpenCL problem is gone. If it breaks something (like gui) replace SIGWINCH with different signal that you have (signals.h for signals defs)
I compile my .dll with the following command: gcc -mno-cygwin -I"/cygdrive/c/Program Files/Java/jdk1.7.0_04/include" -I"/cygdrive/c/Program Files/Java/jdk1.7.0_04/include/win32" -Wl,--add-stdcall-alias -shared -o CalculatorFunctions.dll CalcFunc.c
I use GlassFish for Eclipse. The whole system is a CORBA client-server. When I start the server from Eclipse - it's fine. But when I try to run the server from the CMD (because I want to set a port and host address for the server) it gives me: Exception: ... .dll: Can't load AI 32-bit .dll on a AMD 64-bit platform
I searched through other topics and saw that I should try with changing my JDK to 32 bit - didn't work again.
So the other solution I read about is to compile the .DLL as 64 bit. What command I need to use or how I do that at all ?
Thanks in advance! :)
You need not only a command but whole 64-bit MinGW toolchain - a 64bit compiler in the first place. Then the parameters to your gcc invocation should work the same.
Beware that 64bit is not just a matter of compilability. Primitive data types have different sizes, so any code making assumptions without sizeof checking is a potential issue. Most prominently, pointer arithmetic.
I've written the simplest injection dll possible. Here is the code in its entirety:
#include "stdafx.h"
#include <stdio.h>
BOOL APIENTRY DllMain(HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved)
{
FILE * File = fopen("D:\\test.txt", "w");
if(File != NULL)
{
fclose(File);
}
return TRUE;
}
Super simple right? Well I can't even get this to work. This code compiles to a dll and I've placed the path to this dll in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs]. I should also mention that LoadAppInit_DLLs registry value is set to 1. From doing this I expect to see the file "D:\test.txt" appear when I start other applications (like notepad.exe), but it doesn't. I don't get it. There is another .dll, which is very old and written in visual studio '97, (which I'm trying to replace) that works just fine when I set AppInit_DLLs to point to it and start an arbitrary application. I can tell that it is getting loaded when other applications are started.
I'm not sure whats going on here, but this should work shouldn't it? It can't get any simpler. I'm using VS 2010, by all accounts I think I've created a very plane Jane .dll so I don't think any project settings should be out of whack, but I'm not completely sure about that. What am I missing here?
Setup Info
OS: Windows 7 64-bit
OS Version: 6.1.7601 Service Pack 1 Build 7601
IDE: Visual Studio 2010
IDE version: 10.0.40219.1 SP1Rel
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs]
is NOT the registry key used for injection for into 32-bit processes. Its the registry key if your OS is 32-bit.
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs] is the correct registry key to use if your OS is 64-bit.
I was under the assumption that the former was for 32-bit processes and the latter was for 64-bit processes. But really, the OS is going to ignore one of those registry keys depending on whether or not the OS itself is 64-bit or 32-bit.
#Ultratrunks: This is not completely correct.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs ] is for both 32 as well as 64 bit OS.
But If we want to run 32 bit processes on 64 bit machine then we need to modify the following registry key-
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs]
Wow is basically concept of making 64 bit system to be compatible of running 32 bit processes.
I verified it after running my programs on both 32 as well as 64 bit OS and running 32 bit processes on 64 bit machine.
Hence
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs for 32/64 bit OS
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs for 32 bit processes on 64 bit OS
First at all about the SOFTWARE\Microsoft vs SOFTWARE\Wow6432Node\Microsoft it's true that if both 32 or 64 so go into SOFTWARE\Microsoft and if you want to inject 32 bit dll in OS64 so go into SOFTWARE\Wow6432Node\Microsoft.
My problem was that the value need to be up to 8 characters and if there is in the path or name above this you need to use shortcut.
Example: if your dll name is inject~1.dll
Don't Forget to set all three reg value
AppInit_DLLs -> dllname if is in system32 or full path with out "
LoadAppInit_DLLs -> 1
RequireSignedAppInit_DLLs -> 0