Why is my nasm program killing itself?
in [ASM]
|
Prev: Sudoku
Next: Linux distro request
From: Herbert Kleebauer on 16 Apr 2008 04:49 Frank Kotler wrote: > Herbert Kleebauer wrote: > > I don't think this will solve the problem, there are still 3 bytes missing (from > > the "align 4") in the output file > > "output file" as in ".o" or the executable? > > > and therefore the data segment starts at an odd > > file address. > > For the most part, the files that get killed don't have a .data section. > Unless you count .bss as part of the .data section... which I guess it > is, for our purposes. > > > Try it with a program which prints an initialized variable. > Try it yourself! I mentioned that I couldn't run it "from here", and > that maybe if I copied the library file over... that worked ("of Didn't any experiments, but if I understand you and Chuck correctly, the situation is as following: The Author of the linker is a former DOS com programmer and wanted to avoid any unnecessary byte in the executable. Therefore, if there is data segment at all (and you always should have one, because, as I understand you, there are kernel versions which have a problem when the last segment isn't write able) and this data segment has a file size of 0 (only a .bss section but no .data section), he didn't align this block of zero bytes on a 4 byte boundary. But the loader still insist that this not existing bytes have to be aligned at a four byte boundary. Don't know which one is the bad boy, the linker or the loader (the elf specification should tell us, but I'm to lazy). But obviously the loader doesn't complain if the start address of this zero byte block is outside the file limits (as long as it is aligned) or my hand written elf header would and the code generated by your patch program could crash. But back to your patch program, I think it is still buggy: > >> ; fetches byte 48h, rounds up to a multiple of 4 > >> ; and stuffs it into byte 58h You shouldn't use byte 48h (code_memsz) but 44h (code_filez) which in most cases is the same, but somebody could use a "resb" at the end of the code. And you also shouldn't round a byte but a dword or $123456ff becomes $12345600 instead of $12345700 Conclusion: To avoid this bug, either make your code size a multiple of 4 (add an "align 4" at the end of the code) or make sure you don't have a data segment with a file size of 0 (add at least one byte in the ..data section).
From: Frank Kotler on 16 Apr 2008 09:36 Herbert Kleebauer wrote: > Frank Kotler wrote: >> Herbert Kleebauer wrote: > >>> I don't think this will solve the problem, there are still 3 bytes missing (from >>> the "align 4") in the output file >> "output file" as in ".o" or the executable? >> >>> and therefore the data segment starts at an odd >>> file address. >> For the most part, the files that get killed don't have a .data section. >> Unless you count .bss as part of the .data section... which I guess it >> is, for our purposes. >> > >>> Try it with a program which prints an initialized variable. > >> Try it yourself! I mentioned that I couldn't run it "from here", and >> that maybe if I copied the library file over... that worked ("of > > > Didn't any experiments, Rather guess? Or trust the docs? > but if I understand you and Chuck correctly, the > situation is as following: > > The Author of the linker is a former DOS com programmer :) > and wanted to > avoid any unnecessary byte in the executable. Therefore, if there is data > segment at all (and you always should have one, because, as I understand > you, there are kernel versions which have a problem when the last segment > isn't write able) True. Or use "Brian Raiter's method", which is like yours, only instead of worrying about section alignment, everything goes in one section, and if you claim you've got a writeable data section, the whole thing is flagged writeable > and this data segment has a file size of 0 (only a .bss > section but no .data section), he didn't align this block of zero bytes > on a 4 byte boundary. But the loader still insist that this not existing > bytes have to be aligned at a four byte boundary. Don't know which > one is the bad boy, the linker or the loader (the elf specification > should tell us, but I'm to lazy). Me too. You're obviously quite familiar with the executable spec, but this is a different issue. Since all the assemblers I've tried, and all (two) of the kernels/loaders I've tried exhibit the same behavior, the linker is "odd man out", regardless of what the spec says. > But obviously the loader doesn't complain if the start address of this > zero byte block is outside the file limits (as long as it is aligned) > or my hand written elf header would and the code generated by your patch > program could crash. > > > But back to your patch program, I think it is still buggy: > >>>> ; fetches byte 48h, rounds up to a multiple of 4 >>>> ; and stuffs it into byte 58h > > You shouldn't use byte 48h (code_memsz) but 44h (code_filez) which > in most cases is the same, but somebody could use a "resb" at the > end of the code. And you also shouldn't round a byte but a dword > or $123456ff becomes $12345600 instead of $12345700 True, but you know us old dos .com programmers! :) Who would have a section larger than 265 bytes??? :) Seriously, that's a stupid error. I'm embarrassed. I'd be more embarrassed if it wasn't intended as a joke (and possibly an example of a "filter" for Almas). That's what comes of "code first, think later"... > Conclusion: > To avoid this bug, either make your code size a multiple of 4 > (add an "align 4" at the end of the code) or make sure you don't have > a data segment with a file size of 0 (add at least one byte in the > .data section). .... or shitcan the buggy linker and replace it with one in which the bug has been fixed! It *is* fixed... Best, Frank
From: Rod Pemberton on 16 Apr 2008 14:06 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:%hnNj.3041$SR2.2445(a)trndny03... > True, but you know us old dos .com programmers! :) Who would have a > section larger than 265 bytes??? :) > What are the extra 9 bytes for? ;) RP
From: Frank Kotler on 16 Apr 2008 15:21
Rod Pemberton wrote: > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > news:%hnNj.3041$SR2.2445(a)trndny03... >> True, but you know us old dos .com programmers! :) Who would have a >> section larger than 265 bytes??? :) >> > > What are the extra 9 bytes for? ;) I use 'em to swap the second and third character... Good catch, Rod! Best, Frank |