NASM - The Netwide Assembler
NASM Forum => Programming with NASM => Topic started by: horse_river on August 12, 2012, 03:58:45 AM
-
hi:
here is the asm codes:
idt_48:
.word 0 ! idt limit=0
.word 0,0 ! idt base=0L
how the nasm to do for this codes? I think it will allocate three times size of word from consecutive memory to save these three word data.
am I right?
thanls!
-
Yeah, I guess....
idt_48:
dw 0 ; idt limit=0
dw 0, 0 ; idt base=0L
or perhaps,
idt_48:
dw 0
dd 0
(I'm not sure a limit of 0 is useful)
Best,
Frank
-
hi:
I want to know how nasm deal with these code?
thanks!
-
I'm not sure what you mean by "deal with". As you speculate, it's just 6 bytes of contiguous memory - a 16-bit size followed by a 32-bit address. Not much for Nasm to "deal with". If you had a valid interrupt descriptor table, and a valid pointer to it (usually called "idtr" but you can call it "idt_48") you'd use it like:
lidt [idt_48]
This is probably not a good place to start if you're not familiar with Nasm! What are you trying to do?
Best,
Frank
-
oh,yeah,
I think the code I give above is for gun assembly ,which may be not suitable fro nasm
does nasm working for intel assembly code style?
thanks!
-
gun assembly
You mean GNU Assembler (GAS)? That Assembler uses AT&T syntax.
NASM and all the "Other" popular x86 Assemblers use INTEL syntax.
AT&T syntax:
movl $4,%eax
INTEL syntax:
mov eax, 4
-
hi,
In my code,there is a global varible ,after linking , it will be referenced as a linear address or a segment offset ?
actually? my problem is ? I referenced this global varible through linear address : lss 0x805d2c0,%esp
but when my code is loaded into bochs
and disassembly ,I find my code change to : DS:0x805d2c0 ,which is a segment offset.
obviously, this offset is beyond segment limit.
what is the reason?
-
I suspect the "reason" is that Bochs is messin' with ya. I suspect that if you look closely at the opcodes, there's no "ds" prefix (0x3e) there - Bochs is just thowing it into the disassembly. If there is a prefix there, it is redundant - it would default to ds anyway.
On x86, an address is always segment:offset. The default for eip is cs, for %esp and %ebp it's ss, otherwise it's ds. In any modern OS, the segment registers - selectors - reference a descriptor with base of zero and a limit of 4G-1, so segment:offset resolves to just offset.
There's an exception to that. Your first code, where you reference an IDT, I'm not too sure about, but the pointer structure to a GDT or LDT has a 16-bit size and a 32-bit address - this address is a linear address, not segment:offset.
obviously, this offset is beyond segment limit.
Well... maybe. What have you set the segment limit to? If you haven't, it's probably 4G-1. The address, 0x804d2c0 looks like a perfectly plausible address for a Linux data section to me. What have you got located there? It "better" be a 32-bit address to go in %esp followed by a 16-bit selector that points to a valid stack descriptor that you've set up in a global or local descriptor table or you're gonna crash when you execute lss.
I said that 0x805d2c0 sounded like a Linux address, but I have a feeling we're "not in Kansas anymore". Where are we? What are you trying to do?
I can see that your code is in AT&T syntax. Not really on-topic here, but we can try to help you anyway. Some of us know a little AT&T although we might not like it (I don't!). But "code is code" I always say - rather optimistically. :)
Best,
Frank
-
thanks ,Frank?
before this lss instruction , I set the segment's limit to 0x7fff ,which is smaller than 0x805d2c0,so
this cause a crash.
my question is , the code is loaded at linear address which start at 0x80480a0,and so I thinl the 0x805d2c0
should be (0x805d2c0 -0x80480a0 ) , which means a offset from .text section . or it may be a offset from .data section.
am I right?
-
You've got a segment with limit 0x7fff. What's the base? I won't ask why you've used such a small limit - I suppose you have your reasons.
Let's back up a bit. You've got some code for (G)as. Unlike Nasm, Gas won't produce a flat binary, but ld will. How are you linking it? I think a linker script is "usual", but you can do it from the command like, too. Something like:
ld -oformat binary -T.text=0x7c00 myfile.o -o kernel.bin
Obviously that's not exactly correct, but I'm guessing you must be doing "something like that". If you're not telling ld that you want a binary file and where the "origin" is, that's not what you'll get! That would explain the "linux-like" addresses you're getting. If you're using a linker script, can we see it?
You still haven't told us what you're trying to do. If you want to keep it to yourself, that's okay, but expect the help to be skimpy. We'll be able to help you more if we don't have to guess!
Best,
Frank
-
this is linux bootloader's code .and this limit is set for code which runs before main()
-
Read up on the Interrupt Descriptor Table @ OSDev.org Wiki (http://wiki.osdev.org/Interrupt_Descriptor_Table).
-
Ah, right there in setup.S. Sorry, I should have recognized it. I'm not as familiar with the Linux boot process as I probably should be. I fooled around with bootsectors a bit, but once I'd learned to load something else, I realized that I didn't really know what I wanted to load. How is "my OS" going to be better than "their OS"? I kinda lost interest, at that point and mostly just play around in userland.
You asked how Nasm would "deal with" that code. It won't. We could translate it to Nasm syntax. Yasm has an option to accept AT&T syntax. Simplest thing is to just use Gas (and ld - it should be "-Ttext=0x0" but otherwise I was on the right track above). It's a good assembler, despite having a bad reputation in some quarters. :)
Besides the OSDev folks Keith mentions (an excellent resource!), there's documentation on the specific Linux boot process...
/usr/source/linux/Documentation/i386/boot.txt
... written by HPA - Nasm's maintainer - no less! Probably other documentation... Linux Documentation Project?
I just tried "make" from the top directory. Churned away for a while, but I can't figure out where it put setup.o. That address you mention - 0x805d2c0 or whatever - doesn't look right to me. From a quick read, I think we're supposed to be loaded at 0x90000 and change. Dunno if that helps.
Best,
Frank