Looking at the api help for rte_eth_dev_set_link_up, it seems it is not required to call this function after rte_eth_dev_start. I see this confirmed in the fact that even not all pmds implement this function (e.g. virtio) and that some pmds call the link_up function in their
start function.
However I am a bit confused by this example code:
https://doc.dpdk.org/api/examples_2ip_pipeline_2link_8c-example.html#a20
in which there is a call to rte_eth_dev_set_link_up after the start.
In what cases is it needed to call rte_eth_dev_set_link_up right after rte_eth_dev_start?
Related
I'm working on a Fortran program and running into a strange bug with some Heisenbug-type characteristics, and looking for some insight into what might be going on. The code is too large to post in full but I hopefully I can the general idea.
What's basically going on is I have a subroutine that reads a list of numerical parameters from a text file,
call read_parameters(filename, parameter_array)
and then this list of parameters is sent into another subroutine that runs a program using those parameter values.
call run_program(parameter_array)
These calls are part of a loop that calls run_program with slightly different parameters each time through the loop---the intention is to find better parameter sets.
I've found that on the first pass through this loop, run_program gives bizarre results, which seems to indicate that something is going wrong with the first call to read_parameters. But all the subsequent passes behave normally and I haven't been able to understand what's going wrong with that first pass despite a lot of investigating, including for example printing the values of the parameters themselves within the actual run_program code.
While testing, I realized that if I put another call to read_parameters right above the call to run_program, then the first pass of the program runs normally, but here's the thing: this new call to read_parameters is just a dummy call, with an output array parameter_array2 that doesn't even get used! As in,
call read_parameters(parameter_array)
call read_parameters(parameter_array2)
call run_program(parameter_array)
If the second line is present, the program runs just fine, even though parameter_array2 isn't used anywhere, while if it's absent the program gives erroneous results for the first pass through the loop.
Does anyone have any ideas about what might be going on?
Thanks.
So recently I wanted to add an imgui interface to an example window using DirectX, so I watched on a video I had to hook the EndScene function using DirectX9sdk to be able to add my custom imgui interface.
However I have some questions:
Where can I find any documentation for the DirectX9 functions and types,( if there is any, because I do not understand why we specifically have to hook the EndScene function) or where could I find any article explaining more in depth how directX works?
I've seen two version so far of EndScene hooks one with a patternScanning function which scans a signature in the shaderapi dll and another which creates a DirectXDevice and then accesses the vtable from there; are there any sources online, or is it something we have to do ourselves?
Here is the version I have:
while (!DirectXDevice) // loops until it finds the device
DirectXDevice = **(DWORD**)(FindPattern("shaderapidx9.dll", "A1 ?? ?? ?? ?? 50 8B 08 FF 51 0C") + 0x1);
void** pVTable = *reinterpret_cast<void***>(DirectXDevice); // getting the vtable array
oEndScene = (f_EndScene)DetourFunction((PBYTE)pVTable[42], (PBYTE)Hooked_EndScene)//getting the 42th virtual function and detouring it to our own
I don't really understand what __stdcall does here, I do know it is used to call WINAPI functions but what for here?
HRESULT __stdcall Hooked_EndScene(IDirect3DDevice9* pDevice){//some code}
Note: thats the function I hook to the original endscene.
Thank you really much, I'm sorry if there are alot of questions but I really can't wrap my head around this.
How do you know which functions you need to hook?
To put it bluntly, you have to be an experienced DirectX graphics programmer to find that out. Don't expect being able to hook into a framework that you don't understand. It just so happens that EndScene will always be called after all the other draw calls on the render target.
There are tons of D3D9 programming resources available, online and in paper form. Most of them are not free. I'm afraid this is not the answer you were hoping for.
What is the deal with pattern scanning, or creating a temporary D3D9 device?
Microsoft did not put any explicit effort into making EndScene hookable. It just happens to be hookable because every normal function is hookable. You need a way to find the function in memory, because the function will not always be at the same address.
One approach is to scan for known instructions that appear inside the function. Someone needs to be the first person to find out that pattern that you can scan for. You are far from the first person to hook EndScene, so many have reverse-engineered the function before and shared searchable patterns.
NOTE: The pattern does not necessarily need to be directly inside the target function. It might also lead you to something else first, in your case, the ID3D9Device instance. The important thing is that you can find your way to the EndScene function somehow.
Another approach is to get a pointer to the function. If it was a regular C function, that would be easy. It's hard here because OOP tends to make these things hard - you have to fight your way through various interfaces to get the correct vtable.
Both methods have advantages and disadvantages -- creating a D3D9 device is safer, but also more intrusive, because the target process might not expect someone to just randomly create new devices.
Why does the hook function need __stdcall?
Since you replace the original function with your hooked version, the calling convention of the hooked function must be the same as the calling convention of the original function. The caller of EndScene expects (and was compiled with) a __stdcall convention, so the new function must also behave the same way, otherwise the stack will be corrupted. Your act of replacing the function does not change the way the caller calls it.
I debug a code, and I use _set_purecall_handler to set function that be called when pure call virtual function happened. This exemple from MSDN work nice for me and do what I want: code from msdn
So, you can see the declaration of the function
void myPurecallHandler(void)
{
printf("In _purecall_handler.");
exit(0);
}
this function MUST return a void value and don't have any arguments, this function is called when a pure call virtuall function happened. I have trying to overload this function to passe it a parameters (The line number where pure call virtuall function happened ), but can't success.
If you see, there is another function there: _set_purecall_handler_m
What is the difference between this function and _set_purecall_handler?
Thanks a lot,
_set_purecall_handler_m is for use with mixed mode CRT when using C++ and C++-CLI. If you are not working with C++-CLI you really don't need to use it. If however you are creating say a DLL that may be used with C++-CLi applications you might want to consider using it.
I've recently been working on detouring functions (only in Linux) and so far I've had great success. I was developing my own detouring class until I found this. I modernized the code a bit and converted it to C++ (as a class of course). That code is just like any other detour implementation, it replaces the original function address with a JMP to my own specified 'hook' function. It also creates a 'trampoline' for the original function.
Everything works flawlessly but I'd like to do one simple adjustement. I program in pure C++, I use no global functions and everything is enclosed in classes (just like Java/C#). The problem is that this detouring method breaks my pattern. The 'hook' function needs to be a static/non-class function.
What I want to do is to implement support for _thiscall hooks (which should be pretty simple with the GCC _thiscall convention). I've had no success modifying this code to work with _thiscall hooks. What I want as an end result is something just as simple as this; PatchAddress(void * target, void * hook, void * class);. I'm not asking anyone to do this for me, but I would like to know how to solve/approach my problem?
From what I know, I should only need to increase the 'patch' size (i.e it's now 5 bytes, and I should require an additional 5 bytes?), and then before I use the JMP call (to my hook function), I push my 'this' pointer to the stack (which should be as if I called it as a member function). To illustrate:
push 'my class pointer'
jmp <my hook function>
Instead of just having the 'jmp' call directly/only. Is that the correct approach or is there something else beneath that needs to be taken into account (note: I do not care about support for VC++ _thiscall)?
NOTE: here's is my implementation of the above mentioned code: header : source, uses libudis86
I tried several different methods and among these were JIT compile (using libjit) which proved successful but the method did not provide enough performance for it to be usable. Instead I turned to libffi, which is used for calling functions dynamically at run-time. The libffi library had a closure API (ffi_prep_closure_loc) which enabled me to supply my 'this' pointer to each closure generated. So I used a static callback function and converted the void pointer to my object type and from there I could call any non-static function I wished!
I am working on this small project where I'd like to generate the call graph of an application - I am not planning to do anything complex, it is mainly for fun/experience. I am working on x64 platform.
The first goal I set myself is to be able to measure the time spent in each function of my test application. So far my strategy has been to use __penter()_ and __pexit()_ - __penter()_ is a function that will get called at the start of every method or function and conversely __pexit()_ will get called at the end of every method or function.
With these two functions I can record each function call as well as the time spent in each of them. What I'd like to do next is get the address of each function being called.
For example if we consider the following callstack (very simplified):
main()
....myFunction()
........_penter()
I am in __penter_ and I want to get the address of the calling function, myFunction(). I already found a way to do it in the case of non-leaf functions, I simply use RtlLookupFunctionEntry. However this solution doesn't seem to work for leaf functions because they don't provide any unwind data.
One thing I was thinking about is to go up one more level in the callstack, in main(), and decode the CALL procedure manually - that would involve getting a pointer to the instruction calling myFunction().
I was wondering if any of you would know how to get the address of the current function in the case of leaf functions. I have this gut feeling that my current approach is a bit overcomplicated.
Thanks,
Clem
I believe SymGetSymFromAddr64, probably along with StackWalk64 should get you (most of?) what you want.
Hmm, x64 code, no assembly hacks at your disposal unless you use ml64.exe. There's one intrinsic that ought to help here, _ReturnAddress() gives you the code location of the call to your __penter() function. The instruction after it btw. That should be enough to help you identify the caller.