Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: Frank Kotler on 9 Apr 2008 16:07 Herbert Kleebauer wrote: > Frank Kotler wrote: > >> Well... I just installed Slackware 12.0 to "see for myself". Sure >> enough, "Killed". He wasn't bullshittin' us. > > What was killed? I typed in, from memory, the *first* program Ivan posted. Apparently it was close enough. What gets killed is the loader - not actually our code at all. Our code kills the buggy kernel (instead of the usual situation :) I tried a number of modifications - put "i" on the stack, in .data, in ..bss... As I said, the trick seems to be "if we've got .bss, we need ..data". There may be more to it than that, but that seemed like a "constant". Doesn't correspond exactly to Ivan's original observation... there may be something involving .text size, too... > Could you verify: > > 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 did *not* verify that one. I don't think Ivan showed us the complete code. I suspect coincidence, or perhaps a .text size issue (if there is one). I did not verify the "can't execute binary file" on "your method" either. There are a lot of things I didn't try. I was havin' a really bad day, Herbert! At one point, I got as far as booting the suspect kernel, and figured "try this quick, while it's working". I *think* I can boot into that kernel again, and perhaps I will, but I'm a little gunshy right now. Between buggy software and my own incompetence, I *really* fucked my system up! Getting things "back in shape" is my first priority... >> The deal seems to be: if you've got a .bss section, you *must* also have >> a .data section. Just a .text section seems to be okay, unlike some >> earlier kernels. > > As far as I remember, elf doesn't know anything about .text or .bss. > You just specify flags for the included segments. I use two segments, > one for code and constants with the flags: > > SEGM00_flags=5 ; PF_R + PF_X (1: execute 2: write 4:read) > > and one for initialized and initialized data (.text + .bss) with > the flags: > > SEGM01_flags=6 ; PF_R + PF_W (1: execute 2: write 4:read) What about "bits"/"nobits", "load"/"noload", etc.? There's more to it than those three bits. The kernel knows enough to be buggy!!! .... > May be you should start to collect live CD's (which you can start > directly from CD without installing on the disk) of the different > Linux versions. One piece of good news from yesterday, I *finally* figured out how to burn a CD in Linux - a skill I've been missing. Turns out, I need an extra parameter at boot time "hdd=ide-scsi" if the "CD ROM"s going to be writeable. Then the device is just 0, 0, 0... Besides Linux versions, I've got a live CD .iso of ReactOS I've been wanting to try... My roomie'll gladly burn one for me, but it's embarrassing to have to resort to Windows! And I can do backups! A Good Thing. Only made one coaster, actually... I'm also intrigued with that "boot straight from .iso" concept. May not be suitable for "live" .isos, but install programs are interesting to compare (create???), too. >>> Does a virus scanner exist for Linux? >> Dunno, but I'd keep away from Slackware 12.0. Never had a problem with >> Slackware before... 13.0 will probably be fine. This one's not staying >> around long... if I can get rid of it! > > Maybe Linux itself is a virus, go back to Windows! I *know* Windows is a virus. Every time *one* of my friends gets a new version, pretty soon *all* of my friends have got it! :) Seriously, in the depths of my despair, the thought "BSD..." passed through my mind, but "Back (Waaaay Back) to Windows"? Not a chance. Best, Frank
From: Chuck Crayne on 9 Apr 2008 16:34 On Wed, 09 Apr 2008 05:50:22 GMT Frank Kotler <fbkotler(a)verizon.net> wrote: > Well... I just installed Slackware 12.0 to "see for myself". Sure > enough, "Killed". He wasn't bullshittin' us. When you get a chance, would you please send me one or more of the failing executables? I don't expect them to fail on my system, but I would like to see just what the loader is working with. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Rod Pemberton on 9 Apr 2008 17:13 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:yOYKj.2100$bQ1.451(a)trndny09... > Fscking fsck first > needs to check /dev/hda because it's been mounted 20 times without > checking, next try, fsck has to check it because it hasn't been checked > for 49710 days. Right. Didn't I tell you? Don't run fsck. ;-) fsck fscks FS'... Yup, nothing like fsck to screw up data, IMO. You must've missed the RP vs. PC why fsck exists sub-thread on clax...: RP: "D) fsck corrupts disks, if it runs when the disk is in a consistent state." PC: "Do you have any evidence for this bizarre claim? Cite or retract." Not just me now Phil... RP: "... fsck exists only to correct filesystem errors and is only run to correct them. It's totally useless otherwise. It never would've been written otherwise." > I think I'm going to be able to restore my system - I've gotten this far > - but I wanted to post the "answer", in case I suicide first. "Wine is fine. But, Whiskey's quicker." ... "Thought you'd escape the reaper?" "You can't escape the master keeper!" (Suicide Solution - Ozzy Osbourne) :-) Rod Pemberton
From: Frank Kotler on 9 Apr 2008 22:43 Chuck Crayne wrote: > On Wed, 09 Apr 2008 05:50:22 GMT > Frank Kotler <fbkotler(a)verizon.net> wrote: > >> Well... I just installed Slackware 12.0 to "see for myself". Sure >> enough, "Killed". He wasn't bullshittin' us. > > When you get a chance, would you please send me one or more of the > failing executables? I don't expect them to fail on my system, but I > would like to see just what the loader is working with. Okay... on their way... I think. After just triple-posting to clax (when the pop-up says the message hasn't been sent, it means it has - I get it!), I got an error sending to you - I think this one was "real" - had "crayne,org" instead of "crayne.org" duh! I'm really feelin' like a newbie lately! Sorry if I sent it more than once... Let me know if I didn't send it at all. What would be useful, I think, is a comparison between a "failing" executable and an "okay" one, as similar as possible. Ivan said it worked with only one write to "[i]" in .bss. I didn't try that exact combination, nor the "mov al, 10" vs "mov ax, 10" he alluded to. Besides the "buggy kernel" I had a "problem" with lilo. Possibly my own fault (the manual *says* it's dangerous). When I try to boot my "preferred" partition, instead of the lilo menu, I see "L 9A 9A 9A..." for about a half a screen, then it hangs... Gotta get back to that... Noticed, just in passing, that Slackware uses ISOLINUX as an installer - copyright by one H. Peter Anvin - maintainer of Nasm. Lilo is copyright John Coffman, who wrote the "jump optimization" code for Nasm... so at least I'm among friends! :) (I'll have to look into exactly what ISOLINUX "is"... might be something for Rod, and I think there's Nasm code in it...) I copied the latest "loadlin" over to my dos partition from that directory, too. Maybe go back to booting dos and loading Linux from there, if all else fails. That used to work good for me. I only stopped because dos was revectoring bios interrupts, and LRMI (Linux Real Mode Interface) didn't like it... I'm supposed to be an assembly language programmer. Surely I can fix a broken bootsector (and/or MBR)... right??? Ahhh, sleep first or boot first? Best, Frank
From: Chuck Crayne on 10 Apr 2008 01:43
On Thu, 10 Apr 2008 02:43:34 GMT Frank Kotler <fbkotler(a)verizon.net> wrote: > Okay... on their way... To my surprise, it fails (Killed) on my system. So much for my kernel bug has been fixed theory. However, I have a new theory. Perhaps you remember a discussion on the Nasm-devel list in which hpa informed me that the Red Hat Nasm RPM contained a patch to the outelf code, and that I fixed the code so that the Red Hat patch was no longer needed. Well, it appears to me that Slackware 12.0 does not have that patch. The symbol table for the object module which you sent me looks like this: Symbol table '.symtab' contains 8 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 FILE LOCAL DEFAULT ABS ivan.asm 2: 00000000 0 SECTION LOCAL DEFAULT ABS 3: 00000000 0 SECTION LOCAL DEFAULT 1 4: 00000000 0 SECTION LOCAL DEFAULT 2 5: 00000000 0 SECTION LOCAL DEFAULT 3 6: 00000000 0 NOTYPE LOCAL DEFAULT 2 ibss 7: 00000000 0 NOTYPE GLOBAL DEFAULT 3 _start Symbol #2 should not be there, which is the symptom of the bug which I fixed, and the fact that it is there seems to have confused the linker, which generated: Symbol table '.symtab' contains 10 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 08048080 0 SECTION LOCAL DEFAULT 1 2: 080490c0 0 SECTION LOCAL DEFAULT 2 3: 00000000 0 SECTION LOCAL DEFAULT 3 4: 00000000 0 FILE LOCAL DEFAULT ABS ivan.asm 5: 080490c0 0 NOTYPE LOCAL DEFAULT 2 ibss 6: 08048080 0 NOTYPE GLOBAL DEFAULT 1 _start 7: 080490bf 0 NOTYPE GLOBAL DEFAULT ABS __bss_start 8: 080490bf 0 NOTYPE GLOBAL DEFAULT ABS _edata 9: 080490c4 0 NOTYPE GLOBAL DEFAULT ABS _end Although the linker has deleted the bogus ABS section symbol, it has moved the file symbol from #1, where it belongs, to a position after the section symbols -- which is a violation of the ELF standard. According to the change log, my fix appeared in 0.99.06, so, if you feel like exploring this any further, I suggest that you test it with that, or any later, version. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html |