I know this is an odd question, but I'm wondering if this is possible. Is there any method by which code (which would be typed by a user) could be run during runtime? For example, suppose I would allow the user to type in some Core Graphics drawing code. I would want this code to be run in a drawRect method of my preview pane.
So what I would have to do would be to convert this group of strings into actual runtime code.
Is this even possible, or am I just wasting my time?
I see a few solutions:
Create a language of your own, and parse it in-application
If on mac, you could theoretically, create a function stub from what they enter in, and use GCC shipped with the application to compile the code at runtime into a dylib, and then use dylib functions to run the function you created.
On a Mac, you can have your app send text to the compiler (several come with Xcode), have the code compiled, and run the compiled result as a slave app (controlled via a socket, for instance, and copying the preview pane image pixels back via a pipe). If needed you could convert the source code text using some sort of preprocessor and wrap it in your own run-time shell.
Alternatively you could write or port a C language interpreter (there are several open source interpreters for various subsets of C), and plug Core Graphics library calls into the C interpreter's parser and run-time engine.
I do not know of a full interpreter for Objective C.
Related
I'm trying to use Vulkan on MacOS, with the eventual goal of making a cross platform program. My program worked when I statically linked MoltenVK (with the vulkan headers copied into it).
My current setup statically links vulkan.framework, and uses an ICD to load libMoltenVK.dylib. This initially appeared to work: in the logs, I can see "INFO: Found ICD manifest file [expected path to my manifest file]". All the extensions I expect are then found and listed, including VK_KHR_surface. I enable it when I create my VkInstance.
I can call various vulkan functions successfully, including vkCreateMacOSSurfaceMVK. However, when I try to call vkGetPhysicalDeviceSurfaceCapabilitiesKHR, my program crashes.
With no validation layers, it seems like vulkan loads the wrong function: the next symbol in the call stack is vkCreateQueryPool instead of the expected vkGetPhysicalDeviceSurfaceCapabilitiesKHR, and MoltenVK prints [***MoltenVK ERROR***] VK_ERROR_INITIALIZATION_FAILED: vkCreateQueryPool: Unsupported query pool type: -1094795586. The program crashes on the next vulkan call, which happens to be vkGetPhysicalDeviceSurfaceFormatsKHR, but which actually calls into MVKDevice::destoryQueryPool.
With validation layers on, the program crashes on vkGetPhysicalDeviceSurfaceCapabilitiesKHR, which tries to call 0x0. There are no errors printed about validation failing for any of them.
I tried turning on Dynamic Linker API usage/ Dynamic Library loads in Xcode's scheme editor, but I didn't find the information they provided helpful.
Why would vulkan/dyld not hook up some functions correctly? How can I debug this?
You are actually using the Vulkan Loader, not an "ICD", to load libMoltenVK.dylib. libMoltenVK.dylib itself is considered an Installable Client Driver (ICD).
Are you using vkGetInstanceProcAddr() to get the function address of vkGetPhysicalDeviceSurfaceCapabilitiesKHR() ? The Vulkan Loader only exports the core (and some WSI) functions. You'll need to get the addresses of other extension functions with vkGetInstanceProcAddr().
See this code for an example of using GIPA. Search for "vkGetPhysicalDeviceSurfaceCapabilitiesKHR". vulkaninfo calls this extension successfully on MacOS.
I suspect that the MoltenVK lib exports this extension function directly, which is why it worked when you statically linked MoltenVK. Also, when using the Vulkan loader, you should not be linking the MoltenVK library to your application. The Vulkan loader loads it for you.
Context:
I'm trying to automate some of the more mundane tasks in embedded development with Keil. The end result I'm aiming for is that clicking build in a Keil project will run a pre-build step that runs all the code through Uncrustify (a source code beautifier) to ensure it conforms to the company style-guide, and a post-build step which then runs the code through pc-lint (a static code analyser) to highlight any potentially unsafe code that it might find. I've written a PC utility that searches through the .uvproj file for the #define macros, the include paths and the file-paths all of which are needed for both tools and then modifies the pre and post-build user commands to call up my batch files which will manage both steps. The uncrustify part is working fine and the lint part is producing some sensible messages, but the signal-to-noise ratio isn't that great.
My problem:
Lint keeps on producing messages that seem to relate to macros that the Keil compiler is aware of, but that Lint isn't. I'm trying to find a way to plug that gap. I found a table of predefined macros documented on the Keil website, which seems like a good start, but rather than manually copying them into a static .lnt file, I'd like to find a way of grabbing the up-to-date values at the time the project gets built. This way, the "__ARMCC_VERSION" macro, for instance, would be updated whenever the developer updates his/her Keil compiler, rather than being stuck at a point in time whenever I manually copied it.
I'd love it if someone can answer my question directly, but I'd be equally pleased if someone has a viable suggestion for a more straightforward alternative approach I could try instead. Many thanks!
I am assuming you're using the Keil ARM Compiler.
From the Compiler User Guide:
To list macros that are defined on the command line, predefined by the compiler, and found in header and source files, use --list_macros with a non-empty source file.
To list only macros predefined by the compiler and specified on the command line, use --list_macros with an empty source file.
EDIT:
It looks like your SDK also adds a few macros.
From the µVision User's Guide:
The following control strings are added, depending on the use of MDK:
__UVISION_VERSION:
Major and minor version of µVision. For example: -D__UVISION_VERSION="520".
RTE:
Set when RTE is in use. For example: -D_RTE_.
__RTX:
Set when RTX Kernel has been selected in Options for Target - Target - Operation System. Not set when using RTE. For example: -D__RTX.
__MICORLIB:
Set when Use MicroLIB has been enabled in Options for Target - Target. For example: -D__MICROLIB.
__EVAL:
µVision runs in evaluation mode. License MDK-Lite. For example: -D__EVAL.
device header name:
Device header name.
I am trying to load a dll (it's not my dll) and it's written in C++
There are no exports to my knowledge, but it does what I need it to do once loaded.
assert(package.loadlib(dllfile,'')()
This throws an error, obv, "procedure not found" but the dll is still loaded, and works as intended.
if I call the above function a 2nd time, it crashes the client, so I need a checker of some sort.
my question is, is there a way to verify it's loaded?
In Lua 5.1 when using package.loadlib as the second argument you must specify the name of a function actually exported by the DLL. It is not important which, if you only need to force the Windows dynamic linker to load the DLL (that seems your case).
To discover such names you can use DependencyWalker (free tool). Open the DLL using depend.exe and look at the export function list panel (the first column has an E header label). Choose any function and use its name as the second argument (If it really doesn't have exported functions you are out of luck!). Try to choose a function labeled as C (not C++). C++ exported functions have mangled names that could cause problems.
For example, say you want to load kernel32.dll: using depend.exe you can discover that among all the exported functions there is one named AddAtomA (but any other C function would do). So you could use package.loadlib in this way:
assert( package.loadlib( "kernel32.dll", "AddAtomA" ) )
The assert call ensures that if the DLL cannot be loaded an error is issued.
To verify a DLL is actually loaded you can use ProcessExplorer (another free tool).
Make sure your script is running (you can put an io.read() statement in a suitable place to keep your script from terminating),
then open ProcessExplorer window,
select the process relative to your script (probably some lua.exe, but you can drag the "target" tool on ProcessExplorer toolbar to your script window to discover it)
and type ctrl-D.
A lower panel should appear showing all the DLLs that the selected process is using. Browse the list to see if your DLL is listed.
Hope this helps.
What are the differences between the byte code binary executables such as Java class files, Parrot bytecode files or CLR files and machine code executables such as ELF, Mach-O and PE.
what are the distinctive differences between the two?
such as the .text area in the ELF structure is equal to what part of the class file?
or they all have headers but the ELF and PE headers contain Architecture but the Class file does not
Java Class File
Elf file
PE File
Byte code is, as imulsion noted, an intermediate step, right before compilation into machine code. Because the last step is left to load time (and often runtime, as is the case with Just-In-Time (JIT) compilation, byte code is architecture independent: The runtime (CLR for .net or JVM for Java) is responsible for mapping the byte code opcodes to their underlying machine code representation.
By comparison, native code (Windows: PE, PE32+, OS X/iOS: Mach-O, Linux/Android/etc: ELF) is compiled code, suited for a particular architecture (Android/iOS: ARM, most else: Intel 32-bit (i386) or 64-bit). These are all very similar, but still require sections (or, in Mach-O parlance "Load Commands") to set up the memory structure of the executable as it becomes a process (Old DOS supported the ".com" format which was a raw memory image). In all the above, you can say , roughly, the following:
Sections with a "." are created by the compiler, and are "default" or expected to have default behavior
The executable has the main code section, usually called "text" or ".text". This is native code, which can run on the specific architecture
Strings are stored in a separate section. These are used for hard-coded output (what you print out) as well as symbol names.
Symbols - which are what the linker uses to put together the executable with its libraries (Windows: DLLs, Linux/Android: Shared Objects, OS X/iOS: .dylibs or frameworks) are stored in a separate section. Usually there is also a "PLT" (Procedure Linkage Table) which enables the compiler to simply put in stubs to the functions you call (printf, open, etc), that the linker can connect when the executable loads.
Import table (in Windows parlance.. In ELF this is a DYNAMIC section, in OS X this is a LC_LOAD_LIBRARY command) is used to declare additional libraries. If those aren't found when the executable is loaded, the load fails, and you can't run it.
Export table (for libraries/dylibs/etc) are the symbols which the library (or in Windows, even an .exe) can export so as to have others link with.
Constants are usually in what you see as the ".rodata".
Hope this helps. Really, your question was vague..
TG
Byte code is a 'halfway' step. So the Java compiler (javac) will turn the source code into byte code. Machine code is the next step, where the computer takes the byte code, turns it into machine code (which can be read by the computer) and then executes your program by reading the machine code. Computers cannot read source code directly, likewise compilers cannot translate immediately into machine code. You need a halfway step to make programs work.
Note that ELF binaries don't necessarily need to be machine/arch specific per se.
The interesting piece is the "interpreter" header field: it holds a path name to a loader program that's executed instead of the actual binary. This one then is responsible for loading the actual program, loading and linking libraries, etc. This is the way how eg. ld.so comes in.
Theoretically one could create an ELF binary that holds java bytecode (or a complete jar). This just needs some appropriate "interpreter" program which starts up a JVM and loads the code from the binary into it.
Not sure whether this actually has been done before, but certainly possible.
The same can be done w/ quite any non-native code.
It also could serve for direct multiarch support via some VM like qemu:
Let the target platform (libc+linker scripts) put the arch name into the interpreter program name (eg. /lib/ld.so.x86_64, /lib/ld.so.armhf, ...).
Then, on a particular arch (eg. x86_64), the one with native arch name will point to the original ld.so, while the others point to some special one that calls up something like qemu-system-XXX.
I'm writing a Cocoa application and I'm trying to link it with the MATLAB Engine to call MATLAB functions. So far I've added the .app/extern/include/ directory (the one that contains the engine.h header) to the header search paths (and subsequently #imported engine.h) and added the .app/extern/lib/maci64 directory to the library search paths (though that doesn't really do anything). I've been looking through the MATLAB documentation and it looks like MATLAB has its own compiler 'mex' for MATLAB engine applications… but clearly that doesn't work for a Cocoa app (and anyway, on my system, the 'mex' command starts PDFTex and has nothing to do with MATLAB). Also, the engine libraries in that directory are in an odd format (.map) which seems to be a debugging symbol file and not a normal Mac library (dylib, a, framework, etc.). Thoughts?