IRC channel logs
2022-02-20.log
back to list of logs
<muurkha>I've definitely learned a lot from looking at gcc asm output <muurkha>gcc -S and especially gcc -g -Wa,-adhlns=foo.lst <muurkha>22:35 < stikonas> yeah, the steep curve of learning assembly is that it forces you to use syscalls from the very beginning <muurkha>this is not really true unless you're compiling without the standard C library <muurkha>or building for a platform that doesn't have one <muurkha>you do not need to call open to open stdout normally <muurkha>`file hello-world` will tell you what format it is <unmatched-paren>hello-world: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped <muurkha>possibly that you just assembled it without linking <muurkha>rename it to hello-world.o and try `ld -o hello-world hello-world.o` <muurkha>the kernel isn't as helpful as it could be in that case <muurkha>nothing is a big step up from "Segmentation violation" <muurkha>or "exec format error" — nothing means it ran! <muurkha>yeah, you're passing it two addresses that both don't make sense <muurkha>but... are you calling stat on purpose? <muurkha>may be useful to know that 0x48 is 'H' <muurkha>perhaps you're accidentally calling stat() instead of write() <muurkha>but also you're passing it 'H' instead of the memory address where 'H' lives, which is an easy mistake to make in assembly <muurkha>probably you should have something like mystring: DB "Hello world\n", 0 <muurkha>potentially but it doesn't really matter <muurkha>although I'm a little rusty on Intel-style syntax <muurkha>data bytes. it means "put these bytes in the program here" <muurkha>maybe in Intel-style syntax $mystring is just mystring <muurkha>write() expects a memory address at which to find the data to write <muurkha>so you have to store the data at a memory address in order to appease it. and DB (.asciz in gas syntax) is the easiest way to do that <muurkha>or is there just a 0 following it by coincidence? <muurkha>like, if you don't have anything after it, the rest of the segment might be filled with 0s by default <muurkha>the `` syntax is new to me, and it might be a nasm thing for appending a 0 "implicitly" too <muurkha>um, I guess in the case of write() you don't need the 0! <muurkha>you just need to tell it how many bytes to write <stikonas>unmatched-paren: now you can check how M0 does printing <muurkha>it's just the C string stuff that uses the trailing 0 <stikonas>but it's just a convention to terminate strings with zero <stikonas>well, it's either terminate with some character or always have string + length <stikonas>you don't want kernel to loop forever in case somebody forgot null byte <stikonas>unmatched-paren: you can write to a file but it's more of the same <stikonas>well, you can do that as intermediate step <stikonas>but later you should start learning functions <stikonas>that will force you to start using stack <muurkha>open() or openat() does use a nul terminator for the filename <unmatched-paren>i should probably also figure out how to write to memory and not just registers <stikonas>unmatched-paren: well, easiest way (and that's what stage0-posix does) is to allocate memory using brk <stikonas>unmatched-paren: actually you already dealt with reading from memory <unmatched-paren>The openat2() system call is an extension of openat(2) and provides a superset of its functionality. <stikonas>after forking, you have to wait for processs <stikonas>none of the old syscalls get removed due to syscall interface compatibility <stikonas>unmatched-paren: anyway, you already deal with memory a bit <stikonas>sys_write syscall takes a pointer to address in memory <stikonas>on risc-v I had to use load/store instruction to deal with memory access, but I think on amd64 opcodes can take memory addresses directly <unmatched-paren>i'll try doing file io and memory writes tomorrow. thanks for all the help \o <oriansj>all registers indicated may change during a syscall so if you care about the values in those registers save them onto the stack prior to the syscall <oriansj>the best way to learn AMD64 assembly is to write a simple couple line program and compile it with nasm and then use gdb (layout asm then layout regs) then do si to single step your binary. Look at the registers and notice how they change when each instruction is executed. You can do this with any instruction to get a clue to how it behaves (only div and udiv require you to read the manual) <oriansj>the core assembly instructions you need to know are mov, add, sub, cmp, je, jne, push, pop, call and ret with mov being the one you will use the most <oriansj>I suggest nasm assembly over at&t assembly (unless you plan on being multi-architecture then at&t is a better choice) but they both work just fine <oriansj>stikonas: the simplest hello world in assembly would be mov 1, rax; mov 1, rdi; mov $message, rsi; mov 12, rdx; syscall; mov 60, rax; mov 0, rdx; syscall; message: "hello world" (so 8 instructions) <oriansj>now syscalls don't care if the strings are null terminated or not, they just care how many bytes you told it to write and to what file (which stdin, stdout and stderr are; just files) <oriansj>the reason strings in assembly usually are null terminated is because it is much easier to just write a function that reads bytes until null and syscalls than passing the length of your string (unless of course your assembler supports .length macros which handles calculating that for you) <oriansj>everything you need to know about assembly, you can see in cc_*.S and you should always ask questions if something is not perfectly clear <oriansj>now if you care about learning about byte coding, displacement calculation, immediate encoding and other machine level details there are other tools you need to know about and I certainly have some notes that I can share. <muurkha>oriansj: that is good advice but unmatched-paren was already closed <oriansj>muurkha: We have logging for a reason; and those who choose not to be constantly active still can see what they miss while offline. <oriansj>and others can learn too by reading of the logs <muurkha>I'll try to link unmatched-paren to the logs if they reappear