On nvidia nvml library, some of the functions are defined in the header as below
nvmlReturn_t DECLDIR nvmlInit_v2(void);
nvmlReturn_t DECLDIR nvmlInitWithFlags(unsigned int flags);
#ifndef NVML_NO_UNVERSIONED_FUNC_DEFS
#define nvmlInit nvmlInit_v2
#endif
which means that nvmlInit could be an alias to another function through a macro.
I want to load this library (nvidia-ml.so) through dlopen since this library may not be available on machines that do not have a gpu setup
Since the #define nvmlInit may change from version to version, is it not recommended to use dlopen for nvml library?
If so is there an alternative so that my application can be run on machines that do not have libnvidia-ml.so
Related
We have some functions made available to us in iOS static library. There is a header (.h) and the compiled (.a) file. Is there any way that the functions in the static library can be called from a command line ( either OS X, Windows or Linux )? I have researched this for couple of days now and I am starting to doubt if this is even possible? We don't deal with Apple/iOS/xcode environment and the vendor only has this static library. Any hints? If it is possible in anyway I am open to reading any and very documentation but at this time I am in doubt if this is even possible? thanks
While checking out what is possible, I ran this
lipo -info libExaNumberCalc.a
I ran the above and it says
Architectures in the fat file: libExaNumberCalc.a are : i386 armv7 x86_64 arm64
Wonder if the above adds any hope?
The first thing that springs to mind is that you could write thin wrapper around your library function and build/run it. Something like
// main.c
#include "your_library_header.h"
int main(int argc, char *argv[])
{
// parse & pass parameters if necessary from command line
your_lib_function();
return 0;
}
Build with something like
clang main.c -o output.file -lyourlibrary
I can't find any information how to implement in C module of iOS Xcode project lseek() for large files:
llseek()
or
lseek64()
Compilation with:
#define _LARGEFILE64_SOURCE
#define _FILE_OFFSET_BITS 64
has no effect.
How is this possible to do?
You need to use fseeko() and ftello() when seeking to specific 64bit offsets in a file. Pass the file offset as a off_t instead of int and it will work on both 32bit and 64bit systems.
Just for educational purposes, I would like to add a function to an existing iPhone app, written in ARM assembly. I don't need a tutorial on ARM assembly in general, because I already read too many of them. I just don't know how to actually run the code!
What I would like to do is something like:
useless.h:
void useless();
useless.s:
useless:
bx lr
If this also works on the simulator it would be fine... On the simulator, the .s file would not compile, so I should maybe do something like:
useless.s:
#if I_AM_ARM
useless:
bx lr
#endif
useless.c:
#if !I_AM_ARM
void useless()
{
}
#endif
I know the syntax I use is broken, but how do I write it correctly? (Breaking an app on the simulator just because I want to try some inline assembly is no option...)
The second-best option would be to use inline assembly, but I would strongly prefer non-inline assembly.
Thanks!
Edit: I want to learn ARM assembly, so I would like to find a method to compile ARM assembly code, and to EXECUTE ARM assembly code.
I finally found the answer myself. It's actually not that hard. I only solved it for the 32-bit ARM version though.
useless.h:
void useless();
useless.s:
#ifdef __arm__
.syntax unified
.globl _useless
.align 2
.code 16
.thumb_func _useless
_useless:
//.cfi_startproc
bx lr
//.cfi_endproc
// CFI means Call Frame Information
// Optionally. Use for better debug-ability.
#endif
useless.c:
#ifndef __arm__
void useless()
{
}
#endif
Notes:
The CLANG ARM Assembler syntax is a bit different from what you see in example all over the web. Comments start with // and /* multiline comments */ are also supported. It also understands the standard C preprocessor. The function has to be defined as a Thumb function, if you specify an arm function (.code 32) the program will just crash. The line .thumb_func _useless can be ommited and it works still. I have no Idea what it means. If you omit the .code 16 line, the program crashes.
about the #ifdef. For ARMv7, __arm__ is defined. For ARMv8, i.e. the 64bit-variant on the iPhone 5S, __arm__ is not defined, but __arm64__ is defined instead. The above code does not work for the 64bit-ARM-version. Instead, the implementation from useless.c will be used. (I didn't forget ARMv7s, I just don't have a device with that arch in my hands currently, so I cannot test.)
The simulator doesn't use arm. you'll have to write x86_64 assembly if you want it to run on the simulator. (probably).
The best way to learn is to take a look at actual working examples, see my blog post about ARM iOS timing. This example Xcode project shows how to mix ARM ASM and C impls of a function. There is also a very accurate timing module to run your code N times, because accurate timing is the hard part when it comes to optimizing the code.
You can emulate ARM-Ubuntu with QEmu (there are some Windows ports of it, e.g. http://lassauge.free.fr/qemu/ ). If you are on Windows, you may need to emulate x86_64-Ubuntu in the middle. To create an ARM image you can follow the steps from this question: Black screen in QEmu for ARM-Ubuntu (how to get GUI?) (yes, unfortunately, you get no GUI with these steps, just a console to the ARM-Ubuntu machine, and you have to do the steps from Ubuntu). Then you can cross-compile your C++/C/Assembly programs from Windows/Ubuntu host to ARM-Ubuntu target.
clang++.exe -Wall test1.cpp -o test1exe -std=c++14 -Ipath-to-arm-linaro/arm-linux-gnueabihf/include/c++/5.3.1 -Ipath-to-arm-linaro/arm-linux-gnueabihf/include/c++/5.3.1/arm-linux-gnueabihf -ffunction-sections -fdata-sections --sysroot=path-to-arm-linaro/arm-linux-gnueabihf/libc --target=arm-unknown-linux-gnueabihf -Bpath-to-arm-linaro/arm-linux-gnueabihf/bin/
For cross-compilation you would need to download and roll out a toolchain, e.g. gcc-linaro-5.3-2016.02-i686-mingw32_arm-linux-gnueabihf.tar.xz (Windows/MinGW) from https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/ and replace "path-to-arm-linaro" in the above command with the path to the toolchain.
I just started working with iOS. The first thing I tried to do was add asm code to my project and ran into the same problem. The static data is handled slightly differently in 64-bit mode. I discovered how to do it by looking at the assembler output of the compiler. The same .S file will be compiled as both 32 and 64-bit in Xcode, so prepare it like this:
.globl _myfunction
.align 2
my_constant_data:
.byte 0,1,2,3,4,5,6,7
#ifdef __arm__
.thumb_func _myfunction
.syntax unified
.code 16
//
// call from C as my myfunction()
//
_myfunction:
ldr r0,=my_constant_data
< write your thumb-2 code here >
bx lr
#else // or you can use #ifdef __arm64__
//
// Call from C as myfunction()
//
_myfunction:
adrp x0, my_constant_data#PAGE
add x0,x0, my_constant_data#PAGEOFF
< write your Armv8 code here >
ret
#endif
What is a good way to load a GLSL shader using C/C++ without using Objective-C or any Apple APIs?
I am currently using the following method, which is from the iPhone 3D Programming book, but it says that it is not recommended for production code:
Simple.vsh
const char* SimpleVertexShader = STRINGIFY
(
// Shader code...
);
RenderingEngine.cpp
#define STRINGIFY(A) #A
#include "Simple.vsh"
// ...
glShaderSource( shaderHandle, 1, &SimpleVertexShader, 0 );
If you want to load your shaders from files in your app bundle, you can get the file paths using the NSBundle object (in Objective-C), or using the CoreFoundation CFBundle object (in pure C).
Either way, you are using Apple-specific APIs. The only thing you're getting by using CFBundle instead of NSBundle is more boilerplate code.
If you don't want to use any Apple APIs, then your options are to embed your shaders as literal strings, or connect to a server on the Internet and download them (using the Unix socket API).
What you really need to do is define an interface by which your RenderingEngine gets the source code for its shaders, and implement that interface using the appropriate platform-specific API on each platform to which your port the RenderingEngine. The interface can be something super simple like this:
RenderingEngineShaderSourceInterface.h
#ifdef __cplusplus
extern "C" {
#endif
// You are responsible for freeing the C string that this function returns.
extern char const *RenderingEngine_shaderSourceForName(char const *name);
#ifdef __cplusplus
}
#endif
Then you create RenderingEngineShaderSource_Windows.cpp, RenderingEngineShaderSource_iOS.m, RenderingEngineShaderSource_Linux.cpp, etc. Each one implements RenderingEngine_shaderSourceForName using the appropriate API for that platform.
I use one of two methods. If it's a short shader, I may just put it code:
const char shader[] =
"uniform vec4 blah;\n" // Note, no semicolon here - it does the right thing
"main ()\n"
"{\n"
...rest of code
"}\n";
Or, if it's longer or going to be re-used in other places, I'll put it into a text file in the resources and read the text file at run time. You can get to it via [NSBundle pathForResource:ofType:].
Consider a C++ raw string literal; no STRINGIFY is needed since the newer features of C++ allow you to do similar things without macro.
I'd retype a good example but here is one.
I followed Claus's post to set up code coverage on Xcode 4.2 with LLVM 3.0. I'm able to see test coverage files, but they're only for my unit test classes, not my actual project classes. I've tried setting Generate Test Coverage Files and Instrument Program Flow to Yes on my main target, but that didn't help, as it failed with the following error:
fopen$UNIX2003 called from function llvm_gcda_start_file
To clarify, I don't think that's even the right approach - I just tried it to see if it would generate code coverage on my project classes.
At this point, I'd be happy to try anything that gets code coverage working on my app. Any suggestions?
You are expecting linker problem, profile_rt library uses fopen$UNIX2003 and fwrite$UNIX2003 functions instead of fopen and fwrite.
All you need is to add the following .c file to your project:
#include <stdio.h>
FILE *fopen$UNIX2003( const char *filename, const char *mode )
{
return fopen(filename, mode);
}
size_t fwrite$UNIX2003( const void *a, size_t b, size_t c, FILE *d )
{
return fwrite(a, b, c, d);
}
This code just remaps the missing functions to standard ones.
Note on $UNIX2003 suffix:
I've found an Apple document saying:
The UNIX™ conformance variants use the $UNIX2003 suffix.
Important: The work for UNIX™ conformance started in Mac OS 10.4, but was not completed until 10.5. Thus, in the 10.4 versions of libSystem.dylib, many of the conforming variant symbols (with the $UNIX2003 suffix) exist. The list is not complete, and the conforming behavior of the variant symbols may not be complete, so they should be avoided.
Because the 64-bit environment has no legacy to maintain, it was created to be UNIX™ conforming from the start, without the use of the $UNIX2003 suffix. So, for example, _fputs$UNIX2003 in 32-bit and _fputs in 64-bit will have the same conforming behavior.
So I expect libprofile_rt to be linked against 10.4 SDK.
I use CoverStory http://code.google.com/p/coverstory/ a GUI for .gcda and .gcno files.
The documentation explains the settings needed to generate these files http://code.google.com/p/coverstory/wiki/UsingCoverstory.