Here is my full source code for a Win32 C++ program fully writen in NASM:
http://devel.archefire.org/tmp/01_00.cpp.zip
I want to interface with the C++ functions like the ones from Windows (MSVCIRT.DLL).
I have tried to run a program like this to print a string:
#include <iostream.h>
void main()
{
cout <<"Welcome to Programming in C++";
}
When I translate it to NASM, cout doesn't print anything:
push wideword main_printf_str_1
mov widecx,?cout##3Vostream_withassign##A#MSVCIRT.DLL
call wideword[??6ostream##QAEAAV0#PBD#Z#MSVCIRT.DLL]
So I guess that I need to do initializations for input/output streams and maybe standard "base" classes similar to what is done when initializing stdin,stdout,stderr with __p_iob from MSVCRT.DLL.
What C++ functions do I need to call to get an initialized cout that would print when calling ostream in assembly, or why doesn't the assembly above print anything, as if cout was invalid?
http://devel.archefire.org/tmp/01_00.cpp.zip
I have finally fixed the problem.
For being able to output with cout << "";, I found that The following 2 MSVCIRT.DLL references need to be called:
push wideword main_printf_str_1
mov widecx,[?cout##3Vostream_withassign##A#MSVCIRT.DLL]
call wideword[??6ostream##QAEAAV0#PBD#Z#MSVCIRT.DLL]
Then, before ending the program we need to call exit(int ); from MSVCRT.DLL. That will flush the output for cout.
Probably formal flushing could be used, but Visual C++ 6.0 produces code that ends with a call to exit(int ) after returning from main() to force things like this final flush, and doesn't explicitly flush anything after the cout << "";.
Related
I'm working on Rust and using a shared library written in C++. The problem that the C++ library spawns a few threads that constantly print to stdout (1) and that interferes with my own logging.
I was able to duplicate stdout using dup to fd = 3. Then I open up a pipe (4, 5), and use dup2 to
move old stdout to one end of the pipe.
As a result:
C++ library writes to fd = 1 (old stdout), but that goes to another pipe where I can capture the data in another thread (say I read from fd = 5). Then I can parse those logs and print them to the console.
In Rust code I can use libc::write to fd = 3 and that will go directly to the console.
The problem now is that standard Rust function such as println! will still try to write to fd = 1, but I'd like to be able to change the default behavior so Rust code will write to fd = 3 instead of 1, that way, any Rust print related function will print to the console, and everything from the shared library will be parsed on a separate thread.
Is that possible to do in stable Rust? Closest thing I found is set_print function which looks like it's unstable and I couldn't even use it using +nightly build.
If it's acceptable to use writeln! instead of println!, you can call from_raw_fd to open a proper File:
use std::fs::File;
use std::io::{BufWriter, Write};
use std::os::unix::io::FromRawFd;
let mut out = BufWriter::new(unsafe { File::from_raw_fd(3) });
writeln!(out, "hello world!")?;
// ...
Note: from_raw_fd is unsafe because you must ensure that the File assumes sole ownership of the file descriptor, in this case that no one else closes or interacts with file descriptor 3. (But you can use into_raw_fd to re-assert ownership of the fd it while consuming the File.)
In NSIS, I was going through some API which calls some functions of Windows.
For example:
Kernel32::SetEnvironmentVariable(t, t)i ("VAR1", "$R0").r0
Kernel32::GetLocaleInfo(i,i,t,i)i(2048,0x2,.r0,${NSIS_MAX_STRLEN})i
As I am a newbie, can anyone please explain what is happening here ? What is t , i , .ro etc. ?
I know that kernel32 is a DLL and SetEnvironmentVariable & GetLocaleInfo are the functions defined in this DLL.
The documentation will tell you what t and i are.
The basic syntax for System::Call is module::function(parameters)return. Parameters and return are optional and they both follow the same basic format: type input output. Type is not optional if you need input and/or output.
Parameters and return can be repeated multiple times, this is only useful when the function prototype exists as a define but you sometimes see this syntax on the NSIS Wiki as well. Kernel32::SetEnvironmentVariable(t, t)i ("VAR1", "$R0").r0 is exactly the same as Kernel32::SetEnvironmentVariable(t "VAR1", t "$R0")i.r0. When using a define it would look like this:
!define SetEnvironmentVariable "Kernel32::SetEnvironmentVariable(t, t)i"
System::Call '${SetEnvironmentVariable}("VAR1", "$R0").r0'
It is helpful if you know a language like C/C++ or Delphi when using the System plug-in because you need to understand the basic Windows types and how functions are typically used.
If for example you wanted to call the GetWindowsDirectory function you would first look at the function on MSDN:
UINT WINAPI GetWindowsDirectory(_Out_ LPTSTR lpBuffer, _In_ UINT uSize);
Translating this to NSIS gives you a initial skeleton of Kernel32::GetWindowsDirectory(t, i)i (WINAPI is the default calling convention). t maps to the Windows TCHAR* type and i is a 32-bit integer, the same as ULONG, LONG, DWORD, INT, UINT, INT32 and UINT32 in the Windows SDK.
The only missing piece is the input and output. The MSDN declaration is decorated with SAL annotations so it is easy to see which parameters are input and which are output.
A working example might look something like this:
System::Call 'Kernel32::GetWindowsDirectory(t .r1, i ${NSIS_MAX_STRLEN})i .r0'
DetailPrint "Return=$0 Output1=$1"
. can be used as a "nothing" placeholder when there is no input. In this case we use it twice. The return value never has input when using System::Call and we also have one output-only parameter.
r1 and r0 are aliases for the $1 and $0 NSIS registers and these aliases must be used when you need the output of something. The plain NSIS register can be used as input but then the variable expansion happens inside NSIS and not in the plug-in and this can cause issues with quotes in strings and is not really recommended if the string might contain quotes or legal System plug-in syntax. I would therefore recommend that your first example is rewritten as Kernel32::SetEnvironmentVariable(t "VAR1", t R0)i.r0.
In C your second example would look something like
char mybuf[1024];
GetLocaleInfo(MAKELCID(LANG_NEUTRAL,SUBLANG_SYS_DEFAULT), LOCALE_SLANGUAGE, mybuf, sizeof(mybuf));
I am developing an application in C / Objective-C (No C++ please, I already have a solution there), and I came across an interesting use case.
Because clang does not support nested functions, my original approach will not work:
#define CREATE_STATIC_VAR(Type, Name, Dflt) static Type Name; __attribute__((constructor)) void static_ ## Type ## _ ## Name ## _init_var(void) { /* loading code here */ }
This code would compile fine with GCC, but because clang doesn't support nested functions, I get a compile error:
Expected ';' at end of declaration.
So, I found a solution that works for Clang on variables inside a function:
#define CREATE_STATIC_VAR_LOCAL(Type, Name, Dflt) static Type Name; ^{ /* loading code here */ }(); // anonymous block usage
However, I was wondering if there was a way to leverage macro concatenation to choose the appropriate one for the situation, something like:
#define CREATE_STATIC_VAR_GLOBAL(Type, Name, Dflt) static Type Name; __attribute__((constructor)) void static_ ## Type ## _ ## Name ## _init_var(void) { /* loading code here */ }
#define CREATE_STATIC_VAR_LOCAL(Type, Name, Dflt) static Type Name; ^{ /* loading code here */ }(); // anonymous block usage
#define SCOPE_CHOOSER LOCAL || GLOBAL
#define CREATE_STATIC_VAR(Type, Name, DFLT) CREATE_STATIC_VAR_ ## SCOPE_CHOOSER(Type, Name, Dflt)
Obviously, the ending implementation doesn't have to be exactly that, but something similar will suffice.
I have attempted to use __builtin_constant_p with __func__, but because __func__ is not a compile-time constant, that wasn't working.
I have also tried to use __builtin_choose_expr, but that doesn't appear to work at the global scope.
Is there something else I am missing in the docs? Seems like this should be something fairly easy to do, and yet, I cannot seem to figure it out.
Note: I am aware that I could simply type CREATE_STATIC_VAR_GLOBAL or CREATE_STATIC_VAR_LOCAL instead of messing with macro concatenation, but this is me attempting to push the limits of the compiler. I am also aware that I could use C++ and get this over with right away, but that's not my goal here.
#define SCOPE_CHOOSER LOCAL || GLOBAL
#define CREATE_STATIC_VAR(Type, Name, DFLT) CREATE_STATIC_VAR_ ## SCOPE_CHOOSER(Type, Name, Dflt)
The biggest difficulty here is that the C preprocessor works by textual substitution, so even if you figured out how to get SCOPE_CHOOSER to do what you want, you'd end up with a macro expansion that looked something like
CREATE_STATIC_VAR_LOCAL || GLOBAL(Type, Name, Dflt);
There's no way to get the preprocessor to "constant-fold" macro expansions during substitution; the only time things are "folded" is when they appear in #if expressions. So your only hope (modulo slight handwaving) is to find a single construction that will work both inside and outside of a function.
Can you explain more about the ultimate goal here? I don't think you can load the variable's initial value with __attribute__((constructor)), but maybe there's a way to load the initial value the first time the function body is entered... or register all the addresses of these variables into a global list at compile-time and have a single __attribute__((constructor)) function that traverses that list... or some mishmash of those approaches. I don't have any specific ideas in mind, but maybe if you give more information something will emerge.
EDIT: I don't think this helps you either, since it's not a preprocessor trick, but here is a constant-expression that will evaluate to 0 at function scope and 1 at global scope.
#define AT_GLOBAL_SCOPE __builtin_types_compatible_p(const char (*)[1], __typeof__(&__func__))
However, notice that I said "evaluate" and not "expand". These constructs are compile-time, not preprocessing-time.
Inspired by the #Qxuuplusone answer.
The suggested macro for AT_GLOBAL_SCOPE does indeed work (in GCC), but causes a compiler warning (and I am pretty sure it cannot be silenced by Diagnostic Pragma because it's created by pedwarn with a test here).
Unless you turn on -w you will always see these warnings and have, in the back of your mind, a horrible feeling that you probably shouldn't be doing whatever it is that you are doing.
Fortunately, there is a solution that can silence these lingering doubts.
In the Other Builtins section, there is __builtin_FUNCTION with this very interesting description (emphasis mine):
This function is the equivalent of the __FUNCTION__ symbol and returns an address constant pointing to the name of the function from which the built-in was invoked, or the empty string if the invocation is not at function scope.
It turns out, at least in version 8.3 of GCC, you can do this:
#define AT_GLOBAL_SCOPE (__builtin_FUNCTION()[0] == '\0')
This still probably won't answer the original question, but until GCC decides this too will cause a warning (it kind of seems like it's intentionally designed not to though), it lets me continue doing questionable things using macros without anything to warn me that it's a bad idea.
I have a structure like this :
struct A
{
int a;
char b;
};
this structure is referenced at various places in a large code. The pointer to this struct is passed on to different functions and accordingly the variables in this structure are updated. i want to set a watchpoint on variable a in this struct as it travels across many functions. to see how a changes. How do I set this watch point ?
First set a breakpoint where you create an instance of your struct using break, like
break myfile.c:9
Then just use watch to set a watchpoint, like
watch myStructInstance.a
for variable a or
watch *0x7ffff75177f0
for a memory address. The memory address can be obtained easily by using print, like
print &myStructInstance.a
Now every time variable a or the given memory address gets modified gdb will break.
I come with the same problem when debugging my virtual memory simulator. The problem is how to keep a close look at the data inside structs.
I tried using print to check, but that's too noisy. Because I have to print out more than 15 variables.
I also tried using watchpoint, but on my machine, I can only set no more than 4 hardware watchpoints. That's not even close to my goal.
Finally, I find my solution by using user-defined function in .gdbinit file. e.g. if I want to watch array of my structure, using
define lookintoStructs
if mystruct != 0x0
print mystruct[0]
print mystruct[1]
print mystruct[2]
print mystruct[3]
print mystruct[4]
print mystruct[5]
end
end
to make it more convenient to use, I'd like to make it hook to my next instruction in gdb.
define hook-next
lookintoStructs
end
so when I call next or n in gdb, lookintoStructs could be called automatically. works fine for me.
Both move vA, vB and move-wide vA, vB involve the same operations and same operands. Except opcodes everything is the same. I am in a situation where I need to print the operands used by instructions in an application.
So when I see the instruction move vA, vB I should print move va(*contents of va*), vb(*contents of vb*).
This works fine in the case of 4-byte registers. But when I encounter move-wide instructions, I should print the contents of vA and the contents of the next virtual register., contents of vB and the contents of the next virtual register. What is the standard way of parsing these?
Since both Dalvik and dx are open source, the best way to answer questions involving dex files is to inspect their source. Dx parses instructions in DecodedInstruction.java. It decodes the opcode first, and then uses the opcode to inform decoding the rest of the instruction.
public static DecodedInstruction decode(CodeInput in) throws EOFException {
int opcodeUnit = in.read();
int opcode = Opcodes.extractOpcodeFromUnit(opcodeUnit);
InstructionCodec format = OpcodeInfo.getFormat(opcode);
return format.decode(opcodeUnit, in);
}