int 0x40

int 0x40

[Raman S]

Hi,
  I relatively new to the kernel and am trying to understand how the linux 
kernel handles interrupts. For this I attempted to
create an int 0x40 by adding a set_system_gate(64, &system_call) in traps.c. 
I verfied by giving out print statements within set_system_gate that 64 is 
being set during initialization (though it isnt a surprise that it is being 
set).  But when i give an int 0x40 in a user level assembly program I get 
segmentation fault, (a SIGSEGV signal is sent to the process).  I have tried 
adding another function in entry.S called my_system_call and reproducing the 
code in system_call with a jmp ret_from_sys_call  at the end. Also tried 
giving an empty C function for my_system_call all with the same result.

My assembly prints out hello world, from the linux assembly how to, 
reproduced here
If i replace int 0x80 with my int 0x40 I end up with a segmentation fault. 
Is there any thing other than set_system_gate and writing the my_system_call 
handler, that i need to do to have a successful int 0x40? I had tried
   a) commenting out just the deference of the system handler function 
within system_call (call *sys_call_table(0, %eax, 4) )
   b) using &system_call itself in set_system_gate
  but still the same situation.

Any suggestions will be appreciated.

Thanks
Raman


.data					# section declaration

msg:
	.string	"Hello, world!\n"	# our dear string
	len = . - msg			# length of our dear string

.text					# section declaration

			# we must export the entry point to the ELF linker or
    .global _start	# loader. They conventionally recognize _start as their
			# entry point. Use ld -e foo to override the default.

_start:

# write our string to stdout

	movl	$len,%edx	# third argument: message length
	movl	$msg,%ecx	# second argument: pointer to message to write
	movl	$1,%ebx		# first argument: file handle (stdout)
	movl	$4,%eax		# system call number (sys_write)
	int	$0x80		# call kernel

# and exit

	movl	$0,%ebx		# first argument: exit code
	movl	$1,%eax		# system call number (sys_exit)
	int	$0x80		# call kernel




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

Re: int 0x40

[Richard B. Johnson]

On Fri, 18 Jan 2002, Raman S wrote:

> Hi,
>   I relatively new to the kernel and am trying to understand how the linux 
> kernel handles interrupts. For this I attempted to
> create an int 0x40 by adding a set_system_gate(64, &system_call) in traps.c. 
> I verfied by giving out print statements within set_system_gate that 64 is 
> being set during initialization (though it isnt a surprise that it is being 
> set).  But when i give an int 0x40 in a user level assembly program I get 
> segmentation fault, (a SIGSEGV signal is sent to the process).  I have tried 
> adding another function in entry.S called my_system_call and reproducing the 
> code in system_call with a jmp ret_from_sys_call  at the end. Also tried 
> giving an empty C function for my_system_call all with the same result.
> 

As you no-doubt know, any 'int' instruction from user-world is
invalid and will cause a trap. So, you can make a trap-handler
and have it do something useful. To have the trap handler get
control, rather than the illegal-instruction trap, you need an
entry in the IDT (interrupt descriptor table). I don't know
which system procedure (if any) will make this entry for you.
You can see how the initial interrupt(s) are set up, make an
entry and then remember to `lidt` load the new IDT.

> My assembly prints out hello world, from the linux assembly how to, 
> reproduced here
> If i replace int 0x80 with my int 0x40 I end up with a segmentation fault. 
> Is there any thing other than set_system_gate and writing the my_system_call 
> handler, that i need to do to have a successful int 0x40? I had tried
>    a) commenting out just the deference of the system handler function 
> within system_call (call *sys_call_table(0, %eax, 4) )
>    b) using &system_call itself in set_system_gate
>   but still the same situation.
> 
> Any suggestions will be appreciated.
> 
> Thanks
> Raman
> 

[SNIPPED assembly...]

In principle, one should be able to nest software interrupts, DOS
did it all the time. However, I fear that executing interrupt 0x80
from within interrupt 0x40 may be interpreted by other kernel code
as "bad". You might get a "Eieee scheduling in an interrupt!" panic.

I would suggest that you execute the sys-calls directly, not through
int 0x80, within your code. This will prevent this problem. It is
also faster. Since a user-mode interrupt is really just a 'call',
'current' should still be valid for I/O.

The kernel was not designed for user-mode software interrupts so you
might find other problems. My question is why you would actually want
one? If you need another function, just add it. If you need something
else, make a module.

Note that a hardware interrupt will never execute a user-mode
interrupt service routine unless you make a kernel-mode ISR that
somehow calls a user-mode routine....and, although that's possible
by using some clever tricks, it's kinda dumb.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: int 0x40

[Brian Gerst]

Raman S wrote:
> 
> Hi,
>   I relatively new to the kernel and am trying to understand how the linux
> kernel handles interrupts. For this I attempted to
> create an int 0x40 by adding a set_system_gate(64, &system_call) in traps.c.
> I verfied by giving out print statements within set_system_gate that 64 is
> being set during initialization (though it isnt a surprise that it is being
> set).  But when i give an int 0x40 in a user level assembly program I get
> segmentation fault, (a SIGSEGV signal is sent to the process).  I have tried
> adding another function in entry.S called my_system_call and reproducing the
> code in system_call with a jmp ret_from_sys_call  at the end. Also tried
> giving an empty C function for my_system_call all with the same result.

The IRQ setup code is probably overwriting it.  You'll need to make the
code in i8259.c skip over vector 0x40 as well as SYSCALL_VECTOR (0x80).

--

				Brian Gerst

Re: int 0x40

[Richard B. Johnson]

On Fri, 18 Jan 2002, Brian Gerst wrote:

> Raman S wrote:
> > 
> > Hi,
> >   I relatively new to the kernel and am trying to understand how the linux
> > kernel handles interrupts. For this I attempted to

[SNIPPED...]
> 
> The IRQ setup code is probably overwriting it.  You'll need to make the
> code in i8259.c skip over vector 0x40 as well as SYSCALL_VECTOR (0x80).
> 
> --
> 
> 				Brian Gerst

Yes. It looks like this is what is happening.

Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: int 0x40

[Raman S]

Yes, That was it, Thanks so much.....
Raman S
>The IRQ setup code is probably overwriting it.  You'll need to make the
>code in i8259.c skip over vector 0x40 as well as SYSCALL_VECTOR (0x80).
>
>--
>
>				Brian Gerst




_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com