assemby int x80 doesn't do anything

[stdcall]

I'm in user mode, using gdb the debugger just steps over the int instruction.
Interrupts are enabled according to EFLAGS.

any thoughts ?

[stevewoods1986]

Hello.

If this is Linux Assembly, please can I have the code where it doesn't work.

Thanks
Steve.

[iansjack]

What gdb instruction are you using to single-step your code?

[stdcall]

What gdb instruction are you using to single-step your code?

si

[stdcall]

Hello.

If this is Linux Assembly, please can I have the code where it doesn't work.

Thanks
Steve.

This is not a Linux assembly.
It's a flat binary file I jump into once I switch to user mode and execute it.

The code for it:

Code: Select all

   0:	e8 02 00             	call   0x5
   3:	00 00                	add    %al,(%bx,%si)
   5:	eb fe                	jmp    0x5
   7:	55                   	push   %bp
   8:	89 e5                	mov    %sp,%bp
   a:	cd 80                	int    $0x80
   c:	b8 00 00             	mov    $0x0,%ax
   f:	00 00                	add    %al,(%bx,%si)
  11:	5d                   	pop    %bp
  12:	c3                   	ret    
  13:	00 14                	add    %dl,(%si)
  15:	00 00                	add    %al,(%bx,%si)
  17:	00 00                	add    %al,(%bx,%si)
  19:	00 00                	add    %al,(%bx,%si)
  1b:	00 01                	add    %al,(%bx,%di)
  1d:	7a 52                	jp     0x71
  1f:	00 01                	add    %al,(%bx,%di)
  21:	7c 08                	jl     0x2b
  23:	01 1b                	add    %bx,(%bp,%di)
  25:	0c 04                	or     $0x4,%al
  27:	04 88                	add    $0x88,%al
  29:	01 00                	add    %ax,(%bx,%si)
  2b:	00 1c                	add    %bl,(%si)
  2d:	00 00                	add    %al,(%bx,%si)
  2f:	00 1c                	add    %bl,(%si)
  31:	00 00                	add    %al,(%bx,%si)
  33:	00 d3                	add    %dl,%bl
  35:	ff                   	(bad)  
  36:	ff                   	(bad)  
  37:	ff 0c                	decw   (%si)
  39:	00 00                	add    %al,(%bx,%si)
  3b:	00 00                	add    %al,(%bx,%si)
  3d:	41                   	inc    %cx
  3e:	0e                   	push   %cs
  3f:	08 85 02 42          	or     %al,0x4202(%di)
  43:	0d 05 48             	or     $0x4805,%ax
  46:	c5 0c                	lds    (%si),%cx
  48:	04 04                	add    $0x4,%al

[iansjack]

If the code isn't running under Linux, how is it running? (It looks like real mode.) Is there actually an int 0x80 handler?

[xenos]

The code for it:

Code: Select all

00000000 <.data>:

I see a contradiction here.

[iansjack]

BTW, note that the interrupt flag has no connection with a software interrupt.

[stevewoods1986]

BTW, note that the interrupt flag has no connection with a software interrupt.

True, it could be an exception (fault). What platform is he/she using? Int 0x80 is Linux.

[iansjack]

A software interrupt cannot be an exception.

[stdcall]

BTW, note that the interrupt flag has no connection with a software interrupt.

True, it could be an exception (fault). What platform is he/she using? Int 0x80 is Linux.

This is no Linux, this is my OS. there's a dedicated isr 0x80 handler I've written and placed in the IDT. and event if there wasn't I would expect to see a general exception fault.

[stdcall]

The code for it:

Code: Select all

00000000 <.data>:

I see a contradiction here.

That's not a contradiction, the format I use for executable is just plain binrary, there are no sections like in ELF.
so basically to dump the assembly out of the binary I typed:

Code: Select all

objdump -D -b binary -mi386 -Maddr16,data16 ./binary_code 

program:     file format binary

Disassembly of section .data:

00000000 <.data>:
   0:	e8 02 00             	call   0x5
....

So basically, the .data section you think you saw is not really a section at all.

[stdcall]

I found a workaround around this but I don't seem to understand why it didn't work.
I changed the int number to 0x40 instead of 0x80 and now it works perfectly.
I don't get it.

[LtG]

I found a workaround around this but I don't seem to understand why it didn't work.
I changed the int number to 0x40 instead of 0x80 and now it works perfectly.
I don't get it.

You haven't really said anything about the context of your issue.

Are you running Linux, on which you run Qemu, on which you run your own OS, on which you run some test app you compiler that tries to use int 0x80? And you are using gdb from the host Linux to connect to Qemu and single stepping over said int 0x80?

Are you using a recent version of Qemu or something ancient? Did you compile it or use a packaged one? Are you using KVM with Qemu or..?

[stdcall]

I found a workaround around this but I don't seem to understand why it didn't work.
I changed the int number to 0x40 instead of 0x80 and now it works perfectly.
I don't get it.

You haven't really said anything about the context of your issue.

Are you running Linux, on which you run Qemu, on which you run your own OS, on which you run some test app you compiler that tries to use int 0x80? And you are using gdb from the host Linux to connect to Qemu and single stepping over said int 0x80?

Are you using a recent version of Qemu or something ancient? Did you compile it or use a packaged one? Are you using KVM with Qemu or..?

I'm Running Linux, on top of that I run Qemu and I'm connecting to the os using remote GDB protocol and Qemu offers.
The OS bootstraps and then runs a process in user mode. the process is a flat binary that is loaded via grub modules.
It appears that even before switching to user mode, int 0x80 doesn't do anything.
changing the number from 0x80 to something else (0x40) solved the issue, now the interrupt occurs.