Author Topic: base knowledge  (Read 19461 times)

Offline horse_river

  • Jr. Member
  • *
  • Posts: 9
base knowledge
« 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!

 

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: base knowledge
« Reply #1 on: August 12, 2012, 05:27:40 AM »
Yeah, I guess....
Code: [Select]
idt_48:
dw 0       ; idt limit=0
dw 0, 0   ; idt base=0L
or perhaps,
Code: [Select]
idt_48:
dw 0
dd 0
(I'm not sure a limit of 0 is useful)

Best,
Frank


Offline horse_river

  • Jr. Member
  • *
  • Posts: 9
Re: base knowledge
« Reply #2 on: August 12, 2012, 12:45:42 PM »
hi:
     I  want to  know  how nasm  deal  with  these code?

thanks!

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: base knowledge
« Reply #3 on: August 12, 2012, 01:53:56 PM »
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:
Code: [Select]
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


Offline horse_river

  • Jr. Member
  • *
  • Posts: 9
Re: base knowledge
« Reply #4 on: August 13, 2012, 12:40:52 AM »
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! 

Offline Gunner

  • Jr. Member
  • *
  • Posts: 74
  • Country: us
    • Gunners Software
Re: base knowledge
« Reply #5 on: August 13, 2012, 12:51:45 AM »
Quote
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:
Code: [Select]
movl    $4,%eax
INTEL syntax:
Code: [Select]
mov     eax, 4

Offline horse_river

  • Jr. Member
  • *
  • Posts: 9
Re: base knowledge
« Reply #6 on: August 14, 2012, 12:09:20 AM »
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?

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: base knowledge
« Reply #7 on: August 14, 2012, 03:33:47 AM »
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.

Quote
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


Offline horse_river

  • Jr. Member
  • *
  • Posts: 9
Re: base knowledge
« Reply #8 on: August 14, 2012, 08:49:41 AM »
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?


Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: base knowledge
« Reply #9 on: August 14, 2012, 07:36:49 PM »
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:
Code: [Select]
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


Offline horse_river

  • Jr. Member
  • *
  • Posts: 9
Re: base knowledge
« Reply #10 on: August 15, 2012, 10:21:10 AM »
this is  linux  bootloader's code  .and  this  limit  is  set  for code  which  runs  before  main()

Offline Keith Kanios

  • Full Member
  • **
  • Posts: 383
  • Country: us
    • Personal Homepage
Re: base knowledge
« Reply #11 on: August 15, 2012, 10:30:48 AM »

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: base knowledge
« Reply #12 on: August 15, 2012, 02:28:30 PM »
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