std::getline and UTF16 (LE) filestream - not working - c++11

Well the following should work - I can't find a reason why it shouldn't:
std::fstream f;
std::string myoutput;
f.imbue(std::locale(f.getloc(), new std::codecvt_utf16<wchar_t, std::little_endian | std::consume_header>));
f.open("c:\\test.txt", std::ios::in);
std::getline(f, myoutput);
The code is executed on the following file (in hex - it should spell "hello world"):
FF FE 68 00 65 00 6C 00 6C 00 6F 00 20 00 77 00 6F 00 72 00 6C 00 64
00
The ultimate goal is to abstract the encoding away, always consider a file UTF-8 unless the first bytes are a BOM. Now above code would be executed after reading a BOM and noticing it is UTF-16. It should hence read UTF-16 file, and convert it to a utf-8 string.
However the std::getline does not ignore the BOM (easily fixed) but furthermore it does not respect the fact that UTF-16 uses 2 bytes. (And it stops after reading the first 3 bytes upon seeing "0" ).
Now of course I could use std::wfstream. But as I wish to "hide" the unicode type from the user for one thing all the "filestreams" are stored inside a container for referencing. So the signature of all those filestreams has to be equal - and be based on char and std::string

If you opened your file as basic_fstream<char>, you've already set both external and internal character width to 1 byte and the locale facet you're applying will never be used.
Either read into a string and apply wstring_convert twice, or apply wbuffer_convert to make the internal character width bigger, and then wstring_convert:
std::fstream f;
f.open("test.txt", std::ios::in | std::ios::binary);
std::wbuffer_convert<std::codecvt_utf16<wchar_t,
0x10ffff, // note your 2nd parameter was wrong
std::little_endian // or consume_header, not both
>> cvt1(f.rdbuf());
std::wistream wide_f(&cvt1);
std::wstring wstr;
std::getline(wide_f, wstr);
std::wstring_convert<std::codecvt_utf8<wchar_t>> cvt2;
std::string u8str = cvt2.to_bytes(wstr);
std::cout << u8str << '\n';

Related

Windows Recycle Bin information file binary format

Programmatic removing of files to Recycle Bin in Windows is a trivial operation.
In short: just move a file to
C:\$Recycle.Bin\SID\$R{name}* (for drive C) and create an associated binary file ($I{name}) with meta information about the "deleted" file/folder near it.
* where SID is your OS installation identifier that looks like: S-1-5-21-1234567890-1234567890-1234567890-1001.
But I have two question after researching:
What is the algorithm of encoding the deletion date to 64-bit value?
Are the file names (in a trash bin) random generated or there is some logic?
The information file structure is follow (based on my research):
const buffer = new Uint8Array([
0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Header
0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // Size // 65535 (bytes)
0x00, 0x00, 0x00, 0x00, 0x00, 0x30, 0xd7, 0x01, // Deletion date (64-bit value)
0x0b, 0x00, 0x00, 0x00, // Path string length // `11`
0x43, 0x00, 0x3a, 0x00, // File path + \0 // `C:\1\1.txt` // `C:\\1\\1.txt\0`
0x5c, 0x00, 0x31, 0x00, 0x5c, 0x00, 0x31, 0x00,
0x2e, 0x00, 0x74, 0x00, 0x78, 0x00, 0x74, 0x00,
0x00, 0x00
]);
Header (always is the same), file size in bytes (which is only visible in File Explorer), 64-bit deletion date value, path string length, and UTF-16 encoded null-terminated path string.
The only questionable part is the date. How is it encoded?
For example:
00 00 00 00 00 29 d7 01 is 2021.04.04 03:10
00 00 00 00 01 29 d7 01 is 2021.04.04 03:17
00 00 00 00 00 30 d7 01 is 2021.04.13 00:57
(The first four hexes is 00 just for convenience.)
For example: 00 00 00 00 00 29 d7 01 is 132619794007457792, but new Date(132619794007457792/100000) is 2012.01.10 12:19:00.
I need to transform 00 00 00 00 00 29 d7 01 bytes to 2021.04.04 03:10.
The "deleted" files in C:\$Recycle.Bin\SID\ have name that is started with $R + [A-Z0-9]{7} + optional .{extension}.
For example: $RL6JQMF.txt.
And associated meta data file: $IL6JQMF.txt that just starts with $I.
Is there some logic for the naming or it is just a random generated one?
In fact, for example, it works well with both $R___ + $I___, and with $R123456789 abc + $I123456789 abc. So, I think it is just random generated.
Only the $R/$I is required. The extension is needed only just to shows the corresponding icon in the File Explorer.
Okay, I got it.
While
00 00 00 00 00 00 00 00 is 1899.12.30 00:00,
but 00 00 00 00 00 00 01 00 is 1601.11.22 18:44,
so this timestamp is a number of 100-nanosecond intervals since 1601.01.01.
For example, for 00 00 00 00 00 29 d7 01 (132619794007457792) I get the correct date (2021.04.04 03:10) as it shows in File Explorer with:
new Date(132619794007457792 / 10000 + Number(new Date("1601.01.01 Z")))
Anyway, I think this topic would be useful for people.
It's strange that in 2021 I did not found any info about how Recycle Bin in Windows works.
Ive done some extensive research on this, as it seems, surprisingly, there is very few info available online on how Recycle Bin actually implemented.
Everything is not that hard to grasp. When you delete file in the Bin, it is not actually moved to it.
First, lets take a look at the subfolders of $Recycle.Bin:
C:\$Recycle.Bin\S-1-5-18 is folder for built-in SYSTEM account
C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\, starting from 1000 are non-built in user folders. You should first check which one of them is the one you need by typing whoami /all in command prompt to get your SID, or wmic useraccount get name,sid to get all local accounts SIDs, then choose the folder matching with SID.
If you give security rights to your account to all this folders, Explorer might show your deleted files in every folder, however its just Explorer bug. If you navigate to, say, C:\$Recycle.Bin\S-1-5-18 folder and type dir /a, you will see that its actually empty, and only folder that match with your SID contains your deleted files.
Note that even if you are the only user on the PC, you might still have folder C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1000\ that most likely will be empty. Then your actual folder will be ...-1001\. User "1000" seems to be dangling folder for user that was created automatically by Windows on installation or some updates, then deleted. But Recycle.Bin folder wasn't destroyed and just stayed there. I assume that its safe to delete this dangling folder. I'm not so sure about C:\$Recycle.Bin\S-1-5-18, but I'm fairly sure its safe too, as there is no need for OS SYSTEM account to use the Bin, anyway.
So, here is deletion algorithm:
System creates hardlink of the deleted file in C:\$Recycle.Bin\S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-1XXX\ folder with the name $RXXXXXX.<file_ext>, where XXXXXX is 6 symbols HASH calculated based on the file contents, as I assume.
Metadata file is created in the same folder with the name $IXXXXXX.<file_ext>. I will show you the content of this file later.
Original file is deleted, but because of extra hardlink in $Recycle.Bin, actual file's data stays in the same location on the drive as if file where never touched. It is not moved anywhere. This is why each logical volume must have it's own $Recycle.Bin folder, as hardlinks only work within the same volume.
That's about it. Restoration algorithm:
Metadata file is read and hardlink of $RXXXXXX.<file_ext> is created based on $IXXXXXX.<file_ext>'s info in original file location, with original file name.
Both metadata and backup file are deleted from $Recycle.Bin
Pretty simple, ain't it?
Now, the most interesting part is that metadata file:
0000 02 00 00 00 00 00 00 00 <-- File header (QW)
0008 00 7C 0A 00 00 00 00 00 <-- File size (QW)
0010 90 83 72 44 28 9C D8 01 <-- File deletion date (QW)
0018 18 00 00 00|43 00 3A 00 <-- File path string length (DW)
0020 5C 00 24 00 52 00 65 00
0028 63 00 79 00 63 00 6C 00
0030 65 00 2E 00 42 00 69 00
0038 6E 00 5C 00 66 00 73 00
0040 73 00 2E 00 65 00 78 00
0048 65 00 00 00| <-- |Null-terminated path string| (wchar_t)
All values are in Little Endian format.
Header is fixed and its identical for all the files. Be warned that some $I files might have some junk bytes FF FE appear before the Header. I have no idea what are this for, so you should check for full header before reading further.
Deletion date is in FILETIME format and can be converted to usual SYSTEMTIME via FileTimeToSystemTime. It represents 100-nanosecond intervals since January 1, 1601 (UTC).
So it's not super complicated file format, but quite interesting design.
I'm planing to use this info myself by creating custom "garbage collector" for Windows, that I will add to task scheduler to launch periodically and scan\delete files that where deleted more than 24 hours ago, etc. I know that Windows 10 has built-in option for this, but it's not flexible and not reliable (it sometimes leaves metadata files, while only deleteing $R files). Also, I think, previous Windows versions doesn't have this feature at all.
I encourage you to experiment with this too! For example, your program might save metadata info of all files it removes into some database, so you would have full history of all files you ever deleted!

how to use SymGetSourceFile api for fetching source file in postmortem debugging

I want to use SymGetSourceFile to get a source file from source server using info from a dump file. But the first param is a handle to process but during postmortem we dont have a process, so is it meant to be used only for live debugging tools? How can I use it from a postmortem debugging tool?
BOOL IMAGEAPI SymGetSourceFile(
HANDLE hProcess,
ULONG64 Base,
PCSTR Params,
PCSTR FileSpec,
PSTR FilePath,
DWORD Size
);
https://learn.microsoft.com/en-us/windows/win32/api/dbghelp/nf-dbghelp-symgetsourcefile
Update:
I have tried using IDebugAdvanced3 interface for same but get HR = 0x80004002 for GetSourceFileInformation call.
char buf[1000] = { 0 };
HRESULT hr = g_ExtAdvanced->GetSourceFileInformation(DEBUG_SRCFILE_SYMBOL_TOKEN,
"Application.cs",
0x000000dd6f5f1000, 0, buf, 1000, 0);
if (SUCCEEDED(hr))
{
dprintf("GetSourceFileInformation = %s", buf);
char buftok[5000] = { 0 };
hr = g_ExtAdvanced->FindSourceFileAndToken(0, 0x000000dd6f5f1000,
"Application.cs", DEBUG_FIND_SOURCE_TOKEN_LOOKUP,
buf, 1000, 0, buftok, 5000, 0);
if (SUCCEEDED(hr))
{
dprintf("FindSourceFileAndToken = %s", buf);
}
else
dprintf("FindSourceFileAndToken HR = %x", hr);
}
else
dprintf("GetSourceFileInformation HR = %x", hr);
I have dump that has this module and pdb loaded. and pass an address within the module - 0x000000dd6f5f1000, to GetSourceFileInformation
this was a comment but grew up so addingas answer
GetSourceFileINformation iirc checks the source servers those that start with srv or %srcsrv%
this returns a token for use with findsourcefileandtoken
if you have a known offset (0x1070 == main() in case below )
use GetLineByOffset this has the added advantage of reloading all the modules
hope you have your private pdb for the dump file you open.
this is engext syntax
Hr = m_Client->OpenDumpFile("criloc.dmp");
Hr = m_Control->WaitForEvent(0,INFINITE);
unsigned char Buff[BUFFERSIZE] = {0};
ULONG Buffused = 0;
DEBUG_READ_USER_MINIDUMP_STREAM MiniStream ={ModuleListStream,0,0,Buff,BUFFERSIZE,Buffused};
Hr = m_Advanced2->Request(DEBUG_REQUEST_READ_USER_MINIDUMP_STREAM,&MiniStream,sizeof(
DEBUG_READ_USER_MINIDUMP_STREAM),NULL,NULL,NULL);
MINIDUMP_MODULE_LIST *modlist = (MINIDUMP_MODULE_LIST *)&Buff;
Hr = m_Symbols->GetLineByOffset(modlist->Modules[0].BaseOfImage+0x1070,&Line,
FileBuffer,0x300,&Filesize,&Displacement);
Out("getlinebyoff returned %x\nsourcefile is at %s line number is %d\n",Hr,FileBuffer,Line);
this is part src adapt it to your needs.
the result of the extension command is pasted below
0:000> .load .\mydt.dll
0:000> !mydt
Loading Dump File [C:\Users\xxxx\Desktop\srcfile\criloc.dmp]
User Mini Dump File with Full Memory: Only application data is available
OpenDumpFile Returned 0
WaitForEvent Returned 0
Request Returned 0
Ministream Buffer Used 28c
06 00 00 00 00 00 8d 00 00 00 00 00 00 e0 04 00
f0 9a 05 00 2d 2e a8 5f ba 14 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
43 00 00 00 4a 38 00 00 00 00 00 00 00 00 00 00
40 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00
No of Modules =6
Module[0]
Base = 8d0000
Size = 4e000
getlinebyoff returned 0
sourcefile is at c:\users\xxx\desktop\misc\criloc\criloc.cpp line number is 21 <<<<<<<<<
||1:1:010> lm
start end module name
008d0000 0091e000 CRILOC (private pdb symbols) C:\Users\xxxx\Desktop\misc\CRILOC\CRILOC.pdb
||1:1:010>
and the actual source file contents on path
:\>grep -i -n main CRILOC.CPP
20:int main(void) << the curly braces is on line 21
UPDATE:
yes if the src file is not source indexed (cvs,perforce,... ) GetSourceFileInformation () will not return a token
it checks for a token using the Which parameter
and the returned info can be used in FindSourceFileAndToken();
if your source is not source indexed and you only have a source path
use FindSourceFileandToken() with DEBUG_FIND_SOURCE_FULL_PATH Flag
be aware you need to either use SetSourcePath() or issue .srcpath command or use _NT_SOURCE_PATH environment variable or use -srcpath commandline switch prior to invoking FindSourceFileAndToken()
see below for a walkthrough
sourcefile and contents
:\>ls *.cpp
mydt.cpp
:\>cat mydt.cpp
#include <engextcpp.cpp>
#define BSIZE 0x1000
class EXT_CLASS : public ExtExtension {
public:
EXT_COMMAND_METHOD(mydt);
};
EXT_DECLARE_GLOBALS();
EXT_COMMAND( mydt, "mydt", "{;e,o,d=0;!mydt;}" ){
HRESULT Hr = m_Client->OpenDumpFile("criloc.dmp");
Hr = m_Control->WaitForEvent(0,INFINITE);
char Buff[BSIZE] = {0};
ULONG Buffused = 0;
DEBUG_READ_USER_MINIDUMP_STREAM MiniStream ={ModuleListStream,0,0,
Buff,BSIZE,Buffused};
Hr = m_Advanced2->Request(DEBUG_REQUEST_READ_USER_MINIDUMP_STREAM,&MiniStream,
sizeof(DEBUG_READ_USER_MINIDUMP_STREAM),NULL,NULL,NULL);
MINIDUMP_MODULE_LIST *modlist = (MINIDUMP_MODULE_LIST *)&Buff;
//m_Symbols->SetSourcePath("C:\\Users\\xxx\\Desktop\\misc\\CRILOC");
char srcfilename[BSIZE] ={0};
ULONG foundsize =0 ;
Hr = m_Advanced3->FindSourceFileAndToken(0,modlist->Modules[0].BaseOfImage,"criloc.cpp",
DEBUG_FIND_SOURCE_FULL_PATH,NULL,0,NULL,srcfilename,0x300,&foundsize);
Out("gsfi returned %x\n" , Hr);
Out("srcfilename is %s\n",srcfilename);
}
compiled and linked with
:\>cat bld.bat
#echo off
set "INCLUDE= %INCLUDE%;E:\windjs\windbg_18362\inc"
set "LIB=%LIB%;E:\windjs\windbg_18362\lib\x86"
set "LINKLIBS=user32.lib kernel32.lib dbgeng.lib dbghelp.lib"
cl /LD /nologo /W4 /Od /Zi /EHsc mydt.cpp /link /nologo /EXPORT:DebugExtensionInitialize /Export:mydt /Export:help /RELEASE %linklibs%
:\>bld.bat
mydt.cpp
E:\windjs\windbg_18362\inc\engextcpp.cpp(1849): warning C4245: 'argument': conversion from 'int' to 'ULONG64', signed/unsigned mismatch
Creating library mydt.lib and object mydt.exp
:\>file mydt.dll
mydt.dll; PE32 executable for MS Windows (DLL) (GUI) Intel 80386 32-bit
executing
:\>cdb cdb
Microsoft (R) Windows Debugger Version 10.0.18362.1 X86
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ntdll!LdrpDoDebuggerBreak+0x2c:
77d805a6 cc int 3
0:000> .load .\mydt.dll
0:000> .chain
Extension DLL chain:
.\mydt.dll: API 1.0.0, built Thu Mar 18 20:40:04 2021
[path: C:\Users\xxxx\Desktop\srcfile\New folder\mydt.dll]
0:000> !mydt
Loading Dump File [C:\Users\xxxx\Desktop\srcfile\New folder\criloc.dmp]
User Mini Dump File with Full Memory: Only application data is available
gsfi returned 80004002
srcfilename is
||1:1:010> .srcpath "c:\\users\\xxxx\\desktop\\misc\\criloc\\"
Source search path is: c:\\users\\xxxx\\desktop\\misc\\criloc\\
************* Path validation summary **************
Response Time (ms) Location
OK c:\\users\\xxxx\\desktop\\misc\\criloc\\
||1:1:010> !mydt
Loading Dump File [C:\Users\xxxx\Desktop\srcfile\New folder\criloc.dmp]
gsfi returned 0
srcfilename is c:\\users\\xxxx\\desktop\\misc\\criloc\\criloc.cpp
||2:2:021>

Alignment of a simple class to allow array access without UB

Suppose I have the following simple class:
struct employee{
std::string name;
short salary;
std::size_t age;
employee(std::string name, short salary, std::size_t age) : name{name}, salary{salary}, age{age}{}
};
Since I want array-like access to the name member of employee in an array of employees, I need for example that the offsets are divisible:
static_assert( sizeof(employee) % sizeof(std::string) == 0, "!" );
In order to ensure that I am using the alignas directive:
struct alignas(sizeof(std::string)) employee{
std::string name;
short salary;
std::size_t age;
employee(std::string name, short salary, std::size_t age) : name{name}, salary{salary}, age{age}{}
};
Which seems to do the job (now the static_assert above passes).
However when I turned on the clang UB (undefined behavior sanitizer) and I try to construct an array of this aligned version of the class clang detects an error:
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/move.h:139:31 in
/usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/ext/new_allocator.h:153:10: runtime error: member call on misaligned address 0x0000022de1b0 for type 'employee', which requires 32 byte alignment
0x0000022de1b0: note: pointer points here
00 00 00 00 c0 e1 2d 02 00 00 00 00 05 00 00 00 00 00 00 00 44 61 76 69 64 00 00 00 00 00 00 00
What would be then the correct way to allow a compatible alignment of employee and the name members? (so member of arrays can be accessed by pointer std::string* arithmetic)
BONUS question: How can all the members be aligned to allow array access on all members of an array of employees.
For more details see here: Align/offset specific members of a struct
Basically I am noting that the solutions that worked are UB according to clang and I am looking for alternatives.
By array access of members I mean being able to this:
employee ARRAY[2];
std::string* p = &ARRAY[0].name;
std::string& p2 = *(p + 2); // can be +3 or any necessary integer
assert( &p2 == &ARRAY[1].name );
Note that I found this worked (in my system), does the job wrt to matching strides and clang doesn't say is UB:
struct employee{
std::string name;
short salary;
std::size_t age;
char dummy[9];
employee() = default;
}
This is the only option I found so far that doesn't produce UB.
I wonder if there is a better way still.
The most idiomatic path seems to use alignas but it also triggers UB according to clang.
struct employee{
std::string name alignas(32);
short salary;
std::size_t age;
employee(std::string name, short salary, std::size_t age) : name{name}, salary{salary}, age{age}{}
};

How to analyze windows 7 bsod error minidump?

I got blue screen of death (bsod) error on my laptop some time ago. I read online that analyzing minidump file in "c:\windows\minidump" will help understand cause behind bsod error. (and probably point to the culprit driver causing the error)
I used this online tool to analyze error http://www.osronline.com/page.cfm?name=analyze
It created a report but I do not understand it. If you can understand it, please let me know.
Link to online crash analysis report: https://pastebin.com/raw/3Hhq7arw
Dump file location: https://drive.google.com/file/d/0BzNdoGke8tyRZk5YcHBKQV8ycFE/view?usp=sharing
Laptop config: Windows 7, 32 bit
You get an WHEA_UNCORRECTABLE_ERROR (124) Bugcheck, which measn there is a fatal hardware error:
The WHEA_UNCORRECTABLE_ERROR bug check has a value of 0x00000124. This
bug check indicates that a fatal hardware error has occurred.
Using the !errrec command in Windbg and the value from parameter 2 I see you have an Internal timer issue with your Intel i3-3217U CPU:
===============================================================================
Common Platform Error Record # 8a0a401c
-------------------------------------------------------------------------------
Record Id : 01d1ff7437bf4c24
Severity : Fatal (1)
Length : 928
Creator : Microsoft
Notify Type : Machine Check Exception
Timestamp : 8/26/2016 8:32:29 (UTC)
Flags : 0x00000000
===============================================================================
Section 0 : Processor Generic
-------------------------------------------------------------------------------
Descriptor # 8a0a409c
Section # 8a0a4174
Offset : 344
Length : 192
Flags : 0x00000001 Primary
Severity : Fatal
Proc. Type : x86/x64
Instr. Set : x86
Error Type : Micro-Architectural Error
Flags : 0x00
CPU Version : 0x00000000000306a9
Processor ID : 0x0000000000000003
===============================================================================
Section 1 : x86/x64 Processor Specific
-------------------------------------------------------------------------------
Descriptor # 8a0a40e4
Section # 8a0a4234
Offset : 536
Length : 128
Flags : 0x00000000
Severity : Fatal
Local APIC Id : 0x0000000000000003
CPU Id : a9 06 03 00 00 08 10 03 - bf e3 ba 3d ff fb eb bf
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
Proc. Info 0 # 8a0a4234
===============================================================================
Section 2 : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor # 8a0a412c
Section # 8a0a42b4
Offset : 664
Length : 264
Flags : 0x00000000
Severity : Fatal
Error : Internal timer (Proc 3 Bank 3)
Status : 0xbe00000000800400
Address : 0x0000000085286f3c
Misc. : 0x0000000000000000
I see that you use the ASUS X550CA Laptop:
BiosVersion = X550CA.217
BiosReleaseDate = 01/23/2014
SystemManufacturer = ASUSTeK COMPUTER INC.
SystemProductName = X550CA
I see you se the older BIOS Version .217, so update the BIOS to .300, maybe it fixes the issue. If this doesn't fix the issue, do a stress test of the CPU with Prime95 and Intel CPU Diag tool.

How can I get correct function address on Aix?

see a simple code below:
int foo(int a)
{
return a;
}
int main() {
printf("%x\n", foo);
printf("%x\n", &foo);
printf("%x\n", *foo);
foo(1);
}
They all displayed the same value:
0x20453840
0x20453840
0x20453840
I used gdb to check foo() entry point is:
(gdb) p foo
$1 = {int (int)} 0x100003d8 <foo>
the value 0x20453840 is actually foo() pointer of pointer:
(gdb) p /x *0x20453850
$3 = 0x100003d8
(gdb) si
0x10000468 76 foo(1);
0x10000464 <main+76>: 38 60 00 01 li r3,1
=> 0x10000468 <main+80>: 4b ff ff 71 bl 0x100003d8 <foo>
(gdb)
foo (a=541407312) at insertcode.c:57
57 {
=> 0x100003d8 <foo+0>: 93 e1 ff fc stw r31,-4(r1)
0x100003dc <foo+4>: 94 21 ff e0 stwu r1,-32(r1)
0x100003e0 <foo+8>: 7c 3f 0b 78 mr r31,r1
0x100003e4 <foo+12>: 90 7f 00 38 stw r3,56(r31)
(gdb)
So I think 0x100003d8 is the entry point.
I used gcc 4.6.2 to compile.
I have tow questions:
why different function address definition on AIX? is it related to gcc?
I have to use gcc not xlC.
how to get real function address in C on AIX?
Thanks in advance!
why different function address definition on AIX?
nm -Pg ./f_addr | grep foo
Try this command, and you will see you have too symbols: foo and .foo One of them lives in the code segment (or text segment), the other, in the data segment.
The purpose is, indeed, creating an indirection in function calling; it is important when creating/using shared libraries.
is it related to gcc? I have to use gcc not xlC.
No.
How to get real function address in C on AIX?
Please clarify your question: what do you want to do with the 'real address'.

Resources