gdtr value

gdtr value

[horseriver]

hi:)

  The gdtr reg saves the base address of gdt , whether is this address a linear address or phisical address ?

thanks!

gdtr value

[horseriver]

hi:)

  The gdtr reg saves the base address of gdt , whether is this address a linear address or phisical address ?

thanks!

gdtr value

[Anuz Pratap Singh Tomar]

On Mon, Feb 18, 2013 at 1:55 AM, horseriver <horserivers@gmail.com> wrote:

> hi:)
>
>   The gdtr reg saves the base address of gdt , whether is this address a
> linear address or phisical address ?
>
According to
Intel? 64 and IA-32 Architectures
Software Developer?s Manual
Volume 3B:
System Programming Guide, Part 2

for 64 bit machines:

On processors that support Intel 64 architecture, the base-address fields
for FS,
GS, GDTR, IDTR, and TR must contain canonical addresses.
Look for definition of canonical addresses here:
http://en.wikipedia.org/wiki/X86-64


According to this book all addresses in GDTR, LDTR and IDTR are linear
addresses
http://books.google.co.uk/books?id=l8QPUGuElFwC&pg=SA7-PA15&lpg=SA7-PA15&dq=GDTR+32+bit&source=bl&ots=4rS-pTNmaE&sig=CasnhDIFc9pVr0fsAlNqAod-xFc&hl=en&sa=X&ei=vRoiUZXDAojK0QXf8IHYBA&ved=0CEgQ6AEwBQ#v=onepage&q=GDTR%2032%20bit&f=false

Intel? 64 and IA-32 Architectures
Software Developer?s Manual
Volume 3A:
System Programming Guide, Part 1
page 65

The linear address of the base of the GDT is contained in the GDT register
(GDTR);
the linear address of the LDT is contained in the LDT register (LDTR).


However for 32 bit registers, this document provides some details in
protected mode:

http://home.swipnet.se/smaffy/asm/info/PMODEDetailedApproach.txt



> thanks!
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
Thank you
Warm Regards
Anuz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130218/aa28b0df/attachment.html 

gdtr value

[horseriver]

hi:)

  I have compiled a .S file ,using command gcc -c x.S -o x.
  Then I use objdump to look up its asm code, even find that some code is not the
  same as that .S file , more important is , some code in origin  .S file has disappear .

  what is about the reason ? If it is due to version , why some code chould get lost after compile?


thanks!

gdtr value

[Anuz Pratap Singh Tomar]

On Mon, Feb 18, 2013 at 5:07 AM, horseriver <horserivers@gmail.com> wrote:

> hi:)
>
>   I have compiled a .S file ,using command gcc -c x.S -o x.
>   Then I use objdump to look up its asm code, even find that some code is
> not the
>   same as that .S file , more important is , some code in origin  .S file
> has disappear .
>
>   what is about the reason ? If it is due to version , why some code
> chould get lost after compile?
>
> Couple of things
1. Please don't piggy back questions over the unrelated topic, that is
totally misdirecting the discussion.
2. You ask a lot of question related to compilation and stuff, which are
off-topic here, why not READ a little bit more or consult relevant
documentation?
3. You seem to do no homework before asking viz googling or reading basic
books on relevant topic for example in this case reading a book on assembly
language programming.

When you write any assembly code(or for that matter any code) your code is
written to be read by HUMANS and not machines. For machines a lot of that
code is redundant and has no use so machine code will be generated in such
a form that it is most optimized for the execution. For example take any
*.c code and do

#gcc -S *.c
you will see an equivalent assembly code. It may not exactly be similar to
the code which you will write in assembly for same logic. There are some
rules according to which compilers generate code, please read some book on
compilers and lex and yacc.




> thanks!
>



-- 
Thank you
Warm Regards
Anuz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130218/24a7645d/attachment-0001.html 

gdtr value

[Anuz Pratap Singh Tomar]

On Mon, Feb 18, 2013 at 3:05 PM, Anuz Pratap Singh Tomar <
chambilkethakur@gmail.com> wrote:

>
>
> On Mon, Feb 18, 2013 at 5:07 AM, horseriver <horserivers@gmail.com> wrote:
>
>> hi:)
>>
>>   I have compiled a .S file ,using command gcc -c x.S -o x.
>>   Then I use objdump to look up its asm code, even find that some code is
>> not the
>>   same as that .S file , more important is , some code in origin  .S file
>> has disappear .
>>
>>   what is about the reason ? If it is due to version , why some code
>> chould get lost after compile?
>>
>> Couple of things
> 1. Please don't piggy back questions over the unrelated topic, that is
> totally misdirecting the discussion.
> 2. You ask a lot of question related to compilation and stuff, which are
> off-topic here, why not READ a little bit more or consult relevant
> documentation?
> 3. You seem to do no homework before asking viz googling or reading basic
> books on relevant topic for example in this case reading a book on assembly
> language programming.
>
> When you write any assembly code(or for that matter any code) your code is
> written to be read by HUMANS and not machines. For machines a lot of that
> code is redundant and has no use so machine code will be generated in such
> a form that it is most optimized for the execution. For example take any
> *.c code and do
>
> #gcc -S *.c
> you will see an equivalent assembly code. It may not exactly be similar to
> the code which you will write in assembly for same logic. There are some
> rules according to which compilers generate code, please read some book on
> compilers and lex and yacc.
>
>
> Some more info about objdump and assembly code  and why they are
different.
http://stackoverflow.com/questions/4309771/disassembling-modifying-and-then-reassembling-a-linux-executable
And bit of correction:
s/it is most optimized for the execution/it is optimized for compilation if
there are no optimization flags used/


>
>> thanks!
>>
>
>
>
> --
> Thank you
> Warm Regards
> Anuz
>



-- 
Thank you
Warm Regards
Anuz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130218/77e62717/attachment.html 

gdtr value

[Anuz Pratap Singh Tomar]

On Tue, Feb 19, 2013 at 10:18 PM, horseriver <horserivers@gmail.com> wrote:

> On Mon, Feb 18, 2013 at 12:25:43PM +0000, Anuz Pratap Singh Tomar wrote:
> > On Mon, Feb 18, 2013 at 1:55 AM, horseriver <horserivers@gmail.com>
> wrote:
> >
>
> > Intel? 64 and IA-32 Architectures
> > Software Developer?s Manual
> > Volume 3A:
> > System Programming Guide, Part 1
> > page 65
> >
> > The linear address of the base of the GDT is contained in the GDT
> register
> > (GDTR);
> > the linear address of the LDT is contained in the LDT register (LDTR).
> >
>
>    Thanks!
>
>    As the value is a linear address , so when  load an segment descriptor
> from an address ,
>    such as lss ubstruction: lss 0x10023,%esp , cpu will check to make sure
>  this stack descriptor
>    exist in gdt .
>    So , we will get a linear address by the gdtr value and the
> descriptor's index , then  *if this linear address*
>    has not phisical page mapped , it will cause a pagefault trap.then ,how
> to resolve this trap?
>
>
> Please use reply all or add kernelnewbies to CC
I am not very sure of how this trap will be resolved, but you can have a
look at this:
Understanding Linux Kernel
Section 9.4

 http://www.makelinux.net/books/ulk3/understandlk-CHP-9-SECT-4

>
> >
> > However for 32 bit registers, this document provides some details in
> > protected mode:
> >
> > http://home.swipnet.se/smaffy/asm/info/PMODEDetailedApproach.txt
> >
> >
> >
> > > thanks!
> > >
> > > _______________________________________________
> > > Kernelnewbies mailing list
> > > Kernelnewbies at kernelnewbies.org
> > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
> > >
> >
> >
> >
> > --
> > Thank you
> > Warm Regards
> > Anuz
>



-- 
Thank you
Warm Regards
Anuz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130220/27038972/attachment.html