In my understanding, DeviceIOControl and ioctl are the same functions. They both send control codes to the hardware and return the responses. In an effort to reuse code, I am trying to create a function which will work in a cross-platform manner. Therefore, I've decided to use the DeviceIOControl api since it is fixed and specific. The problem is: how do I map ioctl to that?
I currently have:
int DeviceIoControl_issueCommand(DeviceHandle handle, int command, void *input, ssize_t sizeof_input, void *output, ssize_t sizeof_output, uint32_t *bytes_written){
#if SYSTEMINFORMATION_ISWINDOWS
int result = DeviceIoControl(handle,command,input,sizeof_input,output,sizeof_output,bytes_written,0);
if (result == 0){
result = -1; //-1 is the new error return
}
return result;
#else
int result = ioctl(handle, command, input); //this doesnt work!
return result;
#endif
}
Any help is greatly appreciated!
What you are asking is not possible without a lot of internal translation in DeviceIoControl_issueCommand. The function calls are completely different and expect different parameters and data. You can work around this by declaring an IOControl class and adding member functions for each type of IO functionality you want to support.
class IOControl
{
public:
void DoIoControlX();
void DoIoControlY(int param1, int param2);
};
Then provide an impelementation for each platform you need to support. One for Windows DeviceIOControl calls and one for systems that support ioctl
I actually found that there is an IOCTL which does pass raw data to and from the driver (at least for the hard drive): HDIO_DRIVE_TASKFILE (http://www.mjmwired.net/kernel/Documentation/ioctl/hdio.txt)
Related
so I have been writing some code and finished it, all I had left to do was send it over SPI. However, I didn't realise that the SPI library I am using only accepts const uint_16t data. I tried setting up a temp variable of the correct data type and using a reference to send over SPI, which works, but because it is a const variable it cant change, which is something I need it to be able to do.
Below is my code, any help with this would be great, for reference this is done in C++ and uses SPI library is part of the Raspberry Pi Pico SDK (the code is cut down as is long so only needed parts included). I did try to use pointers to change the const variable which I think you can do in C but I couldn't get it to work in C++.
Any help with this would be greatly appreciated as I am very stuck as with how to go about fixing this.
Thanks,
Dean
class Frequency_Values{
Public:
static uint16_t position;
//constructors and special member functions here
private:
uint16_t MSB_LUT[401];
uint16_t LSB_LUT[401];
};
//----------static variable definition---------------------
unsigned short Frequency_Values::position = 0;
//---------------------------------------------------------
//-------------------get function definitions--------------
uint16_t Frequency_Values::get_MSB_LUT_Value()
{
return (Frequency_Values::MSB_LUT[position]);
}
uint16_t Frequency_Values::get_LSB_LUT_Value()
{
return (Frequency_Values::LSB_LUT[position]);
}
//-----------------------------------------------------------
Frequency_Values MSB, LSB;
int main(){
while(1){ // to show code runs multiple times
//--------------------------------------------------
const uint16_t LSB_Holder = LSB.get_LSB_LUT_Value(); // this is what I tried to get it in the correct data type
//which worked but as const the value wont change
const uint16_t MSB_Holder = MSB.get_MSB_LUT_Value();
//--------------------------------------------------
}
spi_write16_blocking(SPI_PORT, &LSB_Holder, 1);
spi_write16_blocking(SPI_PORT, &MSB_Holder, 1);
}
This was eventually fixed by just removing the const specifier inside of the pico sdk, spi library.
I have a function like this:
typedef long long myint64;
typedef enum {
INT32_FIELD,
CHARP_FIELD,
INT64_FIELD,
} InfoType;
int32_t ReadInfo(void *handle, InfoType info, ...)
{
va_list arg;
va_start(arg, info);
void *argPtr = va_arg(arg, void*);
va_end(arg);
int32_t ret = 0;
int32_t *paramInt = NULL;
char **paramCharp = NULL;
myint64 *paramInt64 = NULL;
switch (info) {
case INT32_FIELD:
paramInt = static_cast<int32_t*>(argPtr);
*paramInt = functionWhichReturnsInt32();
break;
case CHARP_FIELD:
paramCharp = static_cast<char**>(argPtr);
*paramCharp = functionWhichReturnsCharPtr();
break;
case INT64_FIELD:
paramInt64 = static_cast<myint64*>(argPtr);
*paramInt64 = functionWhichReturnsInt64();
break;
default:
ret = -1;
break;
}
return ret;
}
Call this function like this from separated c file. This file does not include definition of ReadInfo function:
extern "C" {int32_t CDECL ReadInfo(intptr_t, int32_t, int32_t*);}
int32_t readInt()
{
int32_t value = 0;
int32_t *ptr = &value;
ReadInfo(handle, INT32_FIELD, ptr);
return value;
}
This call fails only under iOS arm64. arm7s and win32 work fine with this call. (Yes, our only 64 bit target platform is iOS arm64.)
In debugger I found that address of ptr in readInt function is different from what I got with:
void argPtr = va_arg(arg, void);
Am I working wrong with arg_list?
P.S. It is not a plain Objective C application. It is part of native Unity plugin. But in iOS Unity code is just transformed into Objective C/C++ from C#. That is why you can see second declaration:
extern "C" {int32_t CDECL ReadInfo(intptr_t, int32_t, int32_t*);}
It's not an issue of IL2CPP but an issue of iOS, or maybe the compiler.
The following code could reproduce the issue even on the latest Xcode (10.1) and iOS (12.1)
typedef int __cdecl (*PInvokeFunc) (const char*, int);
int test()
{
PInvokeFunc fp = (PInvokeFunc)printf;
fp("Hello World: %d", 10);
return 0;
}
The expected output is: Hello World: 10 but it will give Hello World: ??? (Random number) on iOS however.
I tried the same code on macOS and Linux and both of them work well.
I'm not sure if it relates to the Apple document or not:
Variadic Functions
The iOS ABI for functions that take a variable number of arguments is entirely different from the generic version.
Stages A and B of the generic procedure call standard are performed as usual—in particular, even variadic aggregates larger than 16 bytes are passed via a reference to temporary memory allocated by the caller. After that, the fixed arguments are allocated to registers and stack slots as usual in iOS.
The NSRN is then rounded up to the next multiple of 8 bytes, and each variadic argument is assigned to the appropriate number of 8-byte stack slots.
The C language requires arguments smaller than int to be promoted before a call, but beyond that, unused bytes on the stack are not specified by this ABI.
As a result of this change, the type va_list is an alias for char * rather than for the struct type specified in the generic PCS. It is also not in the std namespace when compiling C++ code.
https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
Updates:
The reply for Apple engineer:
Casting function pointers to add a different calling convention doesn’t change how the callee is represented, it only changes how the caller performs its call. printf already has a calling convention, and what you’re doing might happen to work for some combinations on some platforms, while not working on others. You want to declare a wrapper function instead, which has the desired calling convention, and which calls the function you want. You’ll need to marshal the arguments manually.
That is to say the variadic function can't be direct p/invoke unless IL2CPP generate wrapper function for it. Only a function pointer is not enough.
The reason of this problem was in IL2CPP, which generates calls of function with variable argument. And it does not use my types like InfoType, myint64. It uses platform specific types for info variable. And size maybe different I guess.
I just add 3 new function for Unity API:
int32_t ReadInfoInt(void *handle, InfoType info, int *ret);
int32_t ReadInfoInt64(void *handle, InfoType info, myint64 *ret);
int32_t ReadInfoStr(void *handle, InfoType info, char **ret);
In this function I just call ReadInfo.
It is workaround 100%, but it is better then fight with IL2CPP.
I need to register functions like the following in a list of functions with arguments.
void func1( int a , char* b ) {}
void func2( vec3f a , std::vector<float> b , double c) {}
...
And call them back when I receive data over network with proper arguments. I imagined va_list would solve, but it doesnt work :
void func1(int a, char* b)
{
printf("%d %s",a,b);
}
void prepare(...)
{
va_list argList;
int args = 2;
va_start(argList, args);
((void (*)(va_list))func1)(argList);
va_end(argList);
}
int main(int argc, char **argv)
{
prepare(1, "huhu");
return 0;
}
What is the most elegant way to solve this ?
I know std::bind / std::function has similar abilities, but the internal data is hidden deep in std I assume. I just need a few basic data types, doesnt have to be for arbitrary types. If preprocessor tricks with ##VA_ARGS or using templates would solve, I am also OK with that. Priority is that it is most simple to use.
Edit1 : I found that assembly can solve ( How do I pass arguments to C++ functions when I call them from inline assembly ) - but I would prefer a more platform independent solution.
If your goal is to create your own, small and ad-hoc "rpc" solution, possibly one of the major drivers for making decisions should be: 1. Minimal amount of code 2. Easy as possible.
Keeping that in mind, it is paying off to ponder, what the difference is between the following 2 scenarios:
"Real" RPC: The handlers shall be as you wrote with rpc-method-specific signature.
"Message passing": The handlers receive messages of either "end point-determined type" or simply of a unified message type.
Now, what has to be done to get a solution of type 1?
Incoming byte streams/network packets need to get parsed to some sort of message with regards to some chosen protocol. Then, using some meta-info (contract), according to { serviceContract, serviceMethod }, a specific set of data items needs to be confirmed in the packet and if present, the respective, registered handler function needs to be called. Somewhere within that infrastructure you typically have a (likely code generated) function which does something like that:
void CallHandlerForRpcXYCallFoo( const RpcMessage*message )
{
uint32_t arg0 = message->getAsUint32(0);
// ...
float argN = message->getAsFloat(N);
Foo( arg0, arg1, ... argN );
}
All that can, of course also be packed into classes and virtual methods with the classes being generated from the service contract meta data. Maybe, there is also a way by means of some excessive template voodoo to avoid generating code and having a more generic meta-implementation. But, all that is work, real work. Way too much work to do it just for fun. Instead of doing that, it would be easier to use one of the dozens technologies which do that already.
Worth noting so far is: Somewhere within that piece of art, there is likely a (code generated) function which looks like the one given above.
Now, what has to be done to get a solution of type 2?
Less than for case 1. Why? Because you simply stop your implementation at calling those handler methods, which all take the RpcMessage as their single argument. As such, you can get away without generating the "make-it-look-like-a-function-call" layer above those methods.
Not only is it less work, it is also more robust in the presence of some scenarios where the contract changes. If one more data item is being added to the "rpc solution", the signature of the "rpc function" MUST change. Code re-generated, application code adapted. And that, whether or not the application needs that new data item. On the other hand, in approach 2, there are no breaking changes in the code. Of course, depending on your choices and the kind of changes in the contract, it still would break.
So, the most elegant solution is: Don't do RPC, do message passing. Preferably in a REST-ful way.
Also, if you prefer a "unified" rpc message over a number of rpc-contract specific message types, you remove another reason for code bloat.
Just in case, what I say seems a bit too abstract, here some mock-up dummy code, sketching solution 2:
#include <cstdio>
#include <cstdint>
#include <map>
#include <vector>
#include <deque>
#include <functional>
// "rpc" infrastructure (could be an API for a dll or a lib or so:
// Just one way to do it. Somehow, your various data types need
// to be handled/represented.
class RpcVariant
{
public:
enum class VariantType
{
RVT_EMPTY,
RVT_UINT,
RVT_SINT,
RVT_FLOAT32,
RVT_BYTES
};
private:
VariantType m_type;
uint64_t m_uintValue;
int64_t m_intValue;
float m_floatValue;
std::vector<uint8_t> m_bytesValue;
explicit RpcVariant(VariantType type)
: m_type(type)
{
}
public:
static RpcVariant MakeEmpty()
{
RpcVariant result(VariantType::RVT_EMPTY);
return result;
}
static RpcVariant MakeUint(uint64_t value)
{
RpcVariant result(VariantType::RVT_UINT);
result.m_uintValue = value;
return result;
}
// ... More make-functions
uint64_t AsUint() const
{
// TODO: check if correct type...
return m_uintValue;
}
// ... More AsXXX() functions
// ... Some ToWire()/FromWire() functions...
};
typedef std::map<uint32_t, RpcVariant> RpcMessage_t;
typedef std::function<void(const RpcMessage_t *)> RpcHandler_t;
void RpcInit();
void RpcUninit();
// application writes handlers and registers them with the infrastructure.
// rpc_context_id can be anything opportune - chose uint32_t, here.
// could as well be a string or a pair of values (service,method) or whatever.
void RpcRegisterHandler(uint32_t rpc_context_id, RpcHandler_t handler);
// Then according to taste/style preferences some receive function which uses the registered information and dispatches to the handlers...
void RpcReceive();
void RpcBeginReceive();
void RpcEndReceive();
// maybe some sending, too...
void RpcSend(uint32_t rpc_context_id, const RpcMessage_t * message);
int main(int argc, const char * argv[])
{
RpcInit();
RpcRegisterHandler(42, [](const RpcMessage_t *message) { puts("message type 42 received."); });
RpcRegisterHandler(43, [](const RpcMessage_t *message) { puts("message type 43 received."); });
while (true)
{
RpcReceive();
}
RpcUninit();
return 0;
}
And if RpcMessage then is traded, while packed in a std::shared_ptr, you can even have multiple handlers or do some forwarding (to other threads) of the same message instance. This is one particularly annoying thing, which needs yet another "serializing" in the rpc approach. Here, you simply forward the message.
I am writing an adapter to combine two APIs (one in C and another in C++).
If a function is called on the one API I need to pass the callers ID and the function's arguments to an adapter and call the according function with this information passed.
Now aparently they can not be mapped directly as one interface requires C++ compilation and the name mangling would screw the other so that is why I am using a set of adapters in the first place.
As the number of arguments varies, I looked up variadic functions and found the idea pretty useful, however I am operating on POD only and have to deal with structs, enums and a lot of different arguments per call, which might need to be put back into a struct before feeding it to the target function.
Every example I stumbled upon was far simpler and involved mostly arithmetic operations like summing stuff up , finding largest numbers or printing. Mostly done with for loops on the var_list.
Maybe I got stuck on the idea and it won't work at all, but I am just curious...
Say I wanted to assign the arguments from the list to my target functions parameters (the order of the arguments passed is the correct one), what would be a good way?
BOOL Some_Function(
/* in */ CallerId *pObjectId,
/* in */ someDataType argument1 )
{
BOOL ret = Adapter_Call(pFunction, pObjectId, argument1);
return ret;
}
and so once I made it to the right adapter I want to do
BOOL Adapter_Call(*pFunction, *pObjectId, argument1, ...)
{
va_list args;
va_start(args, argument1);
/*go over list and do `var_list[i] = pFunctionArgList[i]` which is
of whatever type so I can use it as input for my function */
va_end(args);
pObjectId.pFunction(arg1,...,argn);
}
Can I access the input parameters of a function to perform assignments like this?
Has anyone done something like this before? Is there a conceptual mistake in my thinking?
All I found on the net was this, http://www.drdobbs.com/cpp/extracting-function-parameter-and-return/240000586but due to the use of templates I am not sure if it wouldn't create another problem and so in the end implementing an adapter for each and every single functioncall may be simpler to do.
A SO search only returned this: Dynamic function calls at runtime (va_list)
First, you should heed Kerrek's advice about extern "C". This is C++'s mechanism for giving an identifier C linkage, meaning that the name won't be mangled by the C++ compiler.
Sometimes, and adapter still needs to be written for a C++ interface, because it manipulates objects that do not map to a C POD. So, the adapter gives the C interface a POD or opaque pointer type to manipulate, but the implementation of that interface converts that into an C++ object or reference and then calls the C++ interface. For example, suppose you wanted to provide a C interface for C++ std::map<int, void *>, you would have a common header file in C and C++ that would contain:
#ifdef __cplusplus
extern "C" {
#endif
struct c_map_int_ptr;
// ...
// return -1 on failure, otherwise 0, and *data is populated with result
int c_map_int_ptr_find (struct c_map_int_ptr *, int key, void **data);
#ifdef __cplusplus
}
#endif
Then, the C++ code could implement the function like:
typedef std::map<int, void *> map_int_ptr;
int c_map_int_ptr_find (struct c_map_int_ptr *cmap, int key, void **data) {
map_int_ptr &map = *static_cast<map_int_ptr *>(cmap);
map_int_ptr::iterator i = map.find(key);
if (i != map.end()) {
*data = i->second;
return 0;
}
return -1;
}
Thus, there is no need to pass the arguments passed via the C interface through a variable argument adapter. And so, there is no need for the C++ code to tease out the arguments from a variable argument list. The C code calls directly into the C++ code, which knows what to do with the arguments.
I suppose if you are trying to implement some kind of automated C adapter code generator by parsing C++ code, you could think that using variable arguments would provide a regular mechanism to communicate arguments between the generated C code interface and the generated C++ adapter code that would call the original C++ interface. For such a scenario, the code for the above example would look something like this:
// C interface
typedef struct c_map_int_ptr c_map_int_ptr;
typedef struct c_map_int_ptr_iterator c_map_int_ptr_iterator;
//...
c_map_int_ptr_iterator c_map_int_ptr_find (c_map_int_ptr *map, int key) {
c_map_int_ptr_iterator result;
cpp_map_int_ptr_adapter(__func__, map, key, &result);
return result;
}
// C++ code:
struct cpp_adapter {
virtual ~cpp_adapter () {}
virtual void execute (va_list) {}
};
void cpp_map_int_ptr_adapter(const char *func, ...) {
va_list ap;
va_start(ap, func);
cpp_map_int_ptr_adapter_method_lookup(func).execute(ap);
va_end(ap);
}
//...
struct cpp_map_int_ptr_find_adapter : cpp_adapter {
void execute (va_list ap) {
map_int_ptr *map = va_arg(ap, map_int_ptr *);
int key = va_arg(ap, int);
c_map_int_ptr_iterator *c_iter = va_arg(ap, c_map_int_ptr_iterator *);
map_int_ptr::iterator i = map->find(key);
//...transfer result to c_iter
}
};
Where cpp_map_int_ptr_adapter_method_lookup() returns an appropriate cpp_adapter instance based on a table lookup.
I was trying to hook a custom recv() winsock2.0 method to a remote process, so that my function executes instead of the one in the process, i have been googling this and i found some really good example, but they lack description
typedef (WINAPI * WSAREC)( SOCKET s, char *buf, int len, int flags ) = recv;
Now my question is, what does this mean, or does, is this some sort of a pointer to the real recv() function?
And then the other piece of code for the custom function
int WINAPI Cus_Recv( SOCKET s, char *buf, int len, int flags )
{
printf("Intercepted a packet");
return WSAREC( s, buf, len, flags ); // <- What is this?
}
Sorry if these questions sound really basic, i only started learning 2 or 3 weeks ago.
Thanks.
where did you find such an example ?
the first line tries to define a new type WSAREC, which is a pointer to a function having the same signature as recv(). unfortunately, it is also trying to declare a variable of this type to store the address of the recv() function. the typedef is wrong since the function is lacking a return type. so it does not compile under Visual Studio 2003.
you may have more luck using:
int (WINAPI * WSAREC)( SOCKET s, char *buf, int len, int flags ) = &recv;
which declares only a variable of type "pointer to function", which stores the address of the recv().
now the second snippet is a function which has the same signature as the recv()function, which prints a message, then calls the original recv() through the function pointer declared above.
the code here only shows how to call a function through a pointer: it does not replace anything in the current process.
also, i am not sure you can interfere with another process and replace one function at your will. it would be a great threat to the security of the system. but why would you do that in the first place ??