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).
Related
I have a .exe file and i want to list all function of it. It is possible and have some tool to do it?
P/s: i tried with IDA but it is difficult to understand it. Can it resolve my problem?.
To achieve this, you must have a very good understanding of Assembly Language, and maybe learning from NASM documentation and the Intel Instruction set will get you to a good level. Before you can continue in this path.
Furthermore, for those who already know little or more Assembly Language, is possible to call the function of an exe, mostly if they are standalone or doesn't depend on any other functions using something like Asmjit. And also you can get this function addresses, and cast them into functions if you know the calling convention used here. For example, __stdcall, __cdecl and others. And if then you know the calling convention, you can use this to construct the function signature, including the return type, usually through the POP, RETURN instruction or the registry that was affected before the function exit, or return to the caller.
You have to find a good debugger, to help you find all this. As you said IDA is good but too complicated, so you can use something like x86dbg, or others like ollyDbg those can help you find the entry point of those functions and use that to construct the signature
so a core like this, assuming that 0x749593 is an address of a a function with maybe takes two argument and return sum.
typedef int (*sum)(int first, int second);
Sum mySumFunc;
Changing the address of mySumFunc to point to 0x749593, you can call this function mySumFunc(arg1, arg2 ) and it will still work.
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.
How to concatenate string to the end of file or to specific place in the file?
And what the meaning of '*' in the folloing command:
write(10, *) 'blabla'
The * specifies the format that the program is to use for writing out your variables; it specifies list-directed output which means that the compiler is free to choose a sensible representation of your variables when it writes them. Your best approach to find out what your compiler decides is a sensible representation is to suck it and see; if you don't like what the compiler does, take charge by using edit descriptors.
The rest of your question makes little sense to me and I can't answer it.
Lua by default uses a double precision floating point (double) type as its only numeric type. That's nice and useful. However, I'm working on software that expects to see 64bit integers, for which I don't get around using actual 64bit integers one way or another.
The place where the integer type becomes relevant is for file sizes. Although I don't truly expect to see file sizes beyond what Lua can represent with full "integer" precision using a double, I want to be prepared.
What strategies can you recommend when using a 64bit integer type in parallel with the default numeric type of Lua? I don't really want to throw the default implementation overboard (and I'm not worried of its performance compared to integer arithmetics), but I need some way of representing 64bit integers up to their full precision without too much of a performance penalty.
My problem is that I'm unsure where to modify the behavior. Should I modify the syntax and extend the parser (numbers with appended LL or ULL come to mind, which to my knowledge doesn't exist in default Lua) or should I instead write my own C module and define a userdata type that represents the 64bit integer, along with library functions able to manipulate the values? ...
Note: yes, I am embedding Lua, so I am free to extend it whichever way I please.
As part of LuaJIT's port to ARM CPUs (which often have poor floating-point), LuaJIT implemented a "Dual-number VM", which allows it to switch between integers and floats dynamically as needed. You could use this yourself, just switch between 64-bit integers and doubles instead of 32-bit integers and floats.
It's currently live in builds, so you may want to consider using LuaJIT as your Lua "interpreter." Or you could use it as a way to learn how to do this sort of thing.
However, I do agree with Marcelo; the 53-bit mantissa should be plenty. You shouldn't really need this for a good 10 years or so.
I'd suggest storing your data outside of Lua and use some type of reference to retrieve it when calling your other libraries. You can then push various results onto the Lua stack for the user the see, you can even retrieve the value as a string to be precise, but I would avoid modifying them in Lua and relying on the Lua values when calling your external library.
If you're not going to need floating-point precision at any point in the program, you can just redefine LUA_NUMBER to __int64 (or whatever 64-bit int may be in your environment) in luaconf.h.
Otherwise, you can just bring in another library to handle your integers- for infinite precision, you can use a bignum library such as lhf's lbn.
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