NASM 0.98.39 vs. NASM 2.03.01 disassembly
in [ASM]
|
Prev: announce: my very first disassembler now available (GPL)
Next: Win32 non blocking console input?
From: Frank Kotler on 28 Aug 2008 04:04 Rod Pemberton wrote: .... > I'd have some questions about the compatibility of loadlin with FreeDOS. Yeah, could be an issue. First time I've noticed a problem, but I haven't used it much. I *used* to boot to dos - MS dos (7.0?), not FreeDOS - all the time, and start Linux with loadlin (or type "win" to start Windows). I started fooling with the Linux Real Mode Interface (lrmi on SourceForge), a library to assist with accessing bios functions (or other things, I guess) via a vm86 task. The example, which toggled through video modes, wasn't working. Obviously, for LRMI to access bios routines, bios has to be in ROM. Dos had apparently revectored the bios interrupts into RAM. Booting directly into Linux solved it, so I quit using loadlin... That unexpected power-down, or the even more unexpected stuck-on "soft" switch (Jeez, I miss the Big Red Switch!), could be influenced by bios power management settings. Linux shutdown sets CMOS time to system time, so accesses bios to that degree, at least. Could be a conflict between something FreeDOS has done to bios, and what Linux expects. Still pretty weird! > I've experienced something similar with DOS programs that corrupt > "something" usually by an out of bounds memory pointer. I'm not sure what > gets corrupted. Sometimes, I suspect CMOS (boosting the CPU clock settings > out of range) because the problem won't go away except by many reboots (each > autodetect adjusting the CPU clock) and sometimes it won't reboot without a > CMOS reset. Othertimes, the CMOS settings are wrong. But, sometimes the > CMOS settings are correct! I can't imagine how a program "accidentally" > reprograms the CMOS... Perhaps it's low memory IVT, BDA, etc. corruption. > But, these areas should all be reset by the powerdown of memory and a BIOS > initialization. So, I never came to any solid conclusions... I suspect this one is going to be "unresolved", too, since it isn't something I often do. Blame it on Cosmic Rays! Best, Frank
From: Herbert Kleebauer on 28 Aug 2008 14:31 Frank Kotler wrote: > > Although I get 08049000 from your program on my > > system, your result of 080480B9 can also be considered correct. > > Yeah, in a way... but not really, I think. The end of the data segment can by at any byte, why should it be on a 4096 byte boundary? But because paging is done with 4096 byte pages, you always can access the bytes after the data segment till the next 4096 byte boundary.
From: Herbert Kleebauer on 28 Aug 2008 14:31 Chuck Crayne wrote: > Herbert Kleebauer <klee(a)unibwm.de> wrote: > > > Where can I find the _official_ documentation of the int 80 interface? > > You can start with "man syscalls", but after that, you either have to > read the source code, or trust those of us who have already been there. open source = no documentation (Linux) closed source = GBytes of documentation (Windows) In this case I think I prefer the closed source. But how could they write the C library if there is no documentation of the int80 interface. I doubt that they got there information directly from the kernel source code. > The secret of translating the C interface to 80h calls is that the > syscall number goes in EAX, and the parameters are passed in registers, > beginning with EBX. Also, errors are returned as negative values. So, That's not a big secret, the secret is what exactly the syacall does. > mov eax,__NR_brk ;brk > xor ebx,ebx ;get current end > int 80h ;query kernel > > is the functional equivalent of > > sbrk(0); Are you sure? From the man page: ============================================================================== NAME brk, sbrk - change data segment size SYNOPSIS #include <unistd.h> int brk(void *end_data_segment); void *sbrk(intptr_t increment); DESCRIPTION brk() sets the end of the data segment to the value specified by end_data_segment, when that value is reasonable, the system does have enough memory and the process does not exceed its max data size (see setrlimit(2)). sbrk() increments the program's data space by increment bytes. sbrk() isn't a system call, it is just a C library wrapper. Calling sbrk() with an increment of 0 can be used to find the current location of the program break. RETURN VALUE On success, brk() returns zero, and sbrk() returns a pointer to the start of the new area. On error, -1 is returned, and errno is set to ENOMEM. ============================================================================== So, int80/eax=45 is brk and not sbrk. Therefore ebx has to be loaded with the absolute value of the data segment end and not with an increase value (like for sbrk). If I make these three calls (one after the other) of int80/eax=45 with ebx= 0 -> eax=0x0804a000 ebx=0x0804b000 -> eax=0x0804b000 ebx= 0x2000 -> eax=0x0804b000 This means only the second one is successful, the first and the third fails. But in any case, the return value in eax is the current end of the data segment and not ENOMEM. > This particular call cannot fail. No, it always fails because 0 isn't valid for the end of the data segment. > But if we followed it with > > add ebx,10000h ;65k bytes > mov eax,__NR_brk ;brk > int 80h ;kernel call > > and the requested memory was not available, then it would return the > negative value of ENOMEM in EAX. This also fails because 0x10000 also isn't a valid end of the data segment.
From: Frank Kotler on 28 Aug 2008 15:01 Herbert Kleebauer wrote: .... > But how could they write the C library if there is no documentation > of the int80 interface. AFAIK, the C library doesn't use the int 80h interface... Best, Frank
From: Robert Redelmeier on 28 Aug 2008 16:20
Herbert Kleebauer <klee(a)unibwm.de> wrote in part: > Chuck Crayne wrote: >> Herbert Kleebauer <klee(a)unibwm.de> wrote: >> >> > Where can I find the _official_ documentation of the int 80 interface? You cannot, because int 80h is not official. Linus has promised he will change it on a whim. He has been falling down on the job and hasn't changed the lower numbers in a while. But the highers _do_ shift. >> You can start with "man syscalls", but after that, you either have to >> read the source code, or trust those of us who have already been there. It is not quite that bad. /usr/include/asm-i386/unistd.h contains the syscall numbers & names. The names have corresponding libc calls that have nice manpages. > open source = no documentation (Linux) Not quite, even on my sparse system (kilobytes listed): $ du /usr/man | sort -n | tail 296 /usr/man/man4 312 /usr/man/pl 352 /usr/man/man6 700 /usr/man/man7 1284 /usr/man/man5 1320 /usr/man/man2 2448 /usr/man/man8 9740 /usr/man/man1 12428 /usr/man/man3 31128 /usr/man $ du /usr/doc | sort -n | tail 3564 /usr/doc/subversion-1.2.3 3812 /usr/doc/libxml2-2.6.21 4580 /usr/doc/abiword-2.2.9/docs 4640 /usr/doc/abiword-2.2.9 10164 /usr/doc/python-2.4.1/html/Python-Docs-2.4.1/lib 16652 /usr/doc/python-2.4.1/html/Python-Docs-2.4.1 16656 /usr/doc/python-2.4.1/html 19276 /usr/doc/python-2.4.1 33396 /usr/doc/Linux-HOWTOs 169448 /usr/doc > closed source = GBytes of documentation (Windows) Actually, I've seen very little on int 20h or 2Eh (NT syscalls). Mostly people advise me to use "INVOKE" which looks like it does far calls. > In this case I think I prefer the closed source. No accounting for taste. -- Robert |