I'm running linux and I want to access /proc/kallsyms from outside the OS. I'm writing an SMM driver (EDK2) that's written in C, but I cannot use stdio functions like fopen, because compiler (GCC) says
undefined reference to "fopen"
even though I use #include <stdio.h> and other packages within EDK2 use stdio (go figure \o/)
So I'm wondering is there a way I can access /proc/kallsyms without using functions like fopen or open (which btw I tried to use, same error) ??
It'd need to be "pure C" -ish, if you know what I mean, given that it would not be executed on OS level. Any help or suggestion would be appreciated.
Related
i have been working with platformio for a few weeks now and have been able to create quite a bit for my microcontroller (atmega328p). I have always tried to get away from the Arduino structure. So no “void setup” or “void loop” but simple C.
Now I got a ESP8266, which I would like to compile with a C environment.
When I create the project now (for the 12E) it asks which framework I should use. I have tried them all by replacing the Arduino setup and loop with the int main(){} function, however it always came up with errors. Does anyone know how I can use a pure C environment for the ESP8266?
I am using boost::interprocess to implement an IPC mechanism based on shared memory. I want this to be cross platform (including windows), and the build system is autotools. On some platforms boost::interprocess requires that you link with the library librt which implements some threading functions, but not on windows, or apple platforms (I think). See the following link:
http://www.boost.org/doc/libs/1_64_0/doc/html/interprocess.html#interprocess.intro.introduction_building_interprocess
Now, in autotools I can do things conditionally depending on the host being windows, but it would be better to test if the required functions are available using AC_SEARCH_LIBS. The AC_SEARCH_LIBS macro first checks if the functions are available with no libraries, then using a provided list of libraries in sequence.
To do the test, I need to know what functions to search for.
To be even more specific I need to use the following headers in my program:
#include <boost/interprocess/managed_shared_memory.hpp>
#include <boost/interprocess/sync/interprocess_mutex.hpp>
#include <boost/interprocess/sync/interprocess_condition.hpp>
#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/interprocess/containers/vector.hpp>
So what functions in librt are required by these headers, or what is the easiest way to find this out?
I am trying to get luasocket working in the lua scripting environment of Bizhawk, but so far without luck. I downloaded the vc8 version of luasocket here, made sure I have vc8 installed, and checked the lua version that came with bizhawk: 5.1
But, when I start the script I get the following error:
LuaInterface.LuaScriptException: error loading module 'socket.core' from file './libs/socket\core.dll':
Das angegebene Modul wurde nicht gefunden. (the given module was not found)
The lua code:
package.path = package.path..';./libs/lua/?.lua'
package.cpath = package.cpath..';./libs/?.dll'
local socket = require("socket")
The file system structure:
libs
> lua
> socket
ftp.lua http.lua smtp.lua tp.lua url.lua
ltn12.lua
mime.lua
socket.lua
> socket
core.dll
> mime
core.dll
It seems to find the files, because when I had the file structure wrong it gave me actual file-not-found errors.
My best guess is that there is some kind if incompatibility between the lua that is shipped with Bizhawk and the external luasocket library binaries, but I am out of ideas.
This guy's set it up: https://github.com/antogerva/emuHostUDP (dearchive to emuhawk.exe base directory). His example seems to work, but it might not contain everything you need. Like HTTP for example.
Since project is complex and the luasockets examples are awful, here's a one-liner for testing http:
print(require("socket.http").request{ url = "http://www.google.com" });
Following his model, I applied the following method: contents of lua dir to root; lua5.1.dll to root. Note that we will not be using the core.dlls from luasockets. This is because BizHawk now has them integrated; and this was necessary to work around a bug with luasockets in bizhawk.
More specifically, we have
/emuhawk.exe
/Lua (untouched)
/Socket/ftp.lua,http.lua,etc.
/ltn12.lua,socket.lua,mime.lua
/lua5.1.dll
/mytest.lua
(with files from http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip)
I can't say why precisely all of this is necessary, but I think it's miraculous that it works, given that we have a customized lua.
When using lua, if you find a directory structure that works, it's best not to wrestle with it any further.
Update:
(may be out of date) As soon as you do something nontrivial you may find bizhawk crashes. It seems this is due to a conflict with luasocket's "protection" system. Inspect http.lua and observe the code at the end which sends a function through socket.protect to wrap it. Remove the socket.protect wrapper and it should solve this problem.
I suspect that it's because of the dependence on lua51.dll. luasocket core.dll library is linked against lua51.dll (most likely; you can ran depends or similar tool to find out for sure), which is probably not present and this prevents socket.core from being loaded.
Even if you find lua51.dll, it's not likely to work if Bizhawk is statically compiled with lua51.dll as this will lead to two interpreters loaded into the same process, which is a recipe for seg faults.
There are three main options, but they all depend on how Bizhawk project is structured:
Bizhawk is compiled against lua51.dll (and this dll is present as a standalone file). In this case you need to make sure that the socket/core.dll you are using is compiled against the same library and it should work (as long as the run-times are the same and lua51.sll is available in PATH).
Bizhawk is statically compiled with lua51.dll. The simplest option is also statically compile luasocket libraries into the executable.
If option 2 is not available, then you need to use a proxy library and export Lua symbols from the Bizhawk executable as described in this SO answer: https://stackoverflow.com/a/28310666/1442917
If none of this helps you to solve the problem, you'll need to get depends for your Windows platform and run it in the "profiling" mode, which will tell you the exact error that happens when that DLL is loaded.
While discussing OpenCOBOL being utilized for FastCGI, I posted that replacing
#include <stdio.h>
with
#include <fcgi_stdio.h>
should exhibit no behaviour change for the vast majority of programs that don't care to call
FCGI_Accept()
Did I lie? Are there issues to consider? I'll admit to having not gone over sources yet, only docs from the website.
EDIT: 2013-03-08
I've done some experiments, and the statement is proving positive, but lack sufficient evidence to advertise the statement as true. I'd still appreciate any insider information.
As fcgi_stdio.h is redefining many stdio symbols to its own set of FCGI_* symbols, there will with certanity be some differences. Fastcgi also offers the possibility to #define NO_FCGI_DEFINES though, which lets you use both sets - although you'd have to be explicitly specifying the FCGI_ prefix.
I was just thinking about adding a way to determine which set is to use at runtime to be able to use the same binaries online and from cli, but thinking further about it I'll rather go with two make targets.
Also, compiling with libfcgi-dev v2.4.0 I seem to run into blank output in conjunction with -ldl / dlopen() although both binaries link to the same libfcgi.so.0...
--
tl;dr if you want to use dlopen() and see the output on stdout/stderr, don't #include <fcgi_stdio.h> (without defining NO_FCGI_DEFINES)
I am completely new to CUDA and C. My eventual goal is to adapt a FORTRAN program for CUDA. For now, I am having trouble getting a simple "Hello world" program to run.
I have been able to compile using nvcc hello_test.cu --machine32 which creates an executable. However when I try to run the .exe, I get a System Error message stating:
The program can't start because cudart32_32_9.dll is missing from your computer. Try reinstalling the program to fix this problem
I imagine I haven't added the path to this file (which I can find in "C:\ProgramData\NVIDIA Corporation\NVIDIA GPU Computing SDK 4.2\C\common\bin\"); but I don't know how to add the path. Any help would be appreciated.
You can go several routes. Either just make a copy of the DLL and put it in the same directory as your executable.
Or you can add the path you mentioned in the PATH environment variable of Windows. Then it should be able to find the DLL.