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));
Related
In Rust, you can use the black_box function to force the compiler to
assume that the function's argument is used (forcing it not to optimize away code that generates that value)
not be able to inspect how its return value is produced (preventing it from doing constant-folding and other such optimizations).
Is there a similar facility in Go (to accomplish either task)?
Is there a similar facility in Go (to accomplish either task)?
No.
If you want to use a result: Assign to an exported global.
I believe runtime.KeepAlive is recommended, as per the following Github issue. Unfortunately, it's unclear whether anything exists for function arguments, or whether KeepAlive is even guaranteed to work.
https://github.com/golang/go/issues/27400
I rely on GetProcAddress() to do some hooking of some functions. I get a terrible result though, and to be honest, I don't really know what's happening.
It seems that this code will output "WHAT THE HELL?":
int main(void)
{
HMODULE ws32 = LoadLibrary("WS2_32.DLL");
if (GetProcAddress(ws32, "ntohl") == GetProcAddress(ws32, "htonl"))
printf("WHAT THE HELL\n");
return 0;
}
Could someone explain me why ntohl and htonl have the same absolute addresses?
The problem is that, when I hook into a DLL and do some processing inside the DLL, it's clear that Inside the PE import table (I parse the PE IAT), ntohl() and htonl() have different addresses (Inside the IAT as said).
So this thing renders my program useless. ntohl() is confounded with htonl(), and the program cannot make the difference and goes crazy.
Any thoughts? Would there be a way to circumvent this? An explication?
Sure, why not. All the ntohl and htonl function does, on a little endian platform, is to reverse all the individual bytes in an integer. There's no need for those 2 functions to be implemented differently - you do not need to worry that GetProcAddress() returns the same function pointer.
Ofcourse, you'd want to verify that GetProcAddress doesn't return a NULL pointer.
Unless you're on a mixed-endian platform like PDP-11, converting from host to the native endianness or vice versa is simply a byte swap or a NOP, so applying ntohl or htonl to an integer results in the same output. Therefore the linker may choose to use the same function for both names
It's unclear why you want to differentiate those functions, but it's completely unreliable. Smart compilers know to convert htonl and ntohl to a byte swap if necessary, resulting in zero function call. The user can also call compiler intrinsics such as _byteswap_ulong() or __builtin_bswap32() directly. In those cases how can you hook the function?
That being said, it's likely because of COMDAT folding optimization which merges identical functions. To disable it use the /OPT:NOICF flag
See also
Do distinct functions have distinct addresses?
Why do two functions have the same address?
Windows API has ChildWindowFromPoint() and ChildWindowFromPointEx() functions and they differ in that the latter has uFlags parameter specifying which windows to skip.
It looks like if I pass CWP_ALL into ChildWindowFromPointEx() I'll get exactly the same effect as I would have with ChildWindowFromPoint().
Is the only difference in uFlags parameter? Can I just use ChildWindowFromPointEx() everywhere and pass CWP_ALL when I need ChildWindowFromPoint() behavior?
If it helps at all, I hacked up a quick test application that calls both functions and stepped into the disassembled USER32.DLL to see where the calls go.
For ChildWindowFromPoint, after some preamble, I reached this point:
The main processing was delegated to the call at 75612495.
Then, for ChildWindowFromPointEx, I step into the assembly and get this:
As that entry point is the target of the call from the first function, it seems pretty clear to me that ChildWindowFromPoint calls ChildWindowFromPointEx, presumably with uFlags set to CWP_ALL (my assembler knowledge is limited but I'm looking hard at that push 0 before the call - CWP_ALL is defined as zero).
If you intent to always use ChildWindowFromPointEx with CWP_ALL, you could just use ChildWindowFromPoint().
If you intent to always use ChildWindowFromPoint, you could just use ChildWindowFromPointEx with CWP_ALL.
ChildWindowFromPoint is equivalent to ChildWindowFromPointEx with CWP_ALL.
Advice: use ChildWindowFromPointEx (you may one day have usage for other flags value)
I am trying to hook in functionality for the following kernel API:
extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
arch/arm/include/asm/system_misc.h
I would like to know what is the use of the second parameter char *cmd.
I am unable to rationalize the need for the second parameter cmd, though the first parameter reboot_mode makes proper sense...
Can someone please explain ?
I would like to know what is the use of the second parameter char *cmd.
Can someone please explain ?
This is called via machine_restart(), which is in turn called by kernel_restart(). As per the kernel doc,
#cmd: pointer to buffer containing command to execute for restart or %NULL
You can pass a command to rebootnote and this is what you see. For the most part, ARM hooks just ignores it. You could check it for NULL or also ignore it.
From man 2 reboot,
The precise effect of the above actions depends on the architecture. For the i386 architecture, the additional argument does not do anything at present (2.1.122), but the type of reboot can be determined by kernel command-line arguments ("reboot=...") to be either warm or cold, and either hard or through the BIOS.
You are free to ignore it, but you could use it if you needed user space to signal something special. Almost always, you will get cmd == NULL.
Note: This command always returns with failure; it shouldn't return ;-) See the define LINUX_REBOOT_CMD_RESTART2 for the case that this cmd is non-NULL.
I want to do something similar to how, in GCC, you can do syntax checking on printf-style calls (to make sure that the argument list is actually correct for the call).
I have some functions that take a variable number of parameters. Rather than enforce what parameters are sent, I need to ensure that the last parameter passed is a NULL, regardless of how many parameters are passed-in.
Is there a way to get GCC to do this type of syntax check during compile time?
You probably want the sentinel function attribute, so declare your function like
void foo(int,double,...) __attribute__((sentinel));
You might consider customizing your GCC with a plugin or a MELT extension to typecheck more precisely your variadic functions. That is, you could extend GCC with your own attributes which would do more precise checks (or simply make additional checks based on the names of your functions).
The ex06/ example of melt-examples is doing a similar check for the jansson library; unfortunately that example is incomplete today October 18th 2012, I am still working on it.
In addition, you could define a variadic macro to call such a function by always adding a NULL e.g. something like:
#define FOO(N,D,...) foo((N),(D),##__V_ARGS__,NULL)
Then by coding FOO(i+3,3.14,"a") you'll get foo((i+3),(3.14),"a",NULL) so you are sure that a NULL is appended.
Basile Starynkevitch is right, go with a function attribute. There are a ton of other useful function attributes, like being able to tell the compiler "If the caller doesn't check the return value of this function, it's an error."
You may also want to see if splint can check for you, but I don't think so. I think it would have stuck in my memory.
If you haven't read over this page of GCC compiler flags, do that, too. There are a ton of handy checks in there. http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html