I'm currently trying to write to a file so far I have the following code to append to the file. Does anybody know why this isn't working? It runs fine but by the end nothing has changed.
filewritemode: .asciz "a"
filelocation: .asciz "/h/test.txt"
_main:
push $filelocation
push $filewritemode
call _fopen
push $blabla
push %eax
call _fprintf
push $result
call _printf
push $0
call _exit # exit the program
gcc is used in order to turn the source file into an .exe
$blabla is currently the string with some random chars that are ment for testing
It doesn't work because you have pushed the parameters of fopen in the wrong order. Parameters must be pushed from last to first. Aside from that you are repeatedly pushing parameters, but you don't remove them again. In this case that works because you take a dive to exit, but if instead you would have returned with the ret instruction, you would have found that this would result in a crash as you would be jumping to one of the pushed parameters.
You are passing the arguments to fopen reversed and you are not checking for errors. In situations like this, ltrace may be your friend.
Related
I have an assignment that has me design my own system call. To do this, I would like to view the definition of the open system call. By this, I mean I would like to see how the actual open(const char*, const int) is defined, not sys_open (Since I know where the source code is and can read it).
In both xv6's documentation and files in xv6-public, I am unable to find any reference of the prototype of definition.
The theory of my friend and I is that it's defined in some asm file, or some .o file.
Would anyone happen to know where the actual source code is? I'd appreciate this greatly.
Tried a ctrl-f for open in the source documentation, and tried a grep over all files in xv6-public. Found nothing.
Well,
open is declared in user.h.
open is defined in usys.S:
Lets see:
SYSCALL(open)
Will be transformed in
.globl open;
open:
movl $SYS_ ## open, %eax;
int $T_SYSCALL;
ret
What happened?
When function open is called
register %eax is set to SYS_open (which value is 15 (see syscall.h) and SYS_open is defined in sysfile.c
interuption T_SYSCALL (64 see traps.h) is raised.
after the system call returned, open returns too.
I am working on a small IDAPython script.
The script itself works 100% of the time on lines like this:
qword_FFFFFFF006F1E6C0 DCQ 0xFFFFFFF007758C18
As it looks into address 0xFFFF.. sees if there's a function there, and if there is, renames the qword with the function name + segment info.
Now, sometimes, the disassembly looks like this:
off_FFFFFFF006F1E690 DCQ OSDictionary::withCapacity(uint) , and of course, the script breaks down here (expects an address, is given a name..).
What I'd like to do is to get the address of the second operand (OSDictionary::with...), and execute the script as normal.
Unfortunately, I have no idea how to do that, as to get the address I use this:
disas = GetDisasm(addr).split(" ")
fun_addr = disas[1]
....
If you always want the address of the destination, you could use get_qword function
https://www.hex-rays.com/products/ida/support/idadoc/1321.shtml
Which is the Qword function in IDAPython.
Simply do Qword(addr), this will give you the address as a number.
You might need to compensate for endianity (use struct).
So I'm new to Linux and just got Ubuntu 16.04.2 running on a VM. I've installed gcc/g++ on here in the terminal, but when I run my program in GDB, as soon as I get to a strcmp function, this pops up for many lines.
strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:24
24 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory.
And when I go further down:
strlen () at ../sysdeps/x86_64/strlen.S:66
66 ../sysdeps/x86_64/strlen.S: No such file or directory.
So I'm guessing it just doesn't recognize my C library..
I realize I can step through this after a couple of tries, but this comes up for all my c functions and when I use GDB on my school server, I don't run into this issue. Any help would be appreciated.
I get to a strcmp function, this pops up for many lines.
When you does s (single step) or si (Step single instruction), what you see for string and memory functions like strcmp, memcpy, memcmp, strlen etc is correct, and GDB does recognize your C library (Ubuntu 16.04.2 amd64 started from iso in VM already has libc6-dbg debugging package preinstalled for your libc - C library).
strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:24
24 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory.
strlen () at ../sysdeps/x86_64/strlen.S:66
66 ../sysdeps/x86_64/strlen.S: No such file or directory.
What we see here is that GDB was able to find debugging information for both functions strcmp and strlen to get line numbers, but these functions of standard C library are not C functions! They are assembler functions (one is optimiezed with SSE2), we can see this from .S suffix of their source reference. You can try to do several s or si after entering to them to see incrementing source file lines.
it just doesn't recognize
GDB did all what it can do: it finds debugging info for your system C library (it is not easiest as debug info is separated to other file somewhere in /usr/lib/debug/lib/x86_64-linux-gnu/ with other name), and finds which instruction comes from which line of source. What it can't do is to open source file, as it is not part of preinstalled ubuntu image not part of any ubuntu (debian) binary package.
What can you do if you want to look inside this system library function:
1) Check disassembly of the function with GDB command disassemble (by default it will print current function). It will be very close to the source of this function implementation as it was originally written in assembler and what you lose are comments and structure of macro:
Dump of assembler code for function strlen:
0x000address70 <+0>: pxor %xmm0, %xmm0
=> 0x000address74 <+0>: pxor %xmm1, %xmm1
0x000address78 <+0>: pxor %xmm2, %xmm2
0x000address7c <+0>: pxor %xmm3, %xmm3
...
2) Or you can see instructions as they are executed with "display" command like display/i $pc or disp/2i $pc (print one instruction at current PC which is universal just name of EIP or RIP; or print two instructions: current and next)
3) Or you can create the path required by gdb and copy original source to it: mkdir -p ../sysdeps/x86_64/ and save to this directory assembler source for your version of library. There is glibc-2.23 version for strlen.S (github mirror of authors GIT): https://github.com/bminor/glibc/blob/glibc-2.23/sysdeps/x86_64/strlen.S#L66
4) Or you can download ubuntu source for libc with apt source libc (in some stable path like ~/src after mkdir ~/src) and point gdb to this directory (adding some real subdirectory accounting to ../ relative part of libc build in ubuntu) with directory ~/src/glibc-2.23/sysdeps)
this comes up for all my c functions
No, for your c functions you have other kind of output (not ... something.S: No such file or directory). And you should enable debugging symbols when you built your program by adding -g argument to gcc (or other compiler).
i'm having a bit of trouble with assembly, I'm using TASM for compiling and TLINK for linking (yes I know these are old and outdated, but switching isn't currently an option so please don't suggest that).
Here is the situation. A user types in a path in console, program jumps to that directory and tries to open any files inside. I only know how to access files when I know their name. So how would one do something like this?
P.S. though general logic is fine too, if you write any code please comment it, I'm very much new to this.
You have to scan the directory. Depending upon your SO, this is done by different ways. For example, if you are in DOS environment, which is what I assume by the tools you are using, this is accomplished by using function 4Eh of int 21h. Then, you can use service 4Fh to get subsequents files.
DS:DX must point to the ASCIIZ string containing the path where you want to search for files. The path must include the file name, or some kind of wilcard (for example *.* if you want to scan the complete directory). This is for function 4Eh. Function 4Fh resumes the scan from the file following the one that was found by function 4Eh or a previous call to function 4Fh.
A code for this would be:
;setup a DTA for scanning directories
mov dx,offset of your DTA block
mov ax,segment of your DTA block (normally your current data segment)
mov ds,ax
mov ah,1Ah
int 21h
;setup registers for int 21h,4Eh
;including DS:DX = ASCIIZ string with path and possibly, wilcard.
;......
;......
mov ah,4Eh
int 21h
cmp cx,0
jnz NoMoreFiles
NextFile:
;Parse DTA to obtain filename and extension of the first file found (at offset 30d)
;......
;......
mov ah,4Fh
int 21h
jc NoMoreFiles
jmp NextFile
NoMoreFiles:
More details about what DOS services to use and what parameters they expect, here:
http://bbc.nvg.org/doc/Master%20512%20Technical%20Guide/m512techb_int21.htm
How do I make gdb print functions of interest as they are called, indented according to how deep in the stack they are?
I want to be able to say something like (made up):
(gdb) trace Foo* Bar* printf
And have gdb print all functions which begin with Foo or Bar, as they are called. Kind of like gnu cflow, except using the debugging symbols and only printing functions which actually get called, not all possible call flows.
Tools which won't help include cachegrind, callgrind and oprofile, which order the results by which functions were called most often. I need the order of calling preserved.
The wildcarding (or equivalent) is essential, as there are a lot of Foo and Bar funcs. Although I would settle for recording absolutely every function. Or, perhaps telling gdb to record all functions in a particular library.
Some GDB wizard must have a script for this common job!
In your case I would turn to the define command in gdb, which allows you to define a function, which can take up to 10 arguments.
You can pass in the names of functions to "trace" as arguments to the function you define, or record them all in the function itself. I'd do something like the following
define functiontrace
if $arg0
break $arg0
commands
where
continue
end
end
if $arg1
...
Arguments to a user-defined function in gdb are referenced as $arg0-$arg9. Alternatively, you could just record every function you wanted to trace in the function, instead of using $arg0-9.
Note: this will not indent as to depth in the stack trace, but will print the stack trace every time the function is called. I find this approach more useful than strace etc... because it will log any function you want, system, library, local, or otherwise.
There's rbreak cmd accepting regular expression for setting breakpoints. You can use:
(gdb) rbreak Foo.*
(gdb) rbreak Bar.*
(gdb) break printf
See this for details on breakpoints.
Then use commands to print every function as it's called. E.g. let α = the number of the last breakpoint (you can check it with i br if you missed), then do:
(gdb) commands 1-α
Type commands for breakpoint(s) 1-α, one per line.
End with a line saying just "end".
>silent
>bt 1
>c
>end
(gdb)
Some elaboration: silent suppresses unnecessary informational messages, bt 1 prints the last frame of backtrace (i.e. it's the current function), c is a shortcut for continue, to continue execution, and end is just the delimiter of command list.
NB: if you trace library functions, you may want to wait for lib to get loaded. E.g. set a break to main or whatever function, run app until that point, and only then set breakpoints you wanted.
Use the right tool for the job ;)
How to print the next N executed lines automatically in GDB?
Did you see litb's excellent anwser to a similar post here ?
He uses readelf to get interesting symbols, gdb commands to get the trace, and awk to glue all that.
Basically what you have to change is to modify his gdb command script to remove the 1 depth from backtrace to see the stack and filter specific functions, and reformat the output with an awk/python/(...) script to present it as a tree. (I admit I'm too lazy to do it now...)
You may call gdb in batch mode (using -x option), break where you need and ask for backtrace (bt), then you filter the result using grep or egrep.
Indents are more difficult, however bt output is ordered so you have current function at the top of the trace and main at very bottom.
So you create file with commands:
br <function name where to break>
run
bt
kill
quit
then run gdb <program> -x<command file>
Filter strings that starts with #<digit> - you get stack trace.