> zach-dev2:~ $ ldd /bin/ls
> linux-gate.so.1 => (0xe000)
>
> This is the vsyscall entry point, which gets linked by ld into all processes.
Just a clarification... not GNU ld (the binutils thing), but /lib/ld-linux.so
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thu, 11 Aug 2005, Zwane Mwaikambo wrote:
> On Thu, 11 Aug 2005, Steven Rostedt wrote:
> > On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
> > int is a call to either an interrupt or exception procedure. 0x80 is
> > setup in Linux to be a trap and not an interrupt vector. So
On Thu, 2005-08-11 at 22:04 -0700, Jeff Carr wrote:
> [EMAIL PROTECTED]:~# dpkg -s libc6-i686
> ...
OK, this explains it :-)
# dpkg -s libc-i686
Package `libc-i686' is not installed and no info is available.
# dpkg -s libc6
Package: libc6
Status: install ok installed
Priority: required
On Thu, 2005-08-11 at 22:04 -0700, Jeff Carr wrote:
> But are you using libc6-i686? That enables NPTL. Perhaps the behavior
> difference is there? I'm surprised int 80 doesn't really cause an
> interrupt; it doesn't jump to the appropriate place in the x86 vector
> table? Interesting.
int 80
On Thu, 2005-08-11 at 22:04 -0700, Jeff Carr wrote:
But are you using libc6-i686? That enables NPTL. Perhaps the behavior
difference is there? I'm surprised int 80 doesn't really cause an
interrupt; it doesn't jump to the appropriate place in the x86 vector
table? Interesting.
int 80 does
On Thu, 2005-08-11 at 22:04 -0700, Jeff Carr wrote:
[EMAIL PROTECTED]:~# dpkg -s libc6-i686
...
OK, this explains it :-)
# dpkg -s libc-i686
Package `libc-i686' is not installed and no info is available.
# dpkg -s libc6
Package: libc6
Status: install ok installed
Priority: required
Section:
On Thu, 11 Aug 2005, Zwane Mwaikambo wrote:
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
int is a call to either an interrupt or exception procedure. 0x80 is
setup in Linux to be a trap and not an interrupt vector. So it does
zach-dev2:~ $ ldd /bin/ls
linux-gate.so.1 = (0xe000)
This is the vsyscall entry point, which gets linked by ld into all processes.
Just a clarification... not GNU ld (the binutils thing), but /lib/ld-linux.so
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On 8/12/05, Jeff Carr <[EMAIL PROTECTED]> wrote:
> On 08/11/2005 10:18 AM, Steven Rostedt wrote:
>
> > It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own
> > customizations. But I never touched the sysentry stuff and with a few
> > printks I see it is being initialized.
> >
>
On 08/11/2005 10:18 AM, Steven Rostedt wrote:
> It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own
> customizations. But I never touched the sysentry stuff and with a few
> printks I see it is being initialized.
>
>>Also glibc support.
>
> I'm using Debian unstable with a
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:
> > According to my documentation it isn't. A software interrupt is a far call
> > with an extra pushf, and a hardware interrupt is protected against recursion
> > by the PIC, not by an interrupt
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
>
> >
> > I was talking about the one who had the glibc support to use
> > the newer system-call entry (who's name can confuse).
> >
> > You are looking at code that uses int 0x80.
On Thu, 2005-08-11 at 12:58 -0700, Zachary Amsden wrote:
> If you're feeling really masochistic, I've added a demonstration of how
> you can call sysenter from userspace without glibc.
Thanks Zach, this will give me something to play around with when I have
a little more spare time >8-}
--
Steven Rostedt wrote:
OK, I get the same on my machine.
On a machine that does not support sysenter, this will give you:
int $0x80
ret
The int $0x80 system calls are still fully supported by a sysenter
capable kernel, since it must run older binaries and potentially support
syscalls
On Thu, 2005-08-11 at 14:21 -0400, linux-os (Dick Johnson) wrote:
> I'm not sure you can stop the CPU from clearing the interrupt
> bit in EFLAGS if you execute an interrupt. The interrupt handler
> may be supported by a trap-gate, but the event has already
> occurred. The documentation I have
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
>
>>
>> I was talking about the one who had the glibc support to use
>> the newer system-call entry (who's name can confuse).
>>
>> You are looking at code that uses int 0x80. It's an
On Thu, 2005-08-11 at 10:59 -0700, Zachary Amsden wrote:
>
> zach-dev2:~ $ ldd /bin/ls
> linux-gate.so.1 => (0xe000)
OHHH! So THAT is what linux-gate is used for! Thanks, I've been really
confused by that.
>
> This is the vsyscall entry point, which gets linked by ld into all
>
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
>
> I was talking about the one who had the glibc support to use
> the newer system-call entry (who's name can confuse).
>
> You are looking at code that uses int 0x80. It's an interrupt,
> therefore, in the kernel, once the
Steven Rostedt wrote:
I expect that if I had a Gentoo system that I compiled for my machine,
this would be different. But I suspect that Debian still wants to run on
my old Pentium 75MHz laptop. How would libc know to use sysenter
instead of int 0x80. It could do a test of the system, but
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 13:26 -0400, Steven Rostedt wrote:
>
>> 288fb seems to use "int 0x80" and so do all the other system calls that
>> I inspected.
>
> I expect that if I had a Gentoo system that I compiled for my machine,
> this would be
On Thu, 11 Aug 2005, Steven Rostedt wrote:
> On Thu, 2005-08-11 at 13:10 -0400, linux-os (Dick Johnson) wrote:
>> On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
>
>>>
>>> Also glibc support.
>>>
>>> --
>>> Coywolf Qi Hunt
>>> http://ahbl.org/~coywolf/
>>
>> Probably doesn't use int 0x80 at
On Thu, 2005-08-11 at 13:26 -0400, Steven Rostedt wrote:
> 288fb seems to use "int 0x80" and so do all the other system calls that
> I inspected.
I expect that if I had a Gentoo system that I compiled for my machine,
this would be different. But I suspect that Debian still wants to run on
my
On Thu, 2005-08-11 at 13:10 -0400, linux-os (Dick Johnson) wrote:
> On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
> >>
> >
> > Also glibc support.
> >
> > --
> > Coywolf Qi Hunt
> > http://ahbl.org/~coywolf/
>
> Probably doesn't use int 0x80 at all.
$ objdump -Dhalpr /lib/libc.so.6 | egrep 'int
On Fri, 2005-08-12 at 00:59 +0800, Coywolf Qi Hunt wrote:
> On 8/12/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote:
> > On 8/12/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >
> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> > The cpu does have sep. Is it vanilla
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
> On 8/12/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote:
>> On 8/12/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>>> On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
And booted it. The system is up and running, so I really don't
On 8/12/05, Coywolf Qi Hunt <[EMAIL PROTECTED]> wrote:
> On 8/12/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> > On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
> > >
> > > And booted it. The system is up and running, so I really don't think
> > > that the sysenter_entry is used for
On 8/12/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
> >
> > And booted it. The system is up and running, so I really don't think
> > that the sysenter_entry is used for system calls.
> >
> > Not so "Clear as day"!
>
> And so, looking
On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
>
> And booted it. The system is up and running, so I really don't think
> that the sysenter_entry is used for system calls.
>
> Not so "Clear as day"!
And so, looking into sysenter_entry, it seems that my configurations
don't seem to
Ukil a wrote:
I had this question. As per my understanding, in the
Linux system call implementation on x86 architecture
the call flows like this int 0x80 -> syscall ->
sys_call_vector(taken from the table)-> return from
interrupt service routine.
Almost. There are two entry points, the
On Thu, 2005-08-11 at 11:28 -0400, linux-os (Dick Johnson) wrote:
> On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
>
> > On 8/11/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> >> On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
> >>> Every interrupt software, or hardware, results
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
> On 8/11/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>> On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
>>> Every interrupt software, or hardware, results in the branched
>>> procedure being executed with the interrupts OFF. That's
On Thu, 2005-08-11 at 23:13 +0800, Coywolf Qi Hunt wrote:
>
> He is RBJ, Richard B. Johnson, the LKML defacto official troll.
>
Oh, so this is "root" who almost got DaveJ fired? :)
-- Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 8/11/05, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
> > Every interrupt software, or hardware, results in the branched
> > procedure being executed with the interrupts OFF. That's why
> > one of the first instructions in the
On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
> Every interrupt software, or hardware, results in the branched
> procedure being executed with the interrupts OFF. That's why
> one of the first instructions in the kernel entry for a syscall
> is 'sti' to turn them back on. Look
On Thu, 11 Aug 2005, Bodo Eggert wrote:
> Ukil a <[EMAIL PROTECTED]> wrote:
>
>> Now I had the doubt that if the the syscall
>> implementation is very large will the scheduling and
>> other interrupts be blocked for the whole time till
>> the process returns from the ISR (because in an ISR by
>>
On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:
> According to my documentation it isn't. A software interrupt is a far call
> with an extra pushf, and a hardware interrupt is protected against recursion
> by the PIC, not by an interrupt flag.
I disagree with your definition of a system
On Wed, 2005-08-10 at 22:39 -0700, Ukil a wrote:
> I had this question. As per my understanding, in the
> Linux system call implementation on x86 architecture
> the call flows like this int 0x80 -> syscall ->
> sys_call_vector(taken from the table)-> return from
> interrupt service routine.
>
>
Ukil a <[EMAIL PROTECTED]> wrote:
> Now I had the doubt that if the the syscall
> implementation is very large will the scheduling and
> other interrupts be blocked for the whole time till
> the process returns from the ISR (because in an ISR by
> default the interrupts are disabled unless sti
Ukil a [EMAIL PROTECTED] wrote:
Now I had the doubt that if the the syscall
implementation is very large will the scheduling and
other interrupts be blocked for the whole time till
the process returns from the ISR (because in an ISR by
default the interrupts are disabled unless sti is
On Wed, 2005-08-10 at 22:39 -0700, Ukil a wrote:
I had this question. As per my understanding, in the
Linux system call implementation on x86 architecture
the call flows like this int 0x80 - syscall -
sys_call_vector(taken from the table)- return from
interrupt service routine.
Now I had
On Thu, 11 Aug 2005, Bodo Eggert wrote:
Ukil a [EMAIL PROTECTED] wrote:
Now I had the doubt that if the the syscall
implementation is very large will the scheduling and
other interrupts be blocked for the whole time till
the process returns from the ISR (because in an ISR by
default the
On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:
According to my documentation it isn't. A software interrupt is a far call
with an extra pushf, and a hardware interrupt is protected against recursion
by the PIC, not by an interrupt flag.
I disagree with your definition of a system call.
On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
Every interrupt software, or hardware, results in the branched
procedure being executed with the interrupts OFF. That's why
one of the first instructions in the kernel entry for a syscall
is 'sti' to turn them back on. Look at
On 8/11/05, Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
Every interrupt software, or hardware, results in the branched
procedure being executed with the interrupts OFF. That's why
one of the first instructions in the kernel entry
On Thu, 2005-08-11 at 23:13 +0800, Coywolf Qi Hunt wrote:
He is RBJ, Richard B. Johnson, the LKML defacto official troll.
Oh, so this is root who almost got DaveJ fired? :)
-- Steve
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
On 8/11/05, Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
Every interrupt software, or hardware, results in the branched
procedure being executed with the interrupts OFF. That's why
one
Ukil a wrote:
I had this question. As per my understanding, in the
Linux system call implementation on x86 architecture
the call flows like this int 0x80 - syscall -
sys_call_vector(taken from the table)- return from
interrupt service routine.
Almost. There are two entry points, the one
On Thu, 2005-08-11 at 11:28 -0400, linux-os (Dick Johnson) wrote:
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
On 8/11/05, Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 2005-08-11 at 10:04 -0400, linux-os (Dick Johnson) wrote:
Every interrupt software, or hardware, results in the
On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
And booted it. The system is up and running, so I really don't think
that the sysenter_entry is used for system calls.
Not so Clear as day!
And so, looking into sysenter_entry, it seems that my configurations
don't seem to use it.
On 8/12/05, Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
And booted it. The system is up and running, so I really don't think
that the sysenter_entry is used for system calls.
Not so Clear as day!
And so, looking into
On 8/12/05, Coywolf Qi Hunt [EMAIL PROTECTED] wrote:
On 8/12/05, Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
And booted it. The system is up and running, so I really don't think
that the sysenter_entry is used for system calls.
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
On 8/12/05, Coywolf Qi Hunt [EMAIL PROTECTED] wrote:
On 8/12/05, Steven Rostedt [EMAIL PROTECTED] wrote:
On Thu, 2005-08-11 at 11:51 -0400, Steven Rostedt wrote:
And booted it. The system is up and running, so I really don't think
that the
On Fri, 2005-08-12 at 00:59 +0800, Coywolf Qi Hunt wrote:
On 8/12/05, Coywolf Qi Hunt [EMAIL PROTECTED] wrote:
On 8/12/05, Steven Rostedt [EMAIL PROTECTED] wrote:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
The cpu does have sep. Is it vanilla kernel?
It's
On Thu, 2005-08-11 at 13:10 -0400, linux-os (Dick Johnson) wrote:
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
Also glibc support.
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
Probably doesn't use int 0x80 at all.
$ objdump -Dhalpr /lib/libc.so.6 | egrep 'int *\$0x80' | wc
On Thu, 2005-08-11 at 13:26 -0400, Steven Rostedt wrote:
288fb seems to use int 0x80 and so do all the other system calls that
I inspected.
I expect that if I had a Gentoo system that I compiled for my machine,
this would be different. But I suspect that Debian still wants to run on
my old
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:10 -0400, linux-os (Dick Johnson) wrote:
On Thu, 11 Aug 2005, Coywolf Qi Hunt wrote:
Also glibc support.
--
Coywolf Qi Hunt
http://ahbl.org/~coywolf/
Probably doesn't use int 0x80 at all.
$ objdump -Dhalpr
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:26 -0400, Steven Rostedt wrote:
288fb seems to use int 0x80 and so do all the other system calls that
I inspected.
I expect that if I had a Gentoo system that I compiled for my machine,
this would be different. But I
Steven Rostedt wrote:
I expect that if I had a Gentoo system that I compiled for my machine,
this would be different. But I suspect that Debian still wants to run on
my old Pentium 75MHz laptop. How would libc know to use sysenter
instead of int 0x80. It could do a test of the system, but
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
I was talking about the one who had the glibc support to use
the newer system-call entry (who's name can confuse).
You are looking at code that uses int 0x80. It's an interrupt,
therefore, in the kernel, once the stack is
On Thu, 2005-08-11 at 10:59 -0700, Zachary Amsden wrote:
zach-dev2:~ $ ldd /bin/ls
linux-gate.so.1 = (0xe000)
OHHH! So THAT is what linux-gate is used for! Thanks, I've been really
confused by that.
This is the vsyscall entry point, which gets linked by ld into all
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
I was talking about the one who had the glibc support to use
the newer system-call entry (who's name can confuse).
You are looking at code that uses int 0x80. It's an interrupt,
On Thu, 2005-08-11 at 14:21 -0400, linux-os (Dick Johnson) wrote:
I'm not sure you can stop the CPU from clearing the interrupt
bit in EFLAGS if you execute an interrupt. The interrupt handler
may be supported by a trap-gate, but the event has already
occurred. The documentation I have isn't
Steven Rostedt wrote:
OK, I get the same on my machine.
On a machine that does not support sysenter, this will give you:
int $0x80
ret
The int $0x80 system calls are still fully supported by a sysenter
capable kernel, since it must run older binaries and potentially support
syscalls
On Thu, 2005-08-11 at 12:58 -0700, Zachary Amsden wrote:
If you're feeling really masochistic, I've added a demonstration of how
you can call sysenter from userspace without glibc.
Thanks Zach, this will give me something to play around with when I have
a little more spare time 8-}
-- Steve
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 13:46 -0400, linux-os (Dick Johnson) wrote:
I was talking about the one who had the glibc support to use
the newer system-call entry (who's name can confuse).
You are looking at code that uses int 0x80. It's an
On Thu, 11 Aug 2005, Steven Rostedt wrote:
On Thu, 2005-08-11 at 15:41 +0200, Bodo Eggert wrote:
According to my documentation it isn't. A software interrupt is a far call
with an extra pushf, and a hardware interrupt is protected against recursion
by the PIC, not by an interrupt flag.
On 08/11/2005 10:18 AM, Steven Rostedt wrote:
It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own
customizations. But I never touched the sysentry stuff and with a few
printks I see it is being initialized.
Also glibc support.
I'm using Debian unstable with a recent
On 8/12/05, Jeff Carr [EMAIL PROTECTED] wrote:
On 08/11/2005 10:18 AM, Steven Rostedt wrote:
It's vanilla 2.6.12-rc3 + Ingo's RT V0.7.46-02-rs-0.4 + some of my own
customizations. But I never touched the sysentry stuff and with a few
printks I see it is being initialized.
Also glibc
I had this question. As per my understanding, in the
Linux system call implementation on x86 architecture
the call flows like this int 0x80 -> syscall ->
sys_call_vector(taken from the table)-> return from
interrupt service routine.
Now I had the doubt that if the the syscall
implementation is
I had this question. As per my understanding, in the
Linux system call implementation on x86 architecture
the call flows like this int 0x80 - syscall -
sys_call_vector(taken from the table)- return from
interrupt service routine.
Now I had the doubt that if the the syscall
implementation is very
70 matches
Mail list logo
