Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: Chuck Crayne on 30 Mar 2008 20:18 On Sun, 30 Mar 2008 14:53:02 -0700 (PDT) ivanatora <ivanatora(a)gmail.com> wrote: > I thought .bss blocks are for > variables only, while the .data blocks is for constants... ..bss blocks are used for uninitialized data, and may be either constants or variables. .data blocks are used for initialized data, and may also be either constants or variables. .rodata provides some protection for constants, because it is read only. As for the warning from Nasm, it is just there to remind you that the variable has not been initialized, and can be ignored. However, if you want to get rid of it, use db instead of resb. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Phil Carmody on 31 Mar 2008 04:19 Frank Kotler <fbkotler(a)verizon.net> writes: > Phil Carmody wrote: > > Well, I don't see any "direct to ELF executable" being done > > here. Precisely where do you see creation of an ELF executable? > > (11:47:01)[ivanatora@~/asm]$ nasm -f bin -o blah test_esi.asm > > Do try to pay attention, Phil! <<< $ nasm -hf [...] valid output formats for -f are (`*' denotes default): * bin flat-form binary files (e.g. DOS .COM, .SYS) [...] >>> <<< $ nasm -o /tmp/x -f bin /usr/share/doc/nasm/examples/xchg.asm $ file /tmp/x /tmp/x: Non-ISO extended-ASCII text, with no line terminators bash-3.1$ od -t x1 /tmp/x 0000000 90 90 91 91 92 92 93 93 94 94 95 95 96 96 97 97 0000020 66 90 66 90 66 91 66 91 66 92 66 92 66 93 66 93 0000040 66 94 66 94 66 95 66 95 66 96 66 96 66 97 66 97 .... >>> If that's an ELF executable, I'm a dutchman, in fact it looks remarkably like a DOS .COM file, which really shouldn't be a surprise given that '-f bin' is supposed to create flat-form binary files such as DOS .COM files. Phil -- Dear aunt, let's set so double the killer delete select all. -- Microsoft voice recognition live demonstration
From: Rod Pemberton on 31 Mar 2008 05:18 "Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in message news:87sky7joep.fsf(a)nonospaz.fatphil.org... > Frank Kotler <fbkotler(a)verizon.net> writes: > > Phil Carmody wrote: > > > Well, I don't see any "direct to ELF executable" being done > > > here. Precisely where do you see creation of an ELF executable? > > > > (11:47:01)[ivanatora@~/asm]$ nasm -f bin -o blah test_esi.asm > > > > Do try to pay attention, Phil! > > <<< > $ nasm -hf > [...] > valid output formats for -f are (`*' denotes default): > * bin flat-form binary files (e.g. DOS .COM, .SYS) > [...] > >>> > > <<< > $ nasm -o /tmp/x -f bin /usr/share/doc/nasm/examples/xchg.asm > $ file /tmp/x > /tmp/x: Non-ISO extended-ASCII text, with no line terminators > bash-3.1$ od -t x1 /tmp/x > 0000000 90 90 91 91 92 92 93 93 94 94 95 95 96 96 97 97 > 0000020 66 90 66 90 66 91 66 91 66 92 66 92 66 93 66 93 > 0000040 66 94 66 94 66 95 66 95 66 96 66 96 66 97 66 97 > ... > >>> > > If that's an ELF executable, I'm a dutchman, in fact it > looks remarkably like a DOS .COM file, which really > shouldn't be a surprise given that '-f bin' is supposed > to create flat-form binary files such as DOS .COM files. > Despite numerous indications the code is for Linux (Linux shell prompt, int 0x80, etc), Phil "asks" the following: Q) If "nasm -f bin" generates flat form, non-ELF code, e.g., for DOS .COM's, how can "nasm -f bin -o blah test_esi.asm" be ELF code? A) Because it contains Herbert Kleebauer's flat form ELF header code: http://groups.google.com/group/alt.lang.asm/msg/d70f1af34f81f6b8?hl=en > > Do try to pay attention, Phil! Yes, do try to pay attention, Phil! Rod Pemberton
From: ivanatora on 3 Apr 2008 13:01 Okaay, what is wrong with that: mov al, 10 This gets the program (another one) killed. If I change it into this: mov ax, 10 it is working! I can't use mov with AH or AL, only with AX, EAX, etc... I tried representing numbers in different ways - 10, 0xA ... I've just read a very usefull article here: http://www.geocities.com/siliconvalley/park/3230/x86asm/asml1002.html And that drives me on the conclusion that you have to very carefully think before using every MOV. That is really hitting me hard.
From: Frank Kotler on 3 Apr 2008 15:11
ivanatora wrote: > Okaay, what is wrong with that: > mov al, 10 > This gets the program (another one) killed. > If I change it into this: > mov ax, 10 > it is working! > I can't use mov with AH or AL, only with AX, EAX, etc... > I tried representing numbers in different ways - 10, 0xA ... You're not doing anything wrong. I'm pretty convinced, at this point, that you've got a "buggy kernel". Aside from the fact that it does something different, the only difference between "mov al, 10" and "mov ax, 10" is the size. I'm guessing that kernel must need, or "not like" some particular size or alignment of the ".text" section (and/or some other section)... If you're willing to put some time into experimentation, with a possible "inconclusive" result... try something like: global _start section .text _start: mov eax, 1 int 80h times 13 nop ; with and without: section .data db 0 ; just to give it some content Meddle with the number, and see if you can find some pattern to what gets killed and what doesn't... Finding some reliable workaround is probably easier than changing your kernel... Or start with your "mov al, 10" example that's getting killed and add "nop"s ("nop" is "no operation" - literally "xchg eax, eax"... ax in 16-bit code - db 90h). There's nothing wrong with the "assembly language" part of anything you've shown us! It's easy to cause a segfault - when you see that, it's probably your fault. But I don't even know *how* to generate "killed" on purpose! (allocate more memory than exists, I guess... and then you'd have to write to it, I think) > I've just read a very usefull article here: > http://www.geocities.com/siliconvalley/park/3230/x86asm/asml1002.html > And that drives me on the conclusion that you have to very carefully > think before using every MOV. That is really hitting me hard. Well, since I'm to damn lazy to write a tutorial, I shouldn't criticize other's work. But if I were going to, I'd point out... -------------------- Thus, mov [var1], [var2] must be transformed into: mov ax, [var2] mov [var1],ax That's the way. Why do we do this? Well, don't ask me... ask the maker of the assembler ;-). --------------------- Wrong! Ask the maker of the CPU!!! Ask 'em why they didn't put in two address busses - that's the reason, AFAIK... .... ----------------- Analoguously, mov ax, [var1+2] is from address 102h and so on. However, you cannot have the plus constant too high, like mov ax, [var1+1000]. ;-) I guess the maximum is 8. I'm not certain. Why don't you try it then? ------------------ Okay... Works for me! This might be a "Tasm issue", but I'm not aware of it... There isn't anything special about "mov" that you need to worry about. Of course, you *do* need to think carefully about what you're doing, and about what you *want* to do, and about whether they're the same or not! :) I've only taken a very quick look at the kernel tree. I don't think I know enough "git" to do exactly what I want - examine changes to fs/binfmt_elf.c, in particular - at least not online... I think if I installed the git tree on my machine, I could do it. Not ready for that, quite yet. I'll try some more... maybe even "stop and ask directions" if it comes to that. :) Meanwhile, try padding your "problem" code with "nop"s (or otherwise), and see if that helps. "mov al, 10" should *not* be getting killed, period!!! (says so right here in the glossy brochure!) Best, Frank |