I'm using gcc to compile for mips32, and I declare a pointer to a struct called OSEvent within a global scope as follows:
OSEvent *__osMainEventQueue = NULL;
Additionally, code from within a certain function references this pointer during a call to a function:
__osEnqueueEvent(event, __osMainEventQueue);
That function is declared as follows:
extern void __osEnqueueEvent (OSEvent *event, OSEvent *queue);
However, when debugging this code, gcc seems to dereference the pointer to __osMainEventQueue despite me putting nothing there. You can see this in the disassembly as follows:
118: 3c020000 lui v0,0x0
118: R_MIPS_HI16 __osMainEventQueue
11c: 8c420000 lw v0,0(v0)
11c: R_MIPS_LO16 __osMainEventQueue
120: 00402825 move a1,v0
124: 8fc40018 lw a0,24(s8)
128: 0c000000 jal 0 <osScheduleEvent>
128: R_MIPS_26 __osEnqueueEvent
12c: 00000000 nop
Is there any reason gcc would dereference this pointer? Do I need to reference it with &? (This causes a type mismatch warning so I wouldn't consider this a satisfactory explanation / answer)
There's no pointer dereference. The code is simply loading the value of __osMainEventQueue into $a1 (i.e. the address it points to).
Consider the following scenario: the __osMainEventQueue is located at address 0x12345678 and contains the value 0xDEADBEEF. So what that lui and lw combo does is to first load $v0 with the value 0x12340000. Then it loads from 0x5678($v0), i.e. from (0x12345678), so you end up with 0xDEADBEEF in $v0. Never in this code is there an attempt to read from (0xDEADBEEF).
Related
This question already has answers here:
How do I call "cpuid" in Linux?
(2 answers)
What is the difference between 'asm', '__asm' and '__asm__'?
(4 answers)
Closed 4 years ago.
I'm working on Xeno Kovah's example in slide 18 of Intermediate Assembly. He's using Visual Studios with Intel Assembly, inline. I've tried adapting that to GCC as follows. I'm compiling with -masm=intel -fPIC
#include <stdio.h>
int main(){
unsigned int maxBasicCPUID;
char vendorString[13];
char * vendorStringPtr = (char *)vendorString; //Move the address into its own register
//because it makes the asm syntax easier
//First we will check whether we can even use CPUID
//Such a check is actually more complicated than it seems (OMITED FROM SLIDES)
__asm (
"mov edi, vendorStringPtr;" //Get the base address of the char[] into a register
"mov eax, 0;" //We're going to do CPUID with input of 0
"cpuid;" //As stated, the instruction doesn't have any operands
//Get back the results which are now stored in eax, ebx, ecx, edx
//and will have values as specified by the manual
"mov maxBasicCPUID, eax;"
"mov [edi], ebx;" //We order which register we put into which address
"mov [edi+4], edx;" //so that they all end up forming a human readable string
"mov [edi+8], ecx;"
);
vendorString[12] = 0;
printf("maxBasicCPUID = %#x, vendorString = %s\n", maxBasicCPUID, vendorString);
return 0xb45eba11;
}
I'm not sure what I'm doing wrong, but I'm getting the following error
/usr/bin/ld: /tmp/ccSapgOG.o: relocation R_X86_64_32S against undefined symbol `vendorStringPtr' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
In gcc, you can't reference local variables directly by name within the assembly code.
Also, you need to tell the compiler about all the registers you use (clobber).
But, on the plus side, you can get the compiler to do a lot more of the work for you, as you can see in the following rewrite of your code:
uint32_t *str = (uint32_t *)vendorString;
__asm("cpuid"
: "=a"(maxBasicCPUID), "=b"(str[0]), "=d"(str[1]), "=c"(str[2])
: "a"(0));
The first line of parameters tells the compiler where to store the results, and the second line tells the compiler what values to load before executing the inline assembly.
For all the details, see https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html. (Thanks to #MichaelPetch for the link.)
I am doing an operating system implementation work.
Here's the code first :
//generate software interrupt
void generate_interrupt(int n) {
asm("mov al, byte ptr [n]");
asm("mov byte ptr [genint+1], al");
asm("jmp genint");
asm("genint:");
asm("int 0");
}
I am compiling above code with -masm=intel option in gcc. Also,
this is not complete code to generate software interrupt.
My problem is I am getting error as n undefined, how do I resolve it, please help?
Also it promts error at link time not at compile time, below is an image
When you are using GCC, you must use GCC-style extended asm to access variables declared in C, even if you are using Intel assembly syntax. The ability to write C variable names directly into an assembly insert is a feature of MSVC, which GCC does not copy.
For constructs like this, it is also important to use a single assembly insert, not several in a row; GCC can and will rearrange assembly inserts relative to the surrounding code, including relative to other assembly inserts, unless you take specific steps to prevent it.
This particular construct should be written
void generate_interrupt(unsigned char n)
{
asm ("mov byte ptr [1f+1], %0\n\t"
"jmp 1f\n"
"1:\n\t"
"int 0"
: /* no outputs */ : "r" (n));
}
Note that I have removed the initial mov and any insistence on involving the A register, instead telling GCC to load n into any convenient register for me with the "r" input constraint. It is best to do as little as possible in an assembly insert, and to leave the choice of registers to the compiler as much as possible.
I have also changed the type of n to unsigned char to match the actual requirements of the INT instruction, and I am using the 1f local label syntax so that this works correctly if generate_interrupt is made an inline function.
Having said all that, I implore you to find an implementation strategy for your operating system that does not involve self-modifying code. Well, unless you plan to get a whole lot more use out of the self-modifications, anyway.
This isn't an answer to your specific question about passing parameters into inline assembly (see #zwol's answer). This addresses using self modifying code unnecessarily for this particular task.
Macro Method if Interrupt Numbers are Known at Compile-time
An alternative to using self modifying code is to create a C macro that generates the specific interrupt you want. One trick is you need to a macro that converts a number to a string. Stringize macros are quite common and documented in the GCC documentation.
You could create a macro GENERATE_INTERRUPT that looks like this:
#define STRINGIZE_INTERNAL(s) #s
#define STRINGIZE(s) STRINGIZE_INTERNAL(s)
#define GENERATE_INTERRUPT(n) asm ("int " STRINGIZE(n));
STRINGIZE will take a numeric value and convert it into a string. GENERATE_INTERRUPT simply takes the number, converts it to a string and appends it to the end of the of the INT instruction.
You use it like this:
GENERATE_INTERRUPT(0);
GENERATE_INTERRUPT(3);
GENERATE_INTERRUPT(255);
The generated instructions should look like:
int 0x0
int3
int 0xff
Jump Table Method if Interrupt Numbers are Known Only at Run-time
If you need to call interrupts only known at run-time then one can create a table of interrupt calls (using int instruction) followed by a ret. generate_interrupt would then simply retrieve the interrupt number off the stack, compute the position in the table where the specific int can be found and jmp to it.
In the following code I get GNU assembler to generate the table of 256 interrupt call each followed by a ret using the .rept directive. Each code fragment fits in 4 bytes. The result code generation and the generate_interrupt function could look like:
/* We use GNU assembly to create a table of interrupt calls followed by a ret
* using the .rept directive. 256 entries (0 to 255) are generated.
* generate_interrupt is a simple function that takes the interrupt number
* as a parameter, computes the offset in the interrupt table and jumps to it.
* The specific interrupted needed will be called followed by a RET to return
* back from the function */
extern void generate_interrupt(unsigned char int_no);
asm (".pushsection .text\n\t"
/* Generate the table of interrupt calls */
".align 4\n"
"int_jmp_table:\n\t"
"intno=0\n\t"
".rept 256\n\t"
"\tint intno\n\t"
"\tret\n\t"
"\t.align 4\n\t"
"\tintno=intno+1\n\t"
".endr\n\t"
/* generate_interrupt function */
".global generate_interrupt\n" /* Give this function global visibility */
"generate_interrupt:\n\t"
#ifdef __x86_64__
"movzx edi, dil\n\t" /* Zero extend int_no (in DIL) across RDI */
"lea rax, int_jmp_table[rip]\n\t" /* Get base of interrupt jmp table */
"lea rax, [rax+rdi*4]\n\t" /* Add table base to offset = jmp address */
"jmp rax\n\t" /* Do sepcified interrupt */
#else
"movzx eax, byte ptr 4[esp]\n\t" /* Get Zero extend int_no (arg1 on stack) */
"lea eax, int_jmp_table[eax*4]\n\t" /* Compute jump address */
"jmp eax\n\t" /* Do specified interrupt */
#endif
".popsection");
int main()
{
generate_interrupt (0);
generate_interrupt (3);
generate_interrupt (255);
}
If you were to look at the generated code in the object file you'd find the interrupt call table (int_jmp_table) looks similar to this:
00000000 <int_jmp_table>:
0: cd 00 int 0x0
2: c3 ret
3: 90 nop
4: cd 01 int 0x1
6: c3 ret
7: 90 nop
8: cd 02 int 0x2
a: c3 ret
b: 90 nop
c: cc int3
d: c3 ret
e: 66 90 xchg ax,ax
10: cd 04 int 0x4
12: c3 ret
13: 90 nop
...
[snip]
Because I used .align 4 each entry is padded out to 4 bytes. This makes the address calculation for the jmp easier.
I'm trying to output the same string twice in extended inline ASM in GCC, on 64-bit Linux.
int main()
{
const char* test = "test\n";
asm(
"movq %[test], %%rdi\n" // Debugger shows rdi = *address of string*
"movq $0, %%rax\n"
"push %%rbp\n"
"push %%rbx\n"
"call printf\n"
"pop %%rbx\n"
"pop %%rbp\n"
"movq %[test], %%rdi\n" // Debugger shows rdi = 0
"movq $0, %%rax\n"
"push %%rbp\n"
"push %%rbx\n"
"call printf\n"
"pop %%rbx\n"
"pop %%rbp\n"
:
: [test] "g" (test)
: "rax", "rbx","rcx", "rdx", "rdi", "rsi", "rsp"
);
return 0;
}
Now, the string is outputted only once. I have tried many things, but I guess I am missing some caveats about the calling convention. I'm not even sure if the clobber list is correct or if I need to save and restore RBP and RBX at all.
Why is the string not outputted twice?
Looking with a debugger shows me that somehow when the string is loaded into rdi for the second time it has the value 0 instead of the actual address of the string.
I cannot explain why, it seems like after the first call the stack is corrupted? Do I have to restore it in some way?
Specific problem to your code: RDI is not maintained across a function call (see below). It is correct before the first call to printf but is clobbered by printf. You'll need to temporarily store it elsewhere first. A register that isn't clobbered will be convenient. You can then save a copy before printf, and copy it back to RDI after.
I do not recommend doing what you are suggesting (making function calls in inline assembler). It will be very difficult for the compiler to optimize things. It is very easy to get things wrong. David Wohlferd wrote a very good article on reasons not to use inline assembly unless absolutely necessary.
Among other things the 64-bit System V ABI mandates a 128-byte red zone. That means you can't push anything onto the stack without potential corruption. Remember: doing a CALL pushes a return address on the stack. Quick and dirty way to resolve this problem is to subtract 128 from RSP when your inline assembler starts and then add 128 back when finished.
The 128-byte area beyond the location pointed to by %rsp is considered to
be reserved and shall not be modified by signal or interrupt handlers.8 Therefore,
functions may use this area for temporary data that is not needed across function
calls. In particular, leaf functions may use this area for their entire stack frame,
rather than adjusting the stack pointer in the prologue and epilogue. This area is
known as the red zone.
Another issue to be concerned about is the requirement for the stack to be 16-byte aligned (or possibly 32-byte aligned depending on the parameters) prior to any function call. This is required by the 64-bit ABI as well:
The end of the input argument area shall be aligned on a 16 (32, if __m256 is
passed on stack) byte boundary. In other words, the value (%rsp + 8) is always
a multiple of 16 (32) when control is transferred to the function entry point.
Note: This requirement for 16-byte alignment upon a CALL to a function is also required on 32-bit Linux for GCC >= 4.5:
In context of the C programming language, function arguments are pushed on the stack in the reverse order. In Linux, GCC sets the de facto standard for calling conventions. Since GCC version 4.5, the stack must be aligned to a 16-byte boundary when calling a function (previous versions only required a 4-byte alignment.)
Since we call printf in inline assembler we should ensure that we align the stack to a 16-byte boundary before making the call.
You also have to be aware that when calling a function some registers are preserved across a function call and some are not. Specifically those that may be clobbered by a function call are listed in Figure 3.4 of the 64-bit ABI (see previous link). Those registers are RAX, RCX, RDX, RD8-RD11, XMM0-XMM15, MMX0-MMX7, ST0-ST7 . These are all potentially destroyed so should be put in the clobber list if they don't appear in the input and output constraints.
The following code should satisfy most of the conditions to ensure that inline assembler that calls another function will not inadvertently clobber registers, preserves the redzone, and maintains 16-byte alignment before a call:
int main()
{
const char* test = "test\n";
long dummyreg; /* dummyreg used to allow GCC to pick available register */
__asm__ __volatile__ (
"add $-128, %%rsp\n\t" /* Skip the current redzone */
"mov %%rsp, %[temp]\n\t" /* Copy RSP to available register */
"and $-16, %%rsp\n\t" /* Align stack to 16-byte boundary */
"mov %[test], %%rdi\n\t" /* RDI is address of string */
"xor %%eax, %%eax\n\t" /* Variadic function set AL. This case 0 */
"call printf\n\t"
"mov %[test], %%rdi\n\t" /* RDI is address of string again */
"xor %%eax, %%eax\n\t" /* Variadic function set AL. This case 0 */
"call printf\n\t"
"mov %[temp], %%rsp\n\t" /* Restore RSP */
"sub $-128, %%rsp\n\t" /* Add 128 to RSP to restore to orig */
: [temp]"=&r"(dummyreg) /* Allow GCC to pick available output register. Modified
before all inputs consumed so use & for early clobber*/
: [test]"r"(test), /* Choose available register as input operand */
"m"(test) /* Dummy constraint to make sure test array
is fully realized in memory before inline
assembly is executed */
: "rax", "rcx", "rdx", "rsi", "rdi", "r8", "r9", "r10", "r11",
"xmm0","xmm1", "xmm2", "xmm3", "xmm4", "xmm5", "xmm6", "xmm7",
"xmm8","xmm9", "xmm10", "xmm11", "xmm12", "xmm13", "xmm14", "xmm15",
"mm0","mm1", "mm2", "mm3", "mm4", "mm5", "mm6", "mm6",
"st", "st(1)", "st(2)", "st(3)", "st(4)", "st(5)", "st(6)", "st(7)"
);
return 0;
}
I used an input constraint to allow the template to choose an available register to be used to pass the str address through. This ensures that we have a register to store the str address between the calls to printf. I also get the assembler template to choose an available location for storing RSP temporarily by using a dummy register. The registers chosen will not include any one already chosen/listed as an input/output/clobber operand.
This looks very messy, but failure to do it correctly could lead to problems later as you program becomes more complex. This is why calling functions that conform to the System V 64-bit ABI within inline assembler is generally not the best way to do things.
I am writing a bit of 16-bit (pun intended) code in C++, compiling it with G++. More on the context I'm compiling in here: Force GCC to push arguments on the stack before calling function (using PUSH instruction)
The problem I am facing now is regarding an error LD throws when trying to link my object files. Specifically, here's a code situation:
asm(".code16gcc\n");
void f(const char*);
int main(){
f("A constant string put in section .rodata at link-time");
}
void f(const char* s){ }
In assembly code, with -S and -mno-accumulate-outgoing-args options G++ would translate this to (only relevant parts of the assembly written):
/APP
.code16gcc
.section .rodata
.LC0:
.string "A constant string put in section .rodata at link-time"
main:
.LFB0:
/* here would be main's prologue, not put because it ain't relevant */
// THIS IS THE CALL f("A constant string put in section .rodata at link-time");
push OFFSET FLAT:.LC0
call _Z1fPKc
This application is part of an OS I'm developing. Specifically, the bootloader loads this code at address 0x70D00 in BIOS memory. That makes .rodata's address be bigger than 0x70D00. Since GCC does not have built-in support for pure 16-bit code, it doesn't know that executing the 'push OFFSET FLAT:.LC0' would mean pushing a WORD UNDER PURE 16-BIT circumstances. Which means that, if the address of .rodata is - say - 0x70DAA, the instruction would be 'push 0x70DAA'. That's why the linker throws the error:
In function main': relocation truncated to fit: R_386_16 against.rodata'
-- because the linker knows that 0x70DAA DOES NOT FIT IN A WORD. What would solve the problem is asking GCC to MOV the arguments IN A REGISTER BEFORE PUSHING THEM. Something like:
/APP
.code16gcc
.section .rodata
.LC0:
.string "A constant string put in section .rodata at link-time"
main:
.LFB0:
/* here would be main's prologue, not put because it ain't relevant */
// THIS IS THE CALL f("A constant string put in section .rodata at link-time"); , now using EAX before pushing the string literal's offset in .rodata
mov eax, OFFSET FLAT:.LC0 // move in eax instead
push eax // and push eax!
call _Z1fPKc
This is what MSVC does to optimize in some situations. I was wondering if there's a way to force GCC to do the same thing...one alternative that apparently would work is associating the attribute((regparm(N))) to function f. But this is not really a good alternative, since it DOESN'T REALLY PUSH the registers on the stack, rather than using them directly in f - and can't do this for any function. You can find out more on this by doing a short google search and if needed I'll post exactly what this option does here and why it would't really work, but this question-post starts to get too long.
In short, my question is:
Can I ask GCC to MOV the arguments passed to functions IN A REGISTER BEFORE PUSHING THEM?
Thanks in advance!
I have thought of a work-around for this problem, although I would have prefered a MOV-to-REG-and-PUSH sort-of method. What I've thought of is that this only happens for addresses that the compiler can calculate at compile time, like the address of the string which was put in .rodata.
Knowing that, I have created a local variable in main and used that as the passed argument instead, like this:
asm(".code16gcc\n");
void f(const char*);
int main(){
const char* s = "A constant string put in section .rodata at link-time";
// Now use 's' as the argument instead of the string literal
f(s);
}
void f(const char* s){ }
This effectively changes the generated assembly code to:
/APP
.code16gcc
.section .rodata
.LC0:
.string "A constant string put in section .rodata at link-time"
main:
.LFB0:
/* here would be main's prologue, not put because it ain't relevant */
// THIS IS THE CALL f(s);
mov DWORD PTR [ebp-12], OFFSET FLAT:.LC0 // now specifically loaded in the DWORD 's'
sub esp, 12
push DWORD PTR [ebp-12]
call _Z1fPKc
As it can be seen, the local variable is used now instead, the address to the string literal (in .rodata) being transferred specifically in a DWORD. This effectively avoids the linker error, although it uses some neglijable extra stack space.
#include <stdio.h>
int main(void){
int sum = 0;
sum += 0xabcd;
printf(“%x”, sum);
return 0;
}
This is my code and when I use gdb I can find different address when break main / break *main.
When I just type disassemble main it shows like this:
Dump of assembler code for function main:
0x080483c4 <+0>: push %ebp
0x080483c5 <+1>: mov %esp,%ebp
0x080483c7 <+3>: and $0xfffffff0,%esp
0x080483ca <+6>: sub $0x20,%esp
0x080483cd <+9>: movl $0x0,0x1c(%esp)
0x080483d5 <+17>:addl $0xabcd,0x1c(%esp)
0x080483dd <+25>:mov $0x80484c0,%eax
0x080483e2 <+30>:mov 0x1c(%esp),%edx
0x080483e6 <+34>:mov %edx,0x4(%esp)
0x080483ea <+38>:mov %eax,(%esp)
0x080483ed <+41>:call 0x80482f4 <printf#plt>
0x080483f2 <+46>:mov $0x0,%eax
0x080483f7 <+51>:leave
0x080483f8 <+52>:ret
End of assembler dump.
So when I type [break *main] it starts 0x080483c4 but type [break main] it start 0x080483cd
Why is start address is different?
Why is the address different.
Because break function and break *address are not the same thing(*address specifies the address of the function's first instruction, before the stack frame and arguments have been set up).
In the first case, GDB skips function prolog (setting up the current frame).
Total guess - and prepared to be totally wrong.
*main if address of the function
Breaking inside main is the first available address to stop inside the function when it is being executed.
Note that 0x080483cd is the first place a debugger can stop as it is modifying a variable (ie assigning zero to sum)
When you are breaking at 0x080483c4 this is before the setup assembler that C knows nothing about