Re: Strange behaviour in assembly language program
On Wednesday 03 March 2004 16:26, ari wrote: [EMAIL PROTECTED] said this stuff: .text .global _start _start: pushl $8 pushl $0 movl$1, %eax int $0x80 With this suggestion, it always returns 0 instead of 1. Shouldn't pushl place 4 bytes on the stack? It translates into the instruction 0x6A (pushes only one byte). 32-bit, 80386-based processors cannot push one byte onto the stack; they can push only in 2- or 4-byte increments (word or double-word). While instruction 0x6a pushes an immediate one-byte value, this is only to save instruction space. The number is in fact pushed as a 32-bit (sign-extended) value. Ah yes, silly me. I constantly forget the fact that when you push someting on the stack, the stack pointer does not increment but rather decrement. That's quite unnatural to me. The kernel expects the first argument 4 bytes *below* the stack pointer, and I pushed that stuff in the wrong order. This code works to return 0x57: 31 c0 40 6a 57 50 cd 80 But that needs 8 bytes! Can't it be shortened? I noticed that some registers contain zero on program startup. Can I safely assume they are always initialized to zero and just leave that 31 c0 out? I would need at least one byte off to have it fit nicely into the padding of the e_ident array, while not stepping on the program header. *g* (I've become fed up with software bloat) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange behaviour in assembly language program
On Wednesday 03 March 2004 16:26, ari wrote: [EMAIL PROTECTED] said this stuff: .text .global _start _start: pushl $8 pushl $0 movl$1, %eax int $0x80 With this suggestion, it always returns 0 instead of 1. Shouldn't pushl place 4 bytes on the stack? It translates into the instruction 0x6A (pushes only one byte). 32-bit, 80386-based processors cannot push one byte onto the stack; they can push only in 2- or 4-byte increments (word or double-word). While instruction 0x6a pushes an immediate one-byte value, this is only to save instruction space. The number is in fact pushed as a 32-bit (sign-extended) value. Ah yes, silly me. I constantly forget the fact that when you push someting on the stack, the stack pointer does not increment but rather decrement. That's quite unnatural to me. The kernel expects the first argument 4 bytes *below* the stack pointer, and I pushed that stuff in the wrong order. This code works to return 0x57: 31 c0 40 6a 57 50 cd 80 But that needs 8 bytes! Can't it be shortened? I noticed that some registers contain zero on program startup. Can I safely assume they are always initialized to zero and just leave that 31 c0 out? I would need at least one byte off to have it fit nicely into the padding of the e_ident array, while not stepping on the program header. *g* (I've become fed up with software bloat) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Strange behaviour in assembly language program
Hi! I'm already a bit experienced with assembly, and started to enter my executables directly in the hexeditor (for educational purpose only; I know this is poor programming style). I do not yet fully understand all aspects of the ELF header, but I managed to somehow write working ELF executables. I tried first a program that exits with status 1, and it works. But then I tried other values, and found out that it always exits with 1 no matter what I enter. I don't think I made a stupid mistake, because the Linux version (exit value given in EBX and ELF_OSABI = 03) runs perfectly in emulation mode. The first strange thing is, that it doesn't run on a real Linux system (tells me it doesn't have enough core memory for a 96 byte program). Second strange thing: Finally I came up with the simplest ASM program that reproduces the error. Here it is: .text .global _start _start: pushl $0 movl$1, %eax int $0x80 I looked everywhere (Developer's handbook, Google, ...) to find the solution, but all resources I consulted tell me this is the right way to do it. This program, however, always exits with 1 regardless of the value I push. Please, can someone tell me that I made a really stupid error? I'm already pulling my hair out. Thanks for your time. Daniela ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange behaviour in assembly language program
On Tuesday 02 March 2004 20:15, ari wrote: [EMAIL PROTECTED] said this stuff: Finally I came up with the simplest ASM program that reproduces the error. Here it is: .text .global _start _start: pushl $0 movl$1, %eax int $0x80 I looked everywhere (Developer's handbook, Google, ...) to find the solution, but all resources I consulted tell me this is the right way to do it. This program, however, always exits with 1 regardless of the value I push. .text .global _start _start: pushl $8 pushl $0 movl$1, %eax int $0x80 With this suggestion, it always returns 0 instead of 1. Shouldn't pushl place 4 bytes on the stack? It translates into the instruction 0x6A (pushes only one byte). BTW, when I assemble it with as(1), there is always an extra instruction after my code, and it's a different one each time (and it's always one that effectively does nothing). Who ordered that? Is it because of alignment constraints in the ELF file? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lots of kernel core dumps
On Tuesday 25 March 2003 08:14, Peter Jeremy wrote: On Mon, Mar 24, 2003 at 08:18:43PM +0100, Daniela wrote: Well, it's just a home server. I don't mind a few crashes, but security is important for me. What do you think, should I go back to -stable? If you're willing to put up with a few crashes _and_ assist with debugging the crashes (eg trying patches) then running -CURRENT would help the Project. One option you could try is to stick with -CURRENT for a month or two and see how it pans out - if you feel it's too painful, downgrade to -STABLE. (I ran -CURRENT on my main workstation for about 3 years - I dropped back to -STABLE midway through last year because -CURRENT happened to strike an extended period of instability and it was causing me too much angst). On the topic of security, you should be aware that -CURRENT is not officially supported and therefore isn't mentioned in security advisories - in general -CURRENT will have security patches applied before -STABLE but you will need to do some detective work if you want to identify the exact time/revision affected. There have also been a couple of instances where security problems only affected -CURRENT. In short, if I keep my eyes open, security isn't bad, right? I'll give -current a try, thanks for your advice. Daniela ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lots of kernel core dumps
I know, but 5.0-RELEASE was a) A work-in-progress, not a perfect, bug-free release b) A snapshot of 5.0-CURRENT You read the 5.0 Early Adopter's Guide, right? Bugs like this are expected at this stage in the development process, and if you encounter them then you need to either give up on 5.x and go back to 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed there. Kris Yes, I read the Early Adopter's Guide. Is there any way to solve this without upgrading to -current? I want a stable server, of course, but I still want to help the FreeBSD folks to make 5.0 the best release ever. This requires testing to be done. Daniela To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Lots of kernel core dumps
Hi all!
I'm getting lots of kernel core dumps on my server.
My RAM is OK, I tested it. Below are more detailed informations.
Any help would be greatly appreciated.
I'm not yet intimate with the kernel, but I'm willing to learn it all.
Thanks in advance.
Daniela
--
# uname -a
FreeBSD CM58-27.liwest.at 5.0-RELEASE-p3 FreeBSD 5.0-RELEASE-p3 #4: Sat Mar 1
18:08:27 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CM58-27
i386
# gdb -k kernel.debug vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bwrite: buffer is not busy???
panic messages:
---
panic: bad pte
syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 4h4m35s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 64[CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] 80[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 96[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 112 128 144[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] 160[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
176[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 192[CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] 208 224 240 256 272 288 304 320 336 352 368 384 400 416[CTRL-C to
abort] 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
232 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:232
#1 0xc033b5e6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:364
#2 0xc033b833 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#3 0xc0379fa2 in bwrite (bp=0xce4d4708) at /usr/src/sys/kern/vfs_bio.c:796
#4 0xc037b55e in vfs_bio_awrite (bp=0xce4d4708)
at /usr/src/sys/kern/vfs_bio.c:1643
#5 0xc0307737 in spec_fsync (ap=0xe0d1cb5c)
at /usr/src/sys/fs/specfs/spec_vnops.c:462
#6 0xc0306ca8 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc045fb8d in ffs_sync (mp=0xc40cd800, waitfor=2, cred=0xc150ae80,
td=0xc0584000) at vnode_if.h:612
#8 0xc038d01b in sync (td=0xc0584000, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:138
#9 0xc033b25c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:273
#10 0xc033b833 in panic () at /usr/src/sys/kern/kern_shutdown.c:517
#11 0xc04b7bbb in pmap_remove_pages (pmap=0xc43a33bc, sva=0, eva=3217031168)
at /usr/src/sys/i386/i386/pmap.c:2937
#12 0xc0326572 in exit1 (td=0xc456f9a0, rv=1) at vm_map.h:228
#13 0xc033ed26 in sigexit () at /usr/src/sys/kern/kern_sig.c:1997
#14 0xc033e97a in postsig (sig=1) at /usr/src/sys/kern/kern_sig.c:1886
#15 0xc035b3da in ast (framep=0xe0d1cd48) at /usr/src/sys/kern/subr_trap.c:254
#16 0xc04ac250 in doreti_ast () at {standard input}:446
---Can't read userspace from dump, or kernel process---
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Lots of kernel core dumps
On Friday 21 March 2003 22:10, Kris Kennaway wrote: On Fri, Mar 21, 2003 at 08:37:46PM +0100, Daniela wrote: Hi all! I'm getting lots of kernel core dumps on my server. My RAM is OK, I tested it. Below are more detailed informations. Any help would be greatly appreciated. I think this was fixed after 5.0-R..upgrade to -current and try again. Kris I'm running 5.0-RELEASE, not -CURRENT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
