Prev: announce: my very first disassembler now available (GPL)
Next: Win32 non blocking console input?
From: Herbert Kleebauer on 25 Aug 2008 18:42 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 25 Aug 2008 19:00 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 25 Aug 2008 19:30 "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 25 Aug 2008 19:58 "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 25 Aug 2008 19:58
"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 |