Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: Herbert Kleebauer on 13 Apr 2008 03:11 Frank Kotler wrote: > So, if it's a "Nasm bug", Gas has the same problem... > > > Frank, I've tried that source on several machines and it gets killed > > > on both of them. These include kernel versions: > > > 2.6.23.9 > > > 2.6.21.5 > > > 2.6.12.4 If this bug was present such a long time, then assembly programming in Linux is even more dead than I thought. Here the links to the "Breakpoint 2008" demos. Especially the 4 kByte demos should be of interest for assembly programmer. (Couldn't check what's on the web site because for the weekend I only have a modem connection, but the article in the printed computer magazine sound interesting). http://www.heise.de/ct/08/09/links/056.shtml Also here should be some information about the "Breakpoint 2008": http://www.scene.org
From: Frank Kotler on 13 Apr 2008 12:12 Herbert Kleebauer wrote: > Frank Kotler wrote: > >> So, if it's a "Nasm bug", Gas has the same problem... > >>> > Frank, I've tried that source on several machines and it gets killed >>> > on both of them. These include kernel versions: >>> > 2.6.23.9 >>> > 2.6.21.5 >>> > 2.6.12.4 > > If this bug was present such a long time, then assembly programming > in Linux is even more dead than I thought. I can add a new kernel!!! 2.4.3.33 - what I'm currently running - is "killed", too!!! You'll recall we asked Ivan for his executable, and didn't get it... Eventually I installed Slackware 12.0 to "see for myself". Sure enough, "killed". Apparently, I never actually tried to run it on a "good" kernel... until now... and to my astonishment, "killed"! I guess this narrows it down to a linker problem. I was thinking that it took a combination of "certain ld" and "certain kernel" to manifest the bug. Apparently, a "certain ld" is enough. 2.6 kernels *are* fussier about what they'll load, but that *isn't* the problem after all! Which ld, or what range of versions is "to be determined"... ld seems unusually pissy about library versions. "/slack12/usr/bin/ld --version" barfs before even identifying itself. The library it can't find is libbfd-2.17.50.0.17.20070615.so - that would seem to be a clue. I *think* I tried 2.17.plain and it worked (which made me suspect the loader). 2.18 seems to work fine (*that* built okay). The fact that I made a "truncated" install of Slackware 12.0 turns out to be a problem. I couldn't get past "./configure", trying to build binutils on that system. Turns out "./configure" was right - I *don't* have a gcc capable of creating executables! I *thought* I included all the "development" stuff, but gcc can't fing obscure stuff like "stdio.h"! Maybe just an environment variable needs to be set, or maybe I didn't install it. I'm used to having gcc "just work". I doubt if I'll bother trying to fix it - if I'm going to run that distro, it needs to be installed on a bigger partition. It's a "dead issue", but since you claim C is what we should be using, I'll ask... Trying to build *older* binutils fails with: "array type has incomplete element type" I *think* this is the offending line (the middle one) with (perhaps not enough) context - binutils-2.13/gas/config/tc-i386.h, line 523: #define md_operand(x) extern const struct relax_type md_relax_table[]; #define TC_GENERIC_RELAX_TABLE md_relax_table Any idea what that's lookin' for? My guess is that it's finding different header files than the ones it was originally compiled with. I can get ld out of it, which is all I was after, so it's another "problem that doesn't need fixin'" - the best kind! :) The simplest workaround, for anyone confronted by this issue (I think Ivan's gone...) is "don't write such trivial programs". Next best is "align 4" at the end of the .text section (most ld versions "fix" this, apparently). I guess the "right" way is "upgrade ld". Or... we could just do it "your way", and not worry about ld bugs! This isn't the only "ld bug" I've encountered lately! HLA sometimes produces "funny" objects, which a "certain ld" screws up (dunno the version - Fedora Core 8, apparently). This really *is* a "HLA bug", IMO, but most ld versions seem to work... Doing it "your way" isn't an option for HLA - depends on static linking. (We *can* do dynamic linking! Have you looked at Stephen Pelc's example at all?) > Here the links to the "Breakpoint 2008" demos. Especially the 4 kByte > demos should be of interest for assembly programmer. (Couldn't > check what's on the web site because for the weekend I only have a modem > connection, but the article in the printed computer magazine sound > interesting). > > http://www.heise.de/ct/08/09/links/056.shtml > > Also here should be some information about the "Breakpoint 2008": > > http://www.scene.org Sign of the times, that 64k is considered a "demo"!!! I'll look at that... not right now... Best, Frank
From: Herbert Kleebauer on 14 Apr 2008 15:55 Frank Kotler wrote: > Herbert Kleebauer wrote: > > If this bug was present such a long time, then assembly programming > > in Linux is even more dead than I thought. > > I can add a new kernel!!! 2.4.3.33 - what I'm currently running - is > "killed", too!!! The binary should be killed in any kernel version (it is not conforming to the elf standard). The question is, how many Linux distributions used this buggy linker (or maybe the linker doesn't have a bug but the object file generated by the assembler isn't correct and newer versions of the linker can handle the incorrect object files). > I *think* this is the offending line (the middle one) with (perhaps not > enough) context - binutils-2.13/gas/config/tc-i386.h, line 523: > > #define md_operand(x) > > extern const struct relax_type md_relax_table[]; > #define TC_GENERIC_RELAX_TABLE md_relax_table > > Any idea what that's lookin' for? I can't read C code written by C (C++) programmer. It's completely different from C code written by assembly programmer. > (We *can* do dynamic > linking! Have you looked at Stephen Pelc's example at all?) I have read one article about doing it manually by using a trivial hash table, but I think I would prefer to modify the assembler so it would generate a real hash table. > > http://www.heise.de/ct/08/09/links/056.shtml > > > > Also here should be some information about the "Breakpoint 2008": > > > > http://www.scene.org > > Sign of the times, that 64k is considered a "demo"!!! I'll look at > that... not right now... I just took a look, it's not worth the efford.
From: Chuck Crayne on 14 Apr 2008 17:04 On Mon, 14 Apr 2008 21:55:25 +0200 Herbert Kleebauer <klee(a)unibwm.de> wrote: > or maybe the linker doesn't have a bug but the object > file generated by the assembler isn't correct and newer versions of > the linker can handle the incorrect object files That's what I was concerned about, because there was such a bug in nasm, which I fixed in V99.06, but I assembled Frank's "bad" example, not only with the most recent version, but also with V99.04, and found nothing in the object files which would account for this bug. So I agree with Frank that the linker was the culprit. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Frank Kotler on 14 Apr 2008 18:54
Herbert Kleebauer wrote: > Frank Kotler wrote: >> Herbert Kleebauer wrote: > >>> If this bug was present such a long time, then assembly programming >>> in Linux is even more dead than I thought. >> I can add a new kernel!!! 2.4.3.33 - what I'm currently running - is >> "killed", too!!! > > The binary should be killed in any kernel version (it is not conforming > to the elf standard). The question is, how many Linux distributions used > this buggy linker (or maybe the linker doesn't have a bug but the object > file generated by the assembler isn't correct and newer versions of the > linker can handle the incorrect object files). Newer and older versions - 2.17 and 2.18 seem to work. 2.17.50.0.17.20070615 is one version we know *doesn't* like object files built by Nasm, either 0.98.39 (what Slackware 12.0 comes with), or 2.02, or Gas (same version as ld, I assume). Haven't tried Fasm... I probably should. It may be that Nasm and Gas are producing faulty output, and every version of ld but this one (or some fairly narrow range) "fixes our mistake". Maybe I should say "unsuitable version", rather than "buggy linker"... We'll know computers are becoming more human when we see "error: the other computer did it". [binutils 2.11 and 2.13 won't build] FWIW, 2.16.1 *does* build... and will even link HLA's output! :) > I can't read C code written by C (C++) programmer. It's completely different > from C code written by assembly programmer. Possibly that's my problem. :) >> (We *can* do dynamic >> linking! Have you looked at Stephen Pelc's example at all?) > > I have read one article about doing it manually by using a trivial > hash table, but I think I would prefer to modify the assembler > so it would generate a real hash table. Okay. What's wrong with the "trivial" one? I'll have to look at Stephen's code again - he does "fudge" the hash table, IIRC. Eliminating the pesky linker is looking better and better to me! Here's one more way to fix a broken executable. More complicated than it needs to be - I was inspired by Almas! :) I don't know if it's even "right". Works on the few I've tried it on... I'll have to boot to 12.0 and make a few more. Or, hmmm, what if I copied over the missing libraries... Best, Frank ; fetches byte 48h, rounds up to a multiple of 4 ; and stuffs it into byte 58h ; nasm unkiller.asm ; chmod +x unkiller ;[map all] ;=========================================================================== bits 32 ORIGIN equ 8048000h org ORIGIN section .text code_offset equ 0 code_addr: ;--------------------------- ELF header ----------------------------------- dd $464c457f,$00010101,0,0,$00030002,1,main,$34,0,0,$00200034,2,0 dd 1,code_offset,code_addr,code_addr,code_filez,code_memsz,5,4096 dd 1,data_offset,data_addr,data_addr,data_filez,data_memsz,6,4096 main: ;--------- your code goes here ------------------------------------------ IN_OFF equ 48h OUT_OFF equ 58h xor edi, edi top: call getc cmp edi, IN_OFF jnz not_inbyte mov bl, al add bl, 3 and bl, 0FCh ; -4 not_inbyte: cmp edi, OUT_OFF jnz not_outbyte mov al, bl not_outbyte: call putc inc edi jmp short top exit: mov eax, 1 int 80h getc: push edx push ecx push ebx push eax mov edx, 1 mov ecx, esp xor ebx, ebx mov eax, 3 int 80h cmp eax, 1 jnz exit pop eax pop ebx pop ecx pop edx ret putc: push edx push ecx push ebx push eax mov edx, 1 mov ecx, esp mov ebx, 1 mov eax, 4 int 80h pop eax pop ebx pop ecx pop edx ret ;------------ constant data --------------------------------- ; (note that we're in .text, not .rdata) align 4 ; we have none ;--------------------------------------------------------------------------- align 4 code_memsz equ $ - $$ code_filez equ code_memsz data_addr equ (ORIGIN+code_memsz+4095)/4096*4096 + (code_filez % 4096) data_offset equ code_filez section .data vstart=data_addr ;------------ initialized data ------------------------------ ; we have none ; maybe we'd better add one, for the benefit ; of the "last section must be writeable" kernels dummy db 0 ;--------------------------------------------------------------------------- idat_memsz equ $ - $$ bss_addr equ data_addr + ($ - $$) section .bss vstart=bss_addr ;--------------------------- uninitialized data ------------------------ ; we have none ;--------------------------------------------------------------------------- udat_memsz equ $ - $$ data_memsz equ idat_memsz + udat_memsz data_filez equ idat_memsz ;=========================================================================== |