I don't have the source code but have the binary. With command "nm binary_name" I could know the functions inside the binary.
Can I know how many parameters a function has? Under solaris, is there anyway to do that?
e.g, if the function is: func1(a int,b int,c int), then there are 3 parameters.
Thanks
Daniel
No. Neil Butterworth's suggestion to examine the function signature is a good one for C++ (since the parameters are often encoded into the function so the linker can tell the difference between "int x(int)" and "int x(float)" for example) but, for C, you're going to have to get your hands dirty and disassemble the function, taking particular note of how the stack frames are built and used in your environment.
Keep in mind that SPARC has a rotating window stack rather than regular grow-down stack. You're really going to delve deep into the way the CPU works. If you're talking Solaris for Intel, the rotating stack is not there, of course.
Assuming this is C code, then no there is not - the
compiler/linker elides that information. If it is C++ code, it is just possible that the mangled name of the function is retained and includes the parameters in encoded form.
At the lowest level, if you emulate the function running on the machine, then it will read some information either from registers or the stack which it has not written. If you compare these reads to the ABI of the platform ( You don't say whether it's Sparc Solaris or Intel Solaris ) then some of them should correspond to the registers/stack locations of the parameters of the function. Of course, there's no guarantee that a function will read all its parameters.
For Solaris, elfdump might give more information than nm ( a quick google for elfdump signature indicates support was requested and added, but you'd need to check what version you've got )
IDA Pro (http://www.hex-rays.com/idapro/) is a disassembler which is pretty clever at infering parameters of a function from object code;
maybe there is also symbolic information you can use; eg. on Win32 the symbol _function#8 reveals that 8 bytes (2 parameters) are passed
one can also demangle C++ names to get the parameters and types
Related
I have few benchmarks like fft, dijkstra. I want to collect the stack size of all library functions and user defined functions. C code is also available.
I am managing cache in hardware, so i need the exact stack size of each small function, variable.
If compiling with a recent GCC you could pass the -fstack-usage flag to gcc (in addition of optimization flags, if any) which:
Makes the compiler output stack usage information for the program, on a per-function basis. The filename for the dump is made by appending .su to the auxname. auxname is generated from the name of the output file, if explicitly specified and it is not an executable, otherwise it is the basename of the source file. An entry is made up of three fields:
The name of the function.
A number of bytes.
One or more qualifiers: static, dynamic, bounded.
The qualifier static means that the function manipulates the stack statically: a fixed number of bytes are allocated for the frame on function entry and released on function exit; no stack adjustments are otherwise made in the function. The second field is this fixed number of bytes.
The qualifier dynamic means that the function manipulates the stack dynamically: in addition to the static allocation described above, stack adjustments are made in the body of the function, for example to push/pop arguments around function calls. If the qualifier bounded is also present, the amount of these adjustments is bounded at compile time and the second field is an upper bound of the total amount of stack used by the function. If it is not present, the amount of these adjustments is not bounded at compile time and the second field only represents the bounded part.
You could also pass a -Wstack-usage=len warning flag, which:
Warn if the stack usage of a function might be larger than len bytes. The computation done to determine the stack usage is conservative. Any space allocated via alloca, variable-length arrays, or related constructs is included by the compiler when determining whether or not to issue a warning.
You may consider writing your GCC plugin to extract the stack size of of functions compiled by a recent GCC (e.g. GCC 10 in October 2020), and since GCC is free software, you could improve it.
Of course, if you want the same information for libraries, you should re-compile them from their source code.
BTW, the stack usage of some functions, or of some function calls occurrences, might be ill-defined (and certainly depends upon the optimization flags and the target system), since GCC is sometimes capable of tail call optimizations, and of function inlining (even on functions not qualified inline!) and/or function cloning. Also, some few C standard library functions (printf, memset, ....) are magically known to the compiler which might use some internal builtin functions to compile them. At last, several softwares (and more and more libraries) are compiled with link-time optimizations (using -flto), then the stack usage of individual functions is not well defined (since they are often inlined).
So I am not sure your question makes any precise sense. You might rephrase it and motivate and improve it.
How can I retrieve the type of architecture (linux versus Windows) in my fortran code? Is there some sort of intrinsic function or subroutine that gives this information? Then I would like to use a switch like this every time I have a system call:
if (trim(adjustl(Arch))=='Linux') then
resul = system('ls > output.txt')
elseif (trim(adjustl(Arch))=='Windows')
resul = system('dir > output.txt')
else
write(*,*) 'architecture not supported'
stop
endif
thanks
A.
The Fortran 2003 standard introduced the GET_ENVIRONMENT_VARIABLE intrinsic subroutine. A simple form of call would be
call GET_ENVIRONMENT_VARIABLE (NAME, VALUE)
which will return the value of the variable called NAME in VALUE. The routine has other optional arguments, your favourite reference documentation will explain all. This rather assumes that you can find an environment variable to tell you what the executing platform is.
If your compiler doesn't yet implement this standard approach it is extremely likely to have a non-standard approach; a routine called getenv used to be available on more than one of the Fortran compilers I've used in the recent past.
The 2008 standard introduced a standard function COMPILER_OPTIONS which will return a string containing the compilation options used for the program, if, that is, the compiler supports this sort of thing. This seems to be less widely implemented yet than GET_ENVIRONMENT_VARIABLE, as ever consult your compiler documentation set for details and availability. If it is available it may also be useful to you.
You may also be interested in the 2008-introduced subroutine EXECUTE_COMMAND_LINE which is the standard replacement for the widely-implemented but non-standard system routine that you use in your snippet. This is already available in a number of current Fortran compilers.
There is no intrinsic function in Fortran for this. A common workaround is to use conditional compilation (through makefile or compiler supported macros) such as here. If you really insist on this kind of solution, you might consider making an external function, e.g., in C. However, since your code is built for a fixed platform (Windows/Linux, not both), the first solution is preferable.
I understand 64 bit Linux allows one to pass the first six integer function parameters and first eight floating point function parameters via registers.
If I had seven integer parameters to pass, is there any way for me to use one of the un-used float registers for the seventh integer, without sacrificing performance?
If you are writing your own assembly code, you can utilize the registers in whatever way you want (ok, maybe not quite that liberal, but you can be free to ignore the ABI, sorta). However, if you are interfacing with library code (or system calls, or parts of your program compiled from a higher level language, or ...) that was written to follow the standard ABI, you will have to follow the same restrictions in the portions of your code that form/use the ABI-compliant interfaces.
Is there a way / system call / a function that lets me read numbers from stdin into a register?
currently I can read in a string of, say, 9 characters.
This is, unfortunately, not what I was looking for since my number could be of variable length (so long it is representable in assembly)
e.g. I want to be able to input "5" as well as "66785949" as well as negative numbers like "-1123534", and have it correctly represented as an actual number in assembly, not a string.
I've been looking everywhere so I decided to ask here.
If there's no easy way to do it, is it possible to use C's input/output function library into my linux nasm assembly code? How would I do that and how would I call one of these functions to get a number from stdin?
Thanks
No, there is no system call to do it. Yes, you can easily call atoi(), if you don't feel like implementing it yourself. You just need to link to the C library (-lc) and declare the external symbol (extern atoi).
Google translate :
The interpreter is created, an array of bytes into the array in a machine language to cast the enum type and function, I have made an approach to dynamically execute a function, reference Please tell me if the machine-language site.
Babelfish translate:
It is to make the interpreter, but inserting machine language in arrangement at the byte unit, but if it is it makes function dynamically with the approach that it arranges the very the cast, it executes that in functional type through enum, there is a sight of the machine language which becomes reference, please teach.
Original question:
インタプリタを作っているのですが、機械語をバイト単位で配列に入れて
その配列をenumを通して関数型にキャストし、それを実行するというアプローチで関数を動的に作っているのですが、
参考になる機械語のサイトがあれば教えてください。
I'm going to make a guess - a pure guess:
You have an array of bytes containing the machine code for a function. How can you write a cast such that the function can be executed?
In which case, the answer is likely to be:
In most modern operating systems, the system protects you from converting data into executable code. The best way to deal with it would be to package the code as a function in a dynamically-loaded (shared) library, and then use the standard calls for the operating system to load that library and execute the function.