From: Herbert Kleebauer on
Frank Kotler wrote:

> >> section .data
> >> times 4096 - code_size + 20h - 2 db 0
> >> last_word dw 2Bh
>
> I've been afraid someone's going to ask me what the "+20h" is for. Pure
> fudge! Determined by trial-and-error to put "last_word" where I want it...

After 2 hours testing you tell it! I also don't understand your 2b, my Linux
uses 7b for DS/ES/SS and 73 for CS. But I found out, that also a 32 bit store
of a segment register to memory only accesses 16 bit (in opposite to a store
into a register):

main:
08048074: b8 ffffffff move.l #-1,r0
08048079: 8c d8 move.l s0,r0 ; all 32 bit of r0 are written

0804807b: ba ffffffff move.l #-1,r1
08048080: 66 8c da move.w s0,r1 ; only 16 bit of r0 are written

; move.l #-1,seg ; this will seg fault
08048083: 66 c7 05 08049ffe
0804808a: ffff move.w #-1,seg ; but not this
0804808c: 8c 1d 08049ffe move.l s0,seg ; and also not this (only 16 bit are written)
08048092: 0f 03 1d 08049ffe ldsl.l seg,r3 ; and also not this (only 16 bit are read)

08048099: e8 00000014 bsr.l dump_reg ; display register and stack content

0804809e: b8 08049ffe move.l #seg,r0
080480a3: ba 00000002 move.l #2,r1
080480a8: e8 000000c5 bsr.l dump_mem

080480ad: e8 000001a1 bsr.l exit ; terminate



;--------------------------- uninitialized data ----------------------------

buf: blk.b 4

blk.b 4096 - (@\4096) - 2
seg: blk.b 2

;---------------------------------------------------------------------------



The output:

r0:0000007b ffff007b 00000000 ffffffff r4:00000000 00000000 00000000 bf9e4248
s0: 007b 007b 0000 0000 s6: 0073 007b
pc:0804809e st:00000001 bf9e49b7 00000000 bf9e49c3 bf9e49d6 bf9e49e6 bf9e49fa

08049ffe 7b 00 {
From: Chuck Crayne on
On Mon, 25 Aug 2008 16:25:59 -0400
Frank Kotler <fbkotler(a)verizon.net> wrote:

> I've been afraid someone's going to ask me what the "+20h" is for.
> Pure fudge! Determined by trial-and-error to put "last_word" where I
> want it...

Because of the way I am linking it, I had to change the fudge factor
from "+20h" to "-34h" to put "last_word" at the end of a physical page,
but with that change I got exactly the results I expected -- the 16-bit
read from the "lsl" instruction works correctly, but the 32-bit read
from the "mov" instruction segfaults.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html


From: Rod Pemberton on
"Herbert Kleebauer" <klee(a)unibwm.de> wrote in message
news:48B1B26D.664B6C21(a)unibwm.de...
> It is a real bad idea to to write an assembler
> (or part of it) in assembly language and therefore make it CPU dependent.

Doesn't saying this irritate assembly programmers?

Isn't the perspective of assembly programmers today to eliminate the use of
high level languages? Isn't an assembler in C an anethema?

C is built using assembly. But, it seems that you're saying that assembly
programmers can't create an assembly language independent of the CPU... If
assembly language programmers can't create from assembly the abilities that
a high level language implemented using assembly has - like C, should they
really be programming in assembly? I.e., doesn't this imply their skillset
would be served by a more powerful or more abstracted language created by a
prior generation of programmers who (apparently) were more skilled in
assembly? ;-)

> Because the number of assemblers is already larger than the
> number of assembly programmers, this really doesn't matter.

And, the few who are left seem to use their own syntax... making matters
even worse. ;-)


Rod Pemberton

From: Rod Pemberton on
"Frank Kotler" <fbkotler(a)verizon.net> wrote in message
news:g8v4if$hr6$1(a)aioe.org...
> Well, it doesn't "do" anything, so if it doesn't segfault, it's silent.
> Intended to be stepped through in a debugger, rather than "run",
> really...
....

> To "prove" anything the "mov eax, [last_word]" should be
> changed to ax, or deleted.

This should be discarded too since it does nothing:

nop
mov ebx, -1
mov bx, ds
lsl eax, bx
lsl eax, ebx ; upper 16-bits discarded by instruction

> If it still segfaults on some processor, then
> lsl *is* reading 32 bits like the manual says. Could be true. I'd be
> surprised, but only a little...

Only proves that memory is read as a certain size... nothing about register
usage.


RP

From: Rod Pemberton on
"Herbert Kleebauer" <klee(a)unibwm.de> wrote in message
news:48B33569.5E25FE75(a)unibwm.de...
> 08048092: 0f 03 1d 08049ffe ldsl.l seg,r3 ; and also
not this (only 16 bit are read)

How is one supposed to know that for your assembler "ldsl" means
(apparently) "LoaD Segment Limit", which is "lsl" ("Load Segment Limit") in
Intel syntax when Intel has the similarly named "lds" ("Load DS")?


Rod Pemberton