code trouble...

[Ozguxxx]

I have an interesting problem, in fact this might not be right place to ask this question... When I add a nop or any line in an assembly code, the code works, when I remove this useless line code stops, particularly all registers are set to 0 except esp and segment registers... Anybody had same kind of error? Any ideas? I believe that this is a very generic problem... I am sure that I am not overwriting anything...

[ASHLEY4]

It may be needed for align (alignment).

ASHLEY4.

[Ozguxxx]

Well, I thought so in the first place but why should I need it, I mean are you sure that I need this kind of alignment? This is the first time I am having this kind of error...

[Candy]

I have an interesting problem, in fact this might not be right place to ask this question... When I add a nop or any line in an assembly code, the code works, when I remove this useless line code stops, particularly all registers are set to 0 except esp and segment registers... Anybody had same kind of error? Any ideas? I believe that this is a very generic problem... I am sure that I am not overwriting anything...

[far-fetched answer] It's possible that the code itself is JUST small enough to cram some weird jump in an EB-type call (within 127 bytes), and after adding that byte you just bring it to above that requiring an E9 jump and avoiding the error.
[/far-fetched answer]

Ok, that's near-impossible. Could we have some more information, such as the code, a binary image, info on the test environment, how you found out about those things, hexdumps, more code ?

[Ozguxxx]

sorry for late reply. Well I surely can send the code but its very messy now. To summarize what I am doing, I am using interrupt 50 for system call but problem is that when I add a nop between any line code starts working and if I add another nop, it does an iret and jumps to some unmapped place... It is like that code is pushed one byte and cpu starts reading instructions wrongly??? I am testing under bochs, irq's aer mapped onto 32-39 & 40-48. If I can clean today, the code I can send it. Thanx.

BTW, I could not get your far-fetched answer...

[DennisCGc]

Yes, it looks like the CPU is reading it wrongly.
Maybe you have to change the offset in the IDT of the interrupt's address.
And make sure 32 bit = 32 bit

[Ozguxxx]

I have figured out the problem but I could not solve it, I think it is some above me ??? I hope somebody does have an idea about this:
When I disassemble the object file with objdump, I get the disassembly correctly as:

Code: Select all

 7a5:   e8 56 08 00 00          call   1000 <old_esp+0x30d>
 7aa:   66 bb 5b 00             mov    $0x5b,%bx
 7ae:   66 8e eb                mov    %bx,%gs
 7b1:   65 c6 05 00 80 0b 00    movb   $0x4f,%gs:0xb8000
 7b8:   4f
 7b9:   65 c6 05 01 80 0b 00    movb   $0x7,%gs:0xb8001
 7c0:   07
 7c1:   e9 fb ff ff ff          jmp    7c1 

However when I trace the code with bochs, bochs disassembles the first line as:

Code: Select all

(0) [0x00308000] 004b:00000000 (unk. ctxt): call 0000085b             ; e8560800
00

The problematic part is first line, call 0x1000 : e8 56 08 00 00 both objdump and bochs correctly parse the instruction code but bochs does call to 0x85b rather than 0x1000. Is that problem about me or bochs? BTW, I have checked with some other disassemblers, they also disassemble first line as call 0x1000.

[Candy]

Code: Select all

 7a5:   e8 56 08 00 00          call   1000 <old_esp+0x30d>
 7aa:   66 bb 5b 00             mov    $0x5b,%bx
 7ae:   66 8e eb                mov    %bx,%gs
 7b1:   65 c6 05 00 80 0b 00    movb   $0x4f,%gs:0xb8000
 7b8:   4f
 7b9:   65 c6 05 01 80 0b 00    movb   $0x7,%gs:0xb8001
 7c0:   07
 7c1:   e9 fb ff ff ff          jmp    7c1 

However when I trace the code with bochs, bochs disassembles the first line as:

Code: Select all

(0) [0x00308000] 004b:00000000 (unk. ctxt): call 0000085b             ; e8560800
00

The problematic part is first line, call 0x1000 : e8 56 08 00 00 both objdump and bochs correctly parse the instruction code but bochs does call to 0x85b rather than 0x1000. Is that problem about me or bochs? BTW, I have checked with some other disassemblers, they also disassemble first line as call 0x1000.

The disassemblers assume you load it at the place it should go, that is at 7a5. It's a relative jump, so it jumps to 7a5 + length_of_jump + target = 7a5 + 5 + 856 = 1000 (note, all hex). If you don't do the base, you get 5+856 = 85B, so all are correct, even though they do not agree. You are wrong.

[Ozguxxx]

oh, thanks man I did not realize this relative jump, I wanted an absolute jump that is jump wrt segment base, now I think I fixed it. Also thanks for explanation.