In what order are x64 arguments pushed on to the stack:
in the System V ABI?
in the Windows ABI?
I am writing a Java FFI library that uses dynamically generated stubs and these stubs depend on this order.
I suspect that it is "floats first" but am not sure.
From System V ABI, Section 3.2.3:
Once registers are assigned, the arguments passed in memory are pushed on
the stack in reversed (right-to-left) order.
Windows x64 ABI is very informal and it is doesn't specify the order of the stack parameters.
However from Wikipedia and common sense we can reach the same conclusion as above:
Additional arguments are pushed onto the stack (right to left)
Related
Specifically, lines similar to:
<my-package>.-$$Lambda$<my-class>$TBpBoCodhQrLRrW-jmx762QZ0VY.run(Unknown Source:2)
<my-package> and <my-class> were obviously replaced.
Perhaps there are some options to R8 to preserve pertinent information?
The classes with names starting with -$$Lambda$ are generated by R8 (and D8) when desugaring Java lambdas. These are synthetic classes, and they have no corresponding item in the input program. Normally a -$$Lambda$ will not be on the top of stack, as they will always call the lambda$xxx method generated by javac which has references back to the original source.
If you are using retrace.jar from ProGuard, please make sure to use a recent version which supports inline frames in the mapping file. Version 6+ should work.
I have a question related to V4L-DVB drivers. Following the
Building/Compiling the Latest V4L-DVB Source Code link, there are 3 ways to
compile. I am curious about the last approach (More "Manually
Intensive" Approach). It allows me to choose the components that I
wish to build and install using the "make menuconfig". Some of these components (i.e. "CONFIG_MEDIA_ATTACH") are used in pre-processor directives that define a function in one shape if defined, and a function in another if not defined (i.e.
dvb_attach, dvb_detach) in the resulting modules (i.e. dvb_core.ko)
that will be loaded by most of the DVB drivers. What happens if there are two
drivers (*.ko modules) on the same host machine, one that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH defined and another that needs dvb_core.ko with
CONFIG_MEDIA_ATTACH undefined, is there a clean way to handle this?
What is also not clear to me is: Since the V4L compilation environment seems very customizable (by setting the .config file), if I develop a driver using V4L-DVB structures, there is a big chance that it has conflicts with other drivers since each driver has its own custom settings. Is my understanding correct?
Thanks!
Dave
I've seen several conflicting descriptions of how to do this around the google results, and haven't been able to get any of them to work.
My problem is basically this: where I call ExecutionEngine::getPointerToFunction (with an llvm::Function*), I'd like to instead get the pretty-printed x86 assembly that would be produced for this function.
Anybody?
[ETA: I'm using LLVM 3.3. The descriptions I've found seem to be for earlier versions of LLVM.]
It turns out that you can add an event listener to a JIT ExecutionEngine with ExecutionEngine::RegisterJITEventListener. If you provide an instance of that class, you can have your callback invoked when machine code is generated for you, and you'll be given a pointer to the machine code and its length. With this, you can call llvm::sys::disassembleBuffer to get a description of the machine code buffer.
However, the llvm::sys::disassembleBuffer function just defers to the udis library if LLVM was compiled with that support. Since my build of LLVM didn't have this flag set and I can't rebuild it, I'll just look into using the udis library directly:
https://github.com/vmt/udis86
I'm trying to run an algorithm that requires a few hundred megabytes of memory within eclipse, and I've specified VM arguments -Xmx512m, but I can't get past some arbitrary memory limit which seems to decrease as I continually try to run my programs. Physical memory is fine...what could be the issue?
Eclipse takes VM arguments, but those are for the Eclipse platform itself, you need to modify the applications Launch Configuration to ensure it has enough memory.
When you run a program within Eclipse it creates a new Launch Configuration with default parameters. You can modify those parameters by selecting Run->Run Configurations.. (or Debug->Debug Configurations...), then select the relevant configuration. If it is a Java main app, the configuration will be under Java Application, probably with the name of the class or project you selected when you first ran it.
Select the launch configuration, then the Arguments tab, then enter the relevant JVM arguments (i.e -Xmx512m) in the VM arguments pane. You can also enter Program arguments to pass to the main method if you wish.
(source: modumind.com)
Update: another parameter to try passing is -XX:MaxPermSize=128m, if your algorithm is creating lots of method and/or class objects (which sounds like it is the case).
Look at the arguments -Xms too. Be sure that the argument is specify to your Run mode ( Run / debug).
If you still have some problem, you can use a profiler to see what happen in memory, or just logging the Runtime.getRuntime().freeMemory() can help.
You should ensure that you are specifying the arguments for your test application in the Run Dialog, and not in arguments to Eclipse itself.
os i figured out how to use the -mthumb and -mno-thumb compiler flag and more or less understand what it's doing.
But what is the -mthumb-interlinking flag doing? when is it needed, and is it set for the whole project if i set 'compile for thumb' in my project settings?
thanks for the info!
Open a terminal and type man gcc
Do you mean -mthumb-interwork ?
-mthumb-interwork
Generate code which supports calling between the ARM and Thumb
instruction sets. Without this option the two instruction sets
cannot be reliably used inside one program. The default is
-mno-thumb-interwork, since slightly larger code is generated when
-mthumb-interwork is specified.
If this is related to a build configuration, you should be able to set it separately for each configuration "such as Release or Debug".
Why do you want to change these settings? I know using thumb instructions save some memory but will it save enough to matter in this case?
my application uses both, thumb and vfp code but i never specifically
set -thumb-interwork flag.. how is that possible?
According to man page, without that flag the two instructions sets
cannot be reliably used inside one program.
It says "reliably"; so without that option, it seems they still can be mixed within a single program but it might be "unreliably". I think normally mixing both instructions sets works, the compiler is smart enough to figure out when it has to switch from one set to another one. However, there might be border cases the compiler just doesn't understand correctly and it might fail to see that it should switch instruction sets here, causing the application to fail (most likely it will crash). This option generates special code, so that no matter what your code does, the switching always happens correctly and reliably; the downside is that this extra code is needed for every global visible function and thus increases the binary side (I have no idea if it also might slow down function calls a little bit, I personally would expect that).
Please also note the following two settings:
-mcallee-super-interworking
Gives all externally visible functions in the file being
compiled an ARM instruction set header
which switches to Thumb mode before executing the rest of
the function. This allows these
functions to be called from non-interworking code.
-mcaller-super-interworking
Allows calls via function pointers (including virtual
functions) to execute correctly regardless
of whether the target code has been compiled for
interworking or not. There is a small overhead
in the cost of executing a function pointer if this option
is enabled.
Though I think you only need those, when building libraries to be used with other projects; but I don't know for sure. The GCC thumb handling is definitely "underdocumented".