Please excuse my newbie question but when I tried exporting a function in the header using
__declspec(dllexport) void testfunction(double i);
and declared the function in the .cpp file like this
void testfunction(double i) {
for (int k = 0; k<10; k++) {
double j = 0.1;
}
}
I only see this for the function after disassembling the .exe file using IDA pro:
.text:00401130 ; void __cdecl testfunction(double)
.text:00401130 public ?testfunction##YAXN#Z
.text:00401130 ?testfunction##YAXN#Z proc near ; DATA XREF: .rdata:off_40BE88o
.text:00401130 jmp dword_40C000
.text:00401130 ?testfunction##YAXN#Z endp
Below I have provided the location of dword_40C000
.data:0040C000 ; Section 3. (virtual address 0000C000)
.data:0040C000 ; Virtual size : 000004A0 ( 1184.)
.data:0040C000 ; Section size in file : 00000200 ( 512.)
.data:0040C000 ; Offset to raw data for section: 0000B200
.data:0040C000 ; Flags C0000040: Data Readable Writable
.data:0040C000 ; Alignment : default
.data:0040C000 ; ===========================================================================
.data:0040C000
.data:0040C000 ; Segment type: Pure data
.data:0040C000 ; Segment permissions: Read/Write
.data:0040C000 _data segment para public 'DATA' use32
.data:0040C000 assume cs:_data
.data:0040C000 ;org 40C000h
.data:0040C000 dword_40C000 dd 6000001h ; DATA XREF: testfunction(double)r
.data:0040C004 align 10h
.data:0040C010 db 2
.data:0040C011 db 0
.data:0040C012 db 0
.data:0040C013 db 0
.data:0040C014 db 2
.data:0040C015 db 0
.data:0040C016 db 0
.data:0040C017 db 0
.data:0040C018 dword_40C018 dd 6000003h ; DATA XREF: .text:004011A0r
.data:0040C01C dword_40C01C dd 6000004h ; DATA XREF: .text:004011D0r
.data:0040C020 dword_40C020 dd 6000005h ; DATA XREF: .text:00401200r
...
Shouldn't there be more code since I have a for loop and some other stuff? Where is the actual code?
It seems you're using C++/CLI. I think the 6000001 is the managed method's token, it will be replaced by the address of the JITted code at runtime.
Compile your binary for native x86 to see machine code.
Related
I have two NetCDF files with the exact same dimensions (time,lat,lon). Below is the header of one of the files.
netcdf file1 {
dimensions:
lon = 360 ;
lat = 177 ;
time = 360 ;
variables:
double lon(lon) ;
lon:units = "degrees_east" ;
lon:long_name = "Longitude" ;
double lat(lat) ;
lat:units = "degrees_north" ;
lat:long_name = "Latitude" ;
double time(time) ;
time:long_name = "Time" ;
time:units = "months since 1989-05-01 00:00" ;
double tmp(time, lat, lon) ;
tmp:_FillValue = -999000000. ;
}
I would like to copy values from one file into the other, but only for a small region determined by lat1,lat2 and lon1,lon2. Both files have the same time coordinates.
Something like: (lon1<lon<=lon2) & (lat1<lat<=lat2) file1 = file2
I was wondering if I could do that with NCO.
Any help will be appreciated. Thank
Read the manual section on the ncap2 where function. It describes how to use where on a hyperslab. That will do it:
*var_tmp=var2(:,0,:,:);
where (var1 < 0.5) var_tmp=1234;
var2(;,0,:,;)=var_tmp;
I want to use GetProcAddress to get some functions addresses inside a loaded DLL. I run some attempts on PSAPI library and I can see the the expected proc name is not identical to the symbol names I find with WinDbg x statements. For example, I look for "EnumProcessModules"(which is the name expected by GetProcAddress method) with x psapi!*EnumProcessModules* and I find
00007ff9`fe112210 PSAPI!_imp_K32EnumProcessModulesEx = <no type information>
00007ff9`fe111360 PSAPI!EnumProcessModulesExStub (<no parameter info>)
00007ff9`fe111030 PSAPI!EnumProcessModulesStub (<no parameter info>)
00007ff9`fe1121a8 PSAPI!_imp_K32EnumProcessModules = <no type information>
When I provide any of the found symbols above (with or without "PSAPI!" as a prefix) to the GetProcAddress method as the second parameter (procName) - it returns NULL, but when I use the method name "EnumProcessModules" - it returns 0xfe111030, which is the address of "PSAPI!EnumProcessModulesStub".
How could I know the expected procName in advance? What if I have 2 different classes or namespaces with the same method name in one DLL? How can I distinguish between the two method names when I call GetProcAddress?
PSAPI! is just a prefix, it's the DLL name printed by WinDbg. That's used to disambiguate names. A clear example why this is useful: you will have many DllMain's in your process.
The expected name for GetProcAddress is the documented name of the function, as stated on MSDN. Keep in mind that you will need to add either the A or W suffix when MSDN states both versions are available. E.g. you can't call GetProcAddress with "GetDeviceDriverFileName", you need either "GetDeviceDriverFileNameA" or L"GetDeviceDriverFileNameW".
For non-system DLL's, you need the function name from the Export Address Table.
Background: What you see in WinDbg is the name from the .PDB, which as you have discovered can differ from the exported name. There is nothing which enforces a relation between the two. For instance, it's technically possible to have PDB names Foo and Bar, and have them swapped in the Export Address Table. More realistically, Microsoft may internally add an _wrapper_EnumProcessModules at any time, but the documented and exported name will stay EnumProcessModules.
The Core Functionality for this API is implemented in kernel32.dll
and Named K32EnumProcessModules
in paspi.h header this API is ifdeffed based on PSAPI_VERSION
#ifndef PSAPI_VERSION
#if (NTDDI_VERSION >= NTDDI_WIN7)
#define PSAPI_VERSION 2
#else
#define PSAPI_VERSION 1
#endif
#endif
#if (PSAPI_VERSION > 1)
#define EnumProcessModules K32EnumProcessModules
if you GetProcAddress in psapi.dll you get a stub which gets transferred to kernel32.dll
0:001> u PSAPI!EnumProcessModulesStub l 5
PSAPI!EnumProcessModulesStub:
762d1408 8bff mov edi,edi
762d140a 55 push ebp
762d140b 8bec mov ebp,esp
762d140d 5d pop ebp
762d140e eb05 jmp PSAPI!K32EnumProcessModules (762d1415)
0:001> u 762d1415 l1
PSAPI!K32EnumProcessModules:
762d1415 ff2504102d76 jmp dword ptr [PSAPI!_imp__K32EnumProcessModules (762d1004)]
0:001> u poi(762d1004) l1
kernel32!K32EnumProcessModules:
7668cc52 8bff mov edi,edi
you can use dumpbin /exports on the dll to see if there is any correlation
or if there is a name change (see the Stub#16 )
:\>dumpbin /exports c:\windows\System32\psapi.dll | grep -w EnumProcessModules
5 4 00001408 EnumProcessModules = _EnumProcessModulesStub#16
you could also find the same info from the export table of psapi.dll using some thing like below
0:001> .shell -ci "!dh psapi" grep Export
1088 [ 359] address [size] of Export Directory
.shell: Process exited
0:001> dt ole32!_IMAGE_EXPORT_DIRECTORY (psapi + 1088)
+0x000 Characteristics : 0
+0x004 TimeDateStamp : 0x4a5bc026
+0x008 MajorVersion : 0
+0x00a MinorVersion : 0
+0x00c Name : 0x11be
+0x010 Base : 1
+0x014 NumberOfFunctions : 0x1b
+0x018 NumberOfNames : 0x1b
+0x01c AddressOfFunctions : 0x10b0
+0x020 AddressOfNames : 0x111c
+0x024 AddressOfNameOrdinals : 0x1188
0:001> r? $t0 = (int *) ##(psapi + 10b0)
0:001> r? $t1 = (int *) ##(psapi + 111c)
0:001> r? $t2 = (short *) ##(psapi + 1188)
0:001> .printf "%x %ma %y\n" , ##(#$t2[4]) , (##(#$t1[4]) + psapi) , (##(#$t0[4]) + psapi)
4 EnumProcessModules PSAPI!EnumProcessModulesStub (762d1408)
I am trying to copy a set of instructions from source Basic block to 2 or more destination basic blocks. After copying I wish to remove the instructions from the source basic block, then delete source basic block.
After struggling a bit with the API I get the following results.
Destination basic blocks
then: ; preds = %entry
store i8000000 0, i8000000* %res
;after copying
**Issue-----> %res45 = load i8000000, i8000000* %res
ret i8000000 %res4 <----- Issue**
br label %continuation
else: ; preds = %entry
store i8000000 0, i8000000* %res
;after copying
**Issue----->%res46- = load i8000000, i8000000* %res
ret i8000000 %res4 <----- Issue**
br label %continuation
Source basic block
continuation: ; preds = %else, %then
%iftmp = phi i32 [ 5, %then ], [ 9, %else ]
store i32 %iftmp, i32* %datasize
; 3 lines below to be copied and then this whole basic block needs to be deleted.
store i8000000 0, i8000000* %res
%res4 = load i8000000, i8000000* %res
ret i8000000 %res4
}
relevant chunk of Code
// startInst/endInst are iterators to the instructions where I start/finish copying.
for (auto i = startInst, e = endInst; i != e; ++i) {
Instruction* temp = i->clone();
temp->insertBefore(terminatorInst);
Value* copyInstVal = temp;
Value* originalInstVal = &(*i);
copyInstVal->setName(originalInstVal->getName());
}
My issue
I have been using Instruction::clone() to copy the instructions and then set a name for this clone.
My major issue is that I need to maintain the same dependency between the instructions once I copy them into a new basic block.However , SSA register names ( LHS of instructions ) cannot be the same within a LLVM function and hence this problem.
Is there any way to use the API to achieve this ?
As an example - seen marked "Issue" above , the "ret" instruction is returning the old "%res" value.
How can I make sure that it returns the "%res45" and "%res46" in each of the destination basic blocks?
I have been developing a Bootloader and have run into a problem when linking c++ code to my assembly stage2 code before I linked the files the second stage would jump to protected mode then to long mode without any problems but now after I have linked it there seems to be a problem when jumping to protected mode Here is the code I use to jump to protected mode:
main:
;first stage of bootloader is loaded at the address 0x07c0:0
;second stage of bootloader is loaded at address 0x200:0x0
cli
xor ax, ax ; All segments set to 0, flat memory model
mov ds, ax
mov es, ax
mov gs, ax
mov fs, ax
mov ss, ax
;
; Set stack top SS:0xffff
;
mov sp, 0x0FFFF
;
mov [CDDriveNumber], dl
SwitchToProtectedMode:
lgdt [GDT_32];load the gdt
call EnableA20
mov eax, cr0
or eax, 1
mov cr0, eax
; Flush CS and set code selector
;
jmp 0x8:Protected_Mode
[BITS 32];Declare 32 bits
Protected_Mode:
Here is the GDT:
GDT_START:
;null descriptor
dd 0
dd 0
;data descriptor
dw 0xFFFF
dw 0
db 0
db 10011010b
db 11001111b
db 0
;code descriptor
dw 0xFFFF
dw 0
db 0
db 10010010b
db 11001111b
db 0
GDT_END:
align 4
GDT_32:
dw GDT_END - GDT_START - 1
dd GDT_START
Here is the linker script I use to link my c and assembly code
KernAddr = 0x200;
ENTRY(_Start)
SECTIONS
{
. = KernAddr;
.text : AT(ADDR(.text) - KernAddr)
{
_code = .;
*(.text)
*(.rodata*)
. = ALIGN(4096);
}
.data : AT(ADDR(.data) - KernAddr)
{
_data = .;
*(.data)
. = ALIGN(4096);
}
.eh_frame : AT(ADDR(.eh_frame) - KernAddr)
{
_ehframe = .;
*(.eh_frame)
. = ALIGN(4096);
}
.bss : AT(ADDR(.bss) - KernAddr)
{
_bss = .;
*(.bss)
/*
* You usually need to include generated COMMON symbols
* under kernel BSS section or use gcc's -fno-common
*/
*(COMMON)
. = ALIGN(4096);
}
_end = .;
/DISCARD/ :
{
*(.comment)
}
}
Here is the batch program I made to build everything:
nasm Stage1.asm -o Stage1.bin
nasm -f elf64 Stage2.asm -o Stage2.o
x86_64-elf-g++ -ffreestanding -mcmodel=large -mno-red-zone -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -c -o kernel.o kernel.cpp
x86_64-elf-ld -T linkerscript.ld -o Anmu.bin Stage2.o kernel.o -nostdlib
copy Stage1.bin Root
copy Anmu.bin Root
mkisofs -b Stage1.bin -no-emul-boot -boot-info-table -o BootLoader.iso ./Root
The rest of the code is available here: https://github.com/AnonymousUser1337/Anmu
You say that Stage2 is loaded at segment 0x0200, which is address 0x2000, but your linker says it starts at offset 0x0200.
Also, despite naming your output "Anmu.bin", your file is actually still an ELF executable, which means all of the headers and whatnot are still present in the file. Instead, you need to use objcopy to strip all of the headers and debugging symbols, giving you a flat binary:
objcopy -S -O binary Anmu.bin Anmu-flat.bin
Now, "Anmu-flat.bin" is nothing but code and data, and the first byte of the file is the start of the first instruction.
With LLVM I am trying to find out if an Instruction is present within flow control (if/switch/for) etc and I have to do this at the IR level. A pseudo-code is something like this as below.
if cond
inst
endif
I am looking at the SCC of the function but I am not sure how to deduce for sure if an instruction does exist within a flow control or not.
Taking the example from the Kaleidoscope example for this IR.
declare double #foo()
declare double #bar()
define double #baz(double %x) {
entry:
%ifcond = fcmp one double %x, 0.000000e+00
%0 = call double #foo()
br i1 %ifcond, label %then, label %else
then: ; preds = %entry
%calltmp = call double #foo()
br label %ifcont
else: ; preds = %entry
%calltmp1 = call double #bar()
br label %ifcont
ifcont: ; preds = %else, %then
%iftmp = phi double [ %calltmp, %then ], [ %calltmp1, %else ]
%1 = call double #foo()
ret double %iftmp
}
So in the above IR, lets say I want to find out all the calls to the function foo. So in the entry block we have one call with %0 and one in the then: block we have another call to foo and the last one in the ifcont: block.
So the question is that although the call in the then: block falls in the code generated from if block, how do I deduce that ? i.e. entry block & ifcont block will be executed, however the then: block won't be necessarily executed depending on the condition.
Could someone give me some pointers ?
Thanks
Edit: Giving some more thought, Dominator trees might help in determining this but I don't have an algorithm for this yet.
Here's a definition of instruction post-domination from Wikipedia:
Analogous to the definition of dominance above, a node z is said to
post-dominate a node n if all paths to the exit node of the graph
starting at n must go through z.
It seems to me that in your case you're looking for calls that post-dominate the first instruction in the function. Such calls, by definition of post-domination, must be reached on every path from the first instruction. Is this what you need?
You can run the DominatorTree pass which seems to support post-domination analysis.