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.
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.
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
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.
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