Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: Phil Carmody on 31 Mar 2008 11:31 Frank Kotler <fbkotler(a)verizon.net> writes: > If you thought I was trying to tell you Nasm would make an ELF > executable out of any old source code... no, it will not. Sorry for > the confusion. That indeed was the confusion. Building valid elf headers is the job of the binutils, not DDs in asm source. Phil -- Dear aunt, let's set so double the killer delete select all. -- Microsoft voice recognition live demonstration
From: ivanatora on 30 Mar 2008 05:37 Hello Frank, I'm glad you are still with me :) Later today I will be home and I will install another version of ld. About the killing the program, I get exactly that - Killed. This is from gdb: -------------------------------------------------------------- (gdb) run Starting program: /home/ivanatora/asm/zagadka Program terminated with signal SIGKILL, Killed. The program no longer exists. You can't do that without a process to debug. (gdb) -------------------------------------------------------------- I'm not sure if something else is behind that. First I thought about ulimits - but my program doesn't use any user resources at all (big memory blocks, cpu time, large number of open files...) Now I am near stuck. Later, Ivan.
From: Frank Kotler on 31 Mar 2008 13:24 ivanatora wrote: > Are you suggesting just to replace .bss with .data? I had in mind leaving your .bss as-is, and adding a .data section... either... try both... > Now I understand > how far away I am from assembly :D You're doing quite well... for a guy who gets killed all the time! :) > I thought .bss blocks are for > variables only, Uninitialized data... > while the .data blocks is for constants... Initialized data, but writeable. "Constants" - that is, things that are not "intended" to be written, and you want to error-out if you accidentally do it, can be in "section ..rodata" (Nasm knows the attributes for that one), or you could put 'em in ".text". Adding another section puts a little "bloat" in the header, but if you put "data" in ".text", disassemblers and all will try to disassemble it, which can be a pain. I usually put things which really ought to be "constants" into the ".data" section and "just don't" write on 'em, but "sleepy programmer errors" can creep in. As it happens, Nasm's defaults for an arbitrarily-named section would be right for a "constant" section... > How can the size of the segments be changed? Well... we could pad 'em out... global _start section .text _start: times 4096 nop mov eax, 1 int 80h section .data msg db "Hello Slackware 12.0!", 10 msg_len equ $ - msg times 4096 db 'X' section .bss char_buffer resb 1 resb 4096 You might be able to narrow down what your kernel's "requirements" are by assembling variations of that code and seeing which ones (if any) "live"... We can alter the default alignment of sections, too - "section .data align=4096". This *might* be an issue, but I'd look at "existance", of sections first, then "minimum size"(?)... > Btw, I managed to run the program without a kill! Mirabile dictu! Your code's been fine all along (I think) - Slackware's finally learning! :) If you were running some weird African distro, I'd half expect a curve ball in the kernel, but I thought "Patrick wouldn't do that to us!" I need to upgrade one of these days. I hear the drums saying "U Bun Tu", and I've been thinking of trying that, but maybe I'll stick with Slackware... just to see what's going on. > Here is the working code: [perfectly good code - as usual - snipped] > section .data > i resb 4 As you observed, Nasm warns about this. Does no harm. But "resb" just "res"erves space. resb, resw, resd, resq, rest, and reso should be used in an uninitialized section - ".bss", or you can use 'em in a "struc". In a ".data" section - or .rodata or .text, use db, dw, dd, dq, dt, do. One "gotcha" that still bytes me once in a while - "dw" looks like it might be "dword". No, no, no! "dw" is "define word" - we want (probably) "dd" - "define dword". I don't think I've ever used an "oword" (128 bits), and "dt" and "dq" only rarely... but they're there. If you can find the "combination" that will run reliably on your system, just "going along" is probably easiest. As I mentioned to Robert, this "bug" is probably an "added security feature". Fortunately, source code is available, so we "should" be able to nail it down exactly... but probably not today... This is probably making asm seem a lot "harder" than it really is, to you. As Betov says, "Courage"! Best, Frank
From: Frank Kotler on 31 Mar 2008 14:03 Phil Carmody wrote: > Frank Kotler <fbkotler(a)verizon.net> writes: > >>If you thought I was trying to tell you Nasm would make an ELF >>executable out of any old source code... no, it will not. Sorry for >>the confusion. > > > That indeed was the confusion. Building valid elf headers is > the job of the binutils, not DDs in asm source. That's the way I usually do it. This is "Herbert's idea". However... Herbert's right: the OS doesn't know what tools built an executable. If the bytes are in the right place, it's "valid". I'm not saying that Herbert's code *is* 100% "valid", but if it were (and I believe it is), it would make *no* difference if it came from binutils, or Nasm's "-f bin", or Lindela, or a hex editor. But we *do* have tools whose "job" it is to do this for us. Pity to put 'em out of work... Well, except for Gas, that is. :) Best, Frank
From: ivanatora on 30 Mar 2008 11:11
You mean you declare variables after you use them? It is kinda weird :) Nevermind, I tried that - moved section .bss after .text. Also increased bytes for 'i' to 4, but I think 1 byte is enough for that attempt. The result from that is half good, half bad. Now mov byte [i],65 works fine! But inc byte [i] - doesn't work fine and the result is 'Killed' again. Robert, we tried disassemblying with objdump -d and results from me and from users which don't have problem with that source - are all the same. I've put a breakpoint on a nop before _start and run gdb, but the program gets killed before reaching the _start point. |