trace_ext4_discard_blocks-- I wonder how and where do they implemented this fn., inside linux kernel code. Normal ctags, cscope didn't helps. I strongly suspect it is implemented somewhere in asm but I donno' how to catch this in code. Any pointers or tricks?
Here is the starting point for the tracepoint documentation.
Here is the definition of the function.
Here is where the TRACE_POINT macro ends up.
Related
I have a function that I would like to provide an assembly implementation for
on amd64 architecture. For the sake of discussion let's just suppose it's an
Add function, but it's actually more complicated than this. I have the
assembly version working but my question concerns getting the godoc to display
correctly. I have a feeling this is currenty impossible, but I wanted to seek
advice.
Some more details:
The assembly implementation of this function contains only a few
instructions. In particular, the mere cost of calling the function is a
significant part of the entire cost.
It makes use of special instructions (BMI2) therefore can only be used
following a CPUID capability check.
The implementation is structured like this gist. At a high level:
In the generic (non-amd64 case) the function is defined by delegating to
addGeneric.
In the amd64 case the function is actually a variable, initially set to
addGeneric but replaced by addAsm in the init function if a cpuid
check passes.
This approach works. However the godoc output is crappy because in the
amd64 case the function is actually a variable. Note godoc appears to be
picking up the same build tags as the machine it's running on. I'm not sure
what godoc.org would do.
Alternatives considered:
The Add function delegates to addImpl. Then we pull some similar trick
to replace addImpl in the amd64 case. The problem with this is (in my
experiments) Go doesn't seem to be able to inline the call, and the assembly
is now wrapped in two function calls. Since the assembly is so small already
this has a noticable impact on performance.
In the amd64 case we define a plain function Add that has the useAsm
check inside it, and calls one of addGeneric and addAsm depending on the
result. This would have an even worse impact on performance.
So I guess the questions are:
Is there a better way to structure the code to achieve the performance I
want, and have it appear properly in documentation.
If there is no alternative, is there some other way to "trick" godoc?
See math.Sqrt for an example of how to do this.
Write a stub function with the documentation
Write a generic implementation as an unexported function.
For each architecture, write a function in assembler that jumps to the unexported generic implementation or implements the function directly.
To handle the cpuid check, set a package variable in init() and conditionally jump based on that variable in the assembly implementation.
Can anyone point me to documentation for CodeAuthzpComputeImageHash() in advapi32.dll?
I can't seem to find documentation anywhere.
The reason you can't find documentation for this function is that this function is undocumented.
Not all winapi functions are documented, unfortunately.
There is a mention of the function at http://technet.microsoft.com/en-us/library/cc786941(v=WS.10).aspx, though:
ItemData (REG_BINARY). The actual hash to the file. This value should always be 16 bytes and is generated with a call to CodeAuthzpComputeImageHash().
Also, you can use a trampoline to hook the function, and if you know how to cause it to be executed, you can then try to see its arguments and return type.
Also, try searching at WINE if they have implemented it. Ask in their mailing list. Since they try to implement winapi, they need to implement the undocumented parts, too, there's a good chance they have some understanding about the function.
I am trying to look for definition and declaration of the function nanf() - return 'Not a Number function, which is related to the floating point functionality on Linux gcc compiler environment - (glibc).
I need to use similar/same definition for nanf() on windows to build my code using Visual Studio.
I checked following header files in the Linux src/include folders but did not see anything related to nanf declaration.
/usr/include/math.h
/usr/include/bits/nan.h
Any pointers will be helpful.
thank you,
-AD
The declaration is just (C99 ยง7.12.11.3):
float nanf(const char *tagp);
or macros that expand to something equivalent. A conformant implementation is highly platform-specific, however, because the standard does not define how to interpret tagp, except to say that the behavior is equivalent to a certain call to strtof, and "The nan functions return a quiet NaN, if available, with content indicated through tagp."
Instead of trying to shoehorn C99 features into the one compiler and library that stubbornly refuses to even try to implement them, why not just use a real C compiler? There are plenty out there.
Is there a way to get function caller in linux kernel? I know __func__ returns the function name which is executing. I am looking for the function which called "__func__"
You can get the caller with __builtin_return_address(0).
The caller's caller is __builtin_return_address(1) and so on.
It's a GCC extension, documented in the gcc manual: http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html
Edit: I should probably point out, that gets you the address of the caller. If you want the function name you can print it with %pS, eg:
printk("Caller is %pS\n", __builtin_return_address(0));
If you don't want to print it, you can use kallsyms_lookup() etc.
You can also print the entire call stack contents by calling dump_stack().
Whether or not frame pointers are needed depends on arch, IIRC. For x86, they are certainly desired to fully exploit these features. Also note that inlining can skew the accuracy of builtin_return_address for this very reason.
If you just want a stack dump to see how some place was reached, better use the dump_stack() function than trying to fiddle around with builtin_return_address.
To get the caller function name, one can use the below printk command.
printk("Caller is %pF\n", __builtin_return_address(0));
I've been looking recently into creating a new native language. I understand the (very) basics of the PE format and I've grabbed an assembler with a fairly kind interface off the webs, which I've successfully used to implement some simple functions. But I've run into a problem using functions from a library. The only way that I've called library functions from a dynamically compiled function previously is to pass in the function pointer manually- something I can't do if I create PE files and execute them in their own process. Now, I'm not planning on using the CRT, but I will need access to the Win API to implement my own standard libraries. How do I generate a reference to a WinAPI function so that the PE loader will patch it up?
You need to write an import table. It's basically a list of function names that you wish to use in your application. It's pointed to by the PE header. The loader loads the DLL files into the process memory space for you, finds the requested function in their export table and leaves the address for it in the import table. You then usually dereference that and jmp there.
Check out Izelion's assembly tutorial for the full details and for asm examples.
How about starting by emitting C instead of assembly? Then writing directly to ASM is just an optimization.
I'm not being facetious: most compilers turn out some kind of intermediate code before the final native code pass.
I realize you're trying to get away from all the null-delmited rigmarole, but you'll need that for the WinAPI functions anyway.
Re-reading your question: you do realize that you can get the WinAPI function addresses by calling LoadLibrary(), then calling GetProcAddress(), and then setting up the call...right?
If you want to see how to bootstrap this from pure assembly: the old SDKs had ASM sample code, probably the new ones still do. If they don't, the DDK will.