Somewhere in a source I wrote MOV DX,[BP+2], preceded by MOV BP,SP. At runtime, I get Segmentation fault, and it is just when executing said instruction. I tried to define a stack section, thus:

.SECTION JOHN aw [aw sorrounded by doubl quotes]

but don't know the directive to reserve space. What do you think about the segentation fault? [BP+2] is an implicit reference to the stack segment, that is, the instruction is equivalent to MOV DX,SS:[BP+2], that is, the OS seems to complain I'm directly accessing the stack segment.

You are using 16 bit addressing. I assume your program is running in 32 bit (or even 64 bit) mode.

I believe the x86 instruction set has the right overrides to actually use 16 bit addressing in 32 bit mode. But that means you are addressing memory that is not likely to be mapped and so it should seg fault.

Or maybe, you have the assembler in a strange mode so it assembles code for 16 bit mode. So you may be executing in 32-bit mode machine language that as assembled from asm only for 16-bit mode. Again, a seg fault would not be a surprising result.

I can't send the assembler listing here, but it clearly uses prefixes in this way (I say this Reading the listing): It prefixes my instructions, with don't use extended registers, with 0x66. It sure means the D flag, in the processor is low, at runtime, and so the following holds: Oper.size prefix 66H = yes, and adrs size prefix 67H =high mean effective oper.size = 32, effective adrs size = 16. This from the Intel manuals for family 6.

I think it would be convenient to have the mnemonics to specify either of the two prefixes.

EDIT: I attach the listing.

Attached Files

f02.txt (2.7 KB, 21 views)

stack grows from the top of virtual memory downwards
so in 32bit mode it is far above 66h

If only you could tell me how to set gdb to show the registers each time it halts would be a great thing. Among them, sp would be seen to decrement by either two, four or eight with each push.

1 members found this post helpful.

Thanks.

This mixture of 16- and 32-bit code is bound to fail. If you are absolutely sure you cannot write this in C then use 32-bit Assembly everywhere.

Why would you expect what you did to NOT seg fault??

Why would you expect the 16-bit sp register to contain a valid address?

You have pretty much confirmed that your 16-bit asm code was assembled with as believing it would run in 32-bit mode.

You can use 16-bit operands and even 16-bit addresses in 32-bit mode. But any 16-bit address you use must point to a valid 32-bit location or it will seg fault.

You don't seem to have done anything to cause the address that sp points at to be valid within your process's address space.

i'm attaching a modified source which has been fully debugged. You could have begun by telling I'd should use ESP and EBP instead of sp and bp. That was all the problema.

yes, sp is the bottom 16 bits of esp

https://www.tortall.net/projects/yas...registers.html

note that mov ax, bx keeps the upper 16 bits of eax intact,
while mov eax, ebx clears the upper 32 bits of rax

It was hard to guess what you were trying to do.

You could have given a bit more overview and/or context for what you were doing.

aLL right. But now I'm told that by poping the first three ítems from the stack at program initializaiton I get the first invocation argument. I did that and then initialized sp as before. However, now I get segmentation fault. Where is the fetching of the program name, argumentes and its count well documented?

http://asm.sourceforge.net/articles/startup.html
http://www.tldp.org/LDP/LGNET/issue84/hawk.html
etc.

"When all else fails, read the source"

1 members found this post helpful.

Here's the finished program. It must be invoked as

f11_elf <four-digit hex uppercase number>

The number should be less than 8 and the result will be printed in hex. Example: f11_elf 0005.

Attached Files

	F11_ELF.TXT (2.3 KB, 8 views)
	F11_SOURCE.TXT (2.4 KB, 15 views)