I wrote a dll containing a hook procedure. I try to call this function, after loading (with success) the dll, but the result is 0, and GetLastError result 127. I'm using visual studio c++, and this is the code:
dll:
#include <windows.h>
__declspec(dllexport) LRESULT CALLBACK CBTFrenk(int nCode, WPARAM wParam, LPARAM lParam){...}
myapp:
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
HINSTANCE hdll = LoadLibrary((LPCTSTR) L"C:\\Users\.....DllForHook.dll");
wprintf(L"%d\n", GetLastError());
HOOKPROC pfunc = (HOOKPROC)GetProcAddress(hdll, "CBTFrenk");
wprintf(L"%d\n", GetLastError());
HHOOK handleToAHook = SetWindowsHookEx(WH_CBT, pfunc, hdll, 0);
return 0;
}
Thanks for the collaboration.
edit:
00000000 characteristics
4E515E9D time date stamp Sun Aug 21 21:38:05 2011
0.00 version
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 00011005 ?CBTFrenk##YGJHIJ#Z = #ILT+0(?CBTFrenk##YGJHIJ#Z)
Summary
1000 .data
1000 .idata
2000 .rdata
1000 .reloc
1000 .rsrc
4000 .text
10000 .textbss
This is the result with dumpbin, why is the name of my function is so strange?
Edit:
00000000 characteristics
4E520C85 time date stamp Mon Aug 22 10:00:05 2011
0.00 version
1 ordinal base
1 number of functions
1 number of names
ordinal hint RVA name
1 0 0001107D _CBTFrenk#12 = #ILT+120(_CBTFrenk#12)
Summary
1000 .data
1000 .idata
2000 .rdata
1000 .reloc
1000 .rsrc
4000 .text
10000 .textbss
I declared CBTFrenk like extern "C", and calling "_CBTFrenk#12" it's work.
EDIT:
I wrote the dll code with code::block, and using dumpbin I see that the function name exported is "CBTFrenk#12", and if I try to call it, the function result not found. How can I fix this problem?
Try dumpbin with DllForHook library to see whether CBTFrenk function exists. Declare CBTFrenk as extern "C" to prevent C++ name mangling.
Related
I've been trying to map a page that both writable AND executable.
mov x0, 0 // start address
mov x1, 4096 // length
mov x2, 7 // rwx
mov x3, 0x1001 // flags
mov x4, -1 // file descriptor
mov x5, 0 // offset
movl x16, 0x200005c // mmap
svc 0
This gives me a 0xD error code (EACCESS, which the documentation unhelpfully blames on an invalid file descriptor, although same documentation says to use '-1'). I think the code is correct, it returns a valid mmap if I just pass 'r--' for permissions.
I know the same code works in Catalina and x64 architecture. I tested the same error happens when SIP mode is disabled.
For more context, I'm trying to port a FORTH implementation to MacOs/ARM64, and this FORTH, like many others, heavily uses self modifying code/assembling code at runtime. And the code that is doing the assembling/compiling resides in the middle of the newly created code (in fact part the compiler will be generated in machine language as part of running FORTH), so it's very hard/infeasible to separate the FORTH JIT compiler (if you call it that) from the generated code.
Now, I'd really don't want to end up with the answer: "Apple thinks they know better than you, no FORTH for you!", but that is what it looks like so far. Thanks for any help!
You need to toggle the thread between being writable or executable, it can not be both at the same time. I think it is actually possible to do both with the same memory using 2 different threads but I haven't tried.
Before you write to the memory you mmap, call this:
pthread_jit_write_protect_np(0);
sys_icache_invalidate(addr, size);
Then when you are done writing to it you can switch back again like this:
pthread_jit_write_protect_np(1);
sys_icache_invalidate(addr, size);
This is the full code I am using right now
#include <stdio.h>
#include <sys/mman.h>
#include <pthread.h>
#include <libkern/OSCacheControl.h>
#include <stdlib.h>
#include <stdint.h>
uint32_t* c_get_memory(uint32_t size) {
int prot = PROT_READ | PROT_WRITE | PROT_EXEC;
int flags = MAP_PRIVATE | MAP_ANONYMOUS | MAP_JIT;
int fd = -1;
int offset = 0;
uint32_t* addr = 0;
addr = (uint32_t*)mmap(0, size, prot, flags, fd, offset);
if (addr == MAP_FAILED){
printf("failure detected\n");
exit(-1);
}
pthread_jit_write_protect_np(0);
sys_icache_invalidate(addr, size);
return addr;
}
void c_jit(uint32_t* addr, uint32_t size) {
pthread_jit_write_protect_np(1);
sys_icache_invalidate(addr, size);
void (*foo)(void) = (void (*)())addr;
foo();
}
I can get the bugcheck code and the parameters for one BSOD.
And then I can get the text descriptions from Bug Check Code Reference.
But how can I use some windows API or c++ code to get such text description from the bugcheck code and parameters.
For example, for the bugcheck code 0x9F, how can I get the text as
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
with some windows API or reading from some DLL.
Or to say, how to implement similar function as WinDbg :
1: kd> !analyze -show 0x9F 0x3
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: 0000000000000000, Physical Device Object of the stack
Arg3: 0000000000000000, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: 0000000000000000, The blocked IRP
I saw there's API like KeGetBugMessageText(), but it's preserved by Windows itself.
Could someone help on this and give some clue or suggestion on that?
Update:
The main part of code used to execute command with 'blabb' suggestion:
#pragma comment ( lib ,"dbgeng.lib")
#include <iostream>
#include <dbgeng.h>
#include "StdioOutputCallbacks.h"
//#include <wdbgexts.h>
//WINDBG_EXTENSION_APIS64 ExtensionApis;
StdioOutputCallbacks g_OutputCb;
int main()
{
IDebugClient* DebugClient = NULL;
HRESULT Hr = S_OK;
if ((Hr = DebugCreate(__uuidof(IDebugClient),
(void**)&DebugClient)) != S_OK) {
return Hr;
}
PDEBUG_CONTROL DebugControl;
if ((Hr = DebugClient->QueryInterface(__uuidof(IDebugControl),
(void**)&DebugControl)) == S_OK) {
DebugClient->SetOutputCallbacks(&g_OutputCb);
Hr = DebugClient->OpenDumpFile("C:\\Dev\\Deem\\bug\\dcp938\\MEMORY.DMP");
if (Hr != S_OK) {
return Hr;
}
DebugControl->Execute(DEBUG_OUTCTL_THIS_CLIENT, "!analyze -show 9f 3", DEBUG_EXECUTE_DEFAULT);
DebugControl->Release();
}
// done
DebugClient->Release();
}
and in outputcallback, kept as the msdn sample:
STDMETHODIMP
StdioOutputCallbacks::Output(
THIS_
_In_ ULONG Mask,
_In_ PCSTR Text
)
{
UNREFERENCED_PARAMETER(Mask);
fputs(Text, stdout);
return S_OK;
}
But the result of the execute "!analyze -show 9f 3"(the content of Text in fputs()) is "No export analyze found".
I also try the command ".opendump C:\...MEMORY.DMP;!analyze -show 9f 3", the opendump command executed correctly, the dmp is loaded and got the text output including "For analysis of this file, run !analyze -v", but both "!analyze -v" and "!analyze -show ..." got "No export analyze found".
The command without '!' will lead to command resolve error.
I am not sure what you are looking for.
All these are #defined in bugcodes.h in windows sdk/ddk
C:\Program Files (x86)\Windows Kits\10\Include>pss DRIVER_POWER_STATE_FAILURE
.\10.0.17763.0\shared\bugcodes.h
1505:// MessageId: DRIVER_POWER_STATE_FAILURE
1509:// DRIVER_POWER_STATE_FAILURE
1511:#define DRIVER_POWER_STATE_FAILURE ((ULONG)0x0000009FL)
Or grepping the other way round
C:\Program Files (x86)\Windows Kits\10\Include>grep -ir #define.*0x0000009fl --include *.h *
10.0.17763.0/shared/bugcodes.h:#define DRIVER_POWER_STATE_FAILURE ((ULONG)0x0000009FL)
Or use DbgEng to write either a WinDbg extension or a standalone executable.
Open the dump->WaitForEvent->Executecommands !bugdump .bug****
Or you can also explore IDebugDataSpaces::****tag**** methods like read, start, next, end.
Edit
Scott Noone is probably indicating the ext.dll the inbuilt windbg extension
As i Already Stated you may need to write a windbg Analyze Extension either as an extension or as a standalone
most of these are either undocumented or poorly worded documentation
here is the dump of bugcheck codes compiled inside ext.dll which is what scott noone is probably indicating in his answer.
0:000> dps ext!g_BugCheckApiRefs l10
00007ff9`4a45ccc0 00000000`00000001
00007ff9`4a45ccc8 00007ff9`49efead0 ext!BugCheckAPC_INDEX_MISMATCH
00007ff9`4a45ccd0 00000000`00000002
00007ff9`4a45ccd8 00007ff9`49efeb60 ext!BugCheckDEVICE_QUEUE_NOT_BUSY
00007ff9`4a45cce0 00000000`00000003
00007ff9`4a45cce8 00007ff9`49efebc0 ext!BugCheckINVALID_AFFINITY_SET
00007ff9`4a45ccf0 00000000`00000004
00007ff9`4a45ccf8 00007ff9`49efec20 ext!BugCheckINVALID_DATA_ACCESS_TRAP
00007ff9`4a45cd00 00000000`00000005
00007ff9`4a45cd08 00007ff9`49efec80 ext!BugCheckINVALID_PROCESS_ATTACH_ATTEMPT
00007ff9`4a45cd10 00000000`00000006
00007ff9`4a45cd18 00007ff9`49efece0 ext!BugCheckINVALID_PROCESS_DETACH_ATTEMPT
00007ff9`4a45cd20 00000000`00000007
00007ff9`4a45cd28 00007ff9`49efed40 ext!BugCheckINVALID_SOFTWARE_INTERRUPT
00007ff9`4a45cd30 00000000`00000008
00007ff9`4a45cd38 00007ff9`49efeda0 ext!BugCheckIRQL_NOT_DISPATCH_LEVEL
0:000>
or your power failure
0:000> .shell -ci "dps ext!g_BugCheckApiRefs l150" grep -A 1 -i 09f
00007ff9`4a45d600 00000000`0000009f
00007ff9`4a45d608 00007ff9`49f04450 ext!BugCheckDRIVER_POWER_STATE_FAILURE
.shell: Process exited
0:000>
here is a complete call stackLeadign to yourQuery about !analyze -show 9f 3
Child-SP RetAddr Call Site
000000d3`6d67b768 00007ff9`49fa302a ext!GetBugCheckDescription
000000d3`6d67b770 00007ff9`49f822c2 ext!DebugFailureAnalysis::ParseInputArgs+0xc66
000000d3`6d67bb00 00007ff9`49f549c5 ext!AnalyzeBugCheck+0x10a
000000d3`6d67bbd0 00007ff9`4ae0187d ext!analyze+0x4e5
000000d3`6d67bd90 00007ff9`4ae01a31 dbgeng!ExtensionInfo::CallA+0x27d
000000d3`6d67be50 00007ff9`4ae01d0e dbgeng!ExtensionInfo::Call+0x121
000000d3`6d67c050 00007ff9`4adff9d8 dbgeng!ExtensionInfo::CallAny+0x17a
000000d3`6d67c570 00007ff9`4ae43662 dbgeng!ParseBangCmd+0xe0c
000000d3`6d67cd30 00007ff9`4ae44635 dbgeng!ProcessCommands+0xcd6
000000d3`6d67ce20 00007ff9`4ad6baf7 dbgeng!ProcessCommandsAndCatch+0x79
000000d3`6d67ce90 00007ff9`4ad6be04 dbgeng!Execute+0x2bb
000000d3`6d67d380 00007ff6`4c7b62dc dbgeng!DebugClient::ExecuteWide+0x94
000000d3`6d67d3e0 00007ff6`4c7b879a kd!MainLoop+0x514
000000d3`6d67f460 00007ff6`4c7bb55d kd!wmain+0x3e6
000000d3`6d67f700 00007ff9`857c7c24 kd!__wmainCRTStartup+0x14d
000000d3`6d67f740 00007ff9`85d8d721 KERNEL32!BaseThreadInitThunk+0x14
000000d3`6d67f770 00000000`00000000 ntdll!RtlUserThreadStart+0x21
0:000>
The Function is a simple compare return routine like
while array[i] != 0x9f skip
return String array[i]+0x8
and the detailed description is done by
void PrintBugDescription(_BUGCHECK_ANALYSIS *param_1,DebugFailureAnalysis *param_2)
EDIT
Since My last comment I was wondering
how I would go about this scenario without writing code
without having a kernel memory dump to operate on
possibly scalable to unknown remote machines
I Came up with a small python wrapper using sysinternals livekd.exe
script
:\>cat liv.py
import subprocess
import regex
foo = subprocess.run(
[r"f:\sysint\livekd", "-b" ,"-c \"!analyze -show 9f 03;q\""],
stdout=subprocess.PIPE,
universal_newlines=True
)
resta = regex.search("Reading" , foo.stdout).start()
reend = regex.search("quit:" , foo.stdout).end()
print(foo.stdout[resta:reend])
result of script execution
:\>python liv.py
Reading initial command '!analyze -show 9f 03;q'
*** ERROR: Module load completed but symbols could not be loaded for LiveKdD.SYS
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: 0000000000000000, Physical Device Object of the stack
Arg3: 0000000000000000, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: 0000000000000000, The blocked IRP
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 0, {0, 0, 0, 0}
Probably caused by : LiveKdD.SYS ( LiveKdD+2f4f )
Followup: MachineOwner
---------
quit:
Adding another answer as the prior answer is too cluttered and commented.
contents of directory pre compilation and linking
F:\bugdesc>ls -lg
-rw-r--r-- 1 197121 156689581 Aug 17 23:49 MEMORY.DMP
-rw-r--r-- 1 197121 600 Aug 26 01:22 bugdesc.cpp
-rw-r--r-- 1 197121 109 Aug 19 00:04 complink.bat
-rw-r--r-- 1 197121 1019 Aug 26 01:21 stdioimpl.h
contents of bat file
F:\bugdesc>cat complink.bat
cl /nologo /W4 /Od /Zi /EHsc /I"C:\Program Files (x86)\Windows Kits\10\Debuggers\inc" %1.cpp /link /RELEASE
file containing implementation of StdioOutputCallbacks
F:\bugdesc>cat stdioimpl.h
#include <windows.h>
#include <stdio.h>
#include <dbgeng.h>
#pragma comment(lib, "dbgeng.lib")
class StdioOutputCallbacks : public IDebugOutputCallbacks {
public:
STDMETHOD(QueryInterface)(THIS_ _In_ REFIID ifid, _Out_ PVOID *iface);
STDMETHOD_(ULONG, AddRef)(THIS);
STDMETHOD_(ULONG, Release)(THIS);
STDMETHOD(Output)(THIS_ IN ULONG Mask, IN PCSTR Text);
};
STDMETHODIMP
StdioOutputCallbacks::QueryInterface(THIS_ _In_ REFIID ifid, _Out_ PVOID *iface){
*iface = NULL;
if (IsEqualIID(ifid, __uuidof(IDebugOutputCallbacks))){
*iface = (IDebugOutputCallbacks *)this;
AddRef();
return S_OK;
} else {
return E_NOINTERFACE;
}
}
STDMETHODIMP_(ULONG)
StdioOutputCallbacks::AddRef(THIS) { return 1; }
STDMETHODIMP_(ULONG)
StdioOutputCallbacks::Release(THIS) { return 0; }
STDMETHODIMP StdioOutputCallbacks::Output(THIS_ IN ULONG, IN PCSTR Text){
fputs(Text, stdout);
return S_OK;
}
contents of main source file
F:\bugdesc>cat bugdesc.cpp
#include "stdioimpl.h"
//implement proper error handling and release of Interfaces
void __cdecl main(void)
{
IDebugClient *g_Client;
IDebugControl *g_Control;
StdioOutputCallbacks g_OutputCb;
DebugCreate(__uuidof(IDebugClient), (void **)&g_Client);
g_Client->QueryInterface(__uuidof(IDebugControl), (void **)&g_Control);
g_Client->SetOutputCallbacks(&g_OutputCb);
g_Client->SetOutputCallbacks(&g_OutputCb);
g_Client->OpenDumpFile("F:\\bugdesc\\memory.dmp");
g_Control->WaitForEvent(0, INFINITE);
g_Control->Execute(0, "!analyze -show 9f 3", 0);
}
compiled and linked with vs-community 2017 as x64
F:\bugdesc>complink.bat bugdesc
F:\bugdesc>cl /nologo /W4 /Od /Zi /EHsc /I"C:\Program Files (x86)\Windows Kits\10\Debuggers\inc" bugdesc.cpp /link /RELEASE
bugdesc.cpp
contents of directory post compilation and linking
F:\bugdesc>ls -lg
total 159485
-rw-r--r-- 1 197121 156689581 Aug 17 23:49 MEMORY.DMP
-rw-r--r-- 1 197121 600 Aug 26 01:22 bugdesc.cpp
-rwxr-xr-x 1 197121 406016 Aug 26 01:25 bugdesc.exe
-rw-r--r-- 1 197121 30072 Aug 26 01:25 bugdesc.obj
-rw-r--r-- 1 197121 5992448 Aug 26 01:25 bugdesc.pdb
-rw-r--r-- 1 197121 109 Aug 19 00:04 complink.bat
-rw-r--r-- 1 197121 1019 Aug 26 01:21 stdioimpl.h
-rw-r--r-- 1 197121 176128 Aug 26 01:25 vc140.pdb
executing without proper dlls and failure
F:\bugdesc>bugdesc.exe
No .natvis files found at C:\WINDOWS\SYSTEM32\Visualizers.
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
Microsoft (R) Windows Debugger Version 10.0.18362.1 AMD64
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
Loading Dump File [F:\bugdesc\memory.dmp]
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
*** Type referenced: nt!_MMPTE_TRANSITION ***
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
For analysis of this file, run !analyze -v
No export analyze found<<<<<<<<<<<<<<<<<<
copying relevent dlls from windbg installation folder
F:\bugdesc>copy ..\windbg_dlls\*.* .
..\windbg_dlls\dbgeng.dll
..\windbg_dlls\dbghelp.dll
..\windbg_dlls\ext.dll
..\windbg_dlls\symsrv.dll
4 file(s) copied.
execution and success
F:\bugdesc>bugdesc.exe
Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
Loading Dump File [F:\bugdesc\memory.dmp]
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck E2, {0, 0, 0, 0}
Probably caused by : Unknown_Image
*** Followup info cannot be found !!! Please contact "BADEV"
---------
DRIVER_POWER_STATE_FAILURE (9f)<<<<<<<<<<<<<<<<<<<<<<<
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: 0000000000000000, Physical Device Object of the stack
Arg3: 0000000000000000, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: 0000000000000000, The blocked IRP
xxxxxxxxxxxxxxxxxxxxxxxxxxx snip
I have the following code in a DLL:
#pragma data_seg("ABC")
__declspec (dllexport) char abc[2000] = { 0 };
#pragma data_seg()
#pragma comment(linker, "-section:ABC,rws")
I have the following code in an executable:
extern "C" __declspec(dllimport) char abc[];
char *abcPtr = abc;
#define iVar0 (*(long *)(abcPtr))
int main()
{
printf("Value: %d %p\n", iVar0, &iVar0);
iVar0 = 66;
printf("Value: %d %p\n", iVar0, &iVar0);
char buffer[256];
scanf_s("%s", buffer, 256);
}
When I run the first instance of the program I get:
Value: 0 0FC2A000
Value: 66 0FC2A000
If I run a second instance I get the following because they are using the same shared section:
Value: 66 0FC2A000 <- Notice the value here is set
Value: 66 0FC2A000
However if I change the value in the first instance using Visual Studio debugger, I can see that it changed in the memory location; however, I cannot see the value change if I rerun the second instance.
Why is the debugger not able to write the actual shared (memory) section?
I got the same result as yours:
My understanding is that certain value was not shared in the shared memory during debugging.
https://blogs.msdn.microsoft.com/oldnewthing/20040804-00/?p=38253/
I've seen lots of questions about getting a file's path from it's inode, but almost none about doing the reverse. My kernel module needs to do this to get further information about the subjects of requests passed to open(), such as its file flags or whether or not it's a device. From what I was able to scrounge together from mailing lists, manual pages, and the Linux source code, I came up with this small function:
struct inode* get_inode_from_pathname(const char *pathname) {
struct path path;
kern_path(pathname, LOOKUP_FOLLOW, &path);
return path.dentry->d_inode;
}
Trying to use it in my replacement system call makes kernel messages get printed to the console, though:
struct inode *current_inode;
...
asmlinkage int custom_open(char const *__user file_name, int flags, int mode) {
current_inode = get_inode_from_pathname(file_name);
printk(KERN_INFO "intercepted: open(\"%s\", %X, %X)\n", file_name, flags, mode);
printk(KERN_INFO "i_mode of %s:%hu\n", file_name, current_inode->i_mode);
return real_open(file_name, flags, mode);
}
Is there a better way to do this? I'm almost positive my way is wrong.
You can use the kern_path kernel API to get the inode information from the path string. This function in turn calls the do_path_lookup() function which performs the path look up operation. You can verify the results of the kern_path function by printing the inode number (i_ino field of the inode structure) of the inode you get from your get_inode_from_pathname function and matching it with the inode number from an ls command (ls -i <path of the file>)
I made the following kernel module and it's not crashing the kernel. I am using 2.6.39 kernel.
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/mount.h>
#include <linux/path.h>
#include <linux/namei.h>
#include <linux/fs.h>
#include <linux/namei.h>
char *path_name = "/home/shubham/test_prgs/temp.c";
int myinit(void)
{
struct inode *inode;
struct path path;
kern_path(path_name, LOOKUP_FOLLOW, &path);
inode = path.dentry->d_inode;
printk("Path name : %s, inode :%lu\n", path_name, inode->i_ino);
return 0;
}
void myexit(void)
{
return;
}
module_init(myinit);
module_exit(myexit);
//MODULE_AUTHOR("Shubham");
//MODULE_DESCRIPTION("Module to get inode from path");
MODULE_LICENSE("GPL");
MODULE_LICENSE("GPL v2");
Can you send the crash stack trace?
I guess the author has already fixed his problem, but this question was the first link in google's search results, so I'll explain it further.
The problem with the code from the question was using __user pointer.
When you hook a function that deals with __user pointers, first thing you have to make is to copy content to your own kernel buffer where you will deal with it or make sure that pointer won't become invalid while you are dealing with it.
To copy it to your buffer you could use copy_from_user function
char path[MAX_PATH] = {0};
if (copy_from_user(path, user_path, strlen_user(user_path))
{
//error
}
//success
If you hook sys_open, you can use getname/putname functions, as it is done in do_sys_open function:
1010 long do_sys_open(int dfd, const char __user *filename, int flags, umode_t mode)
1011 {
1012 struct open_flags op;
1013 int fd = build_open_flags(flags, mode, &op);
1014 struct filename *tmp;
1015
1016 if (fd)
1017 return fd;
1018
1019 tmp = getname(filename);
1020 if (IS_ERR(tmp))
1021 return PTR_ERR(tmp);
1022
1023 fd = get_unused_fd_flags(flags);
1024 if (fd >= 0) {
1025 struct file *f = do_filp_open(dfd, tmp, &op);
1026 if (IS_ERR(f)) {
1027 put_unused_fd(fd);
1028 fd = PTR_ERR(f);
1029 } else {
1030 fsnotify_open(f);
1031 fd_install(fd, f);
1032 }
1033 }
1034 putname(tmp);
1035 return fd;
1036 }
ps: code from S_S's answer won't crash because in fact it allocated buffer for path inside kernel, so it couldn't become invalid while the module is working with it.
Why is name mangling still applied to func3()'s signature.
What am I missing? I've reviewed these previously asked questions 1, 2
NO DEF files are being referenced.
// dllmain.cpp
#include "stdafx.h"
extern "C" __declspec( dllexport ) double __cdecl func1(int id, double t)
{
return(1.01);
};
extern "C" __declspec( dllexport ) int __cdecl func2(int id)
{
return(2);
};
extern "C" __declspec( dllexport ) int __cdecl func3(char* file)
{
return(1);
};
......
Here's output from dumpbin /EXPORTS:
00000000 characteristics
51B78F5E time date stamp Tue Jun 11 13:58:06 2013
0.00 version
1 ordinal base
3 number of functions
3 number of names
ordinal hint RVA name
1 0 00003870 func1 = func1
2 1 00003880 func2 = func2
3 2 00001A00 func3 = ?do_encoding#codecvt_base#std##MEBAHXZ (protected: virtual int __cdecl std::codecvt_base::do_encoding(void)const )
The exports are not mangled, you can clearly see the unmangled name in the dumpbin.exe output. You also see the mangled name. That's dumpbin.exe being a bit too helpful, perhaps, it also reads the .pdb file to find the actual name of the function. It displays it on the right-hand side of the =
Simply delete the .pdb file and run dumpbin.exe again to see the difference.
You don't have a problem, it worked.