> 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 it
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, 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 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 re
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 fla
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'
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-}
-- Ste
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 dur
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
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 in
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
> pr
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
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 woul
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.
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.
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, 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 ker
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 thin
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 sys
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 in
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 u
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
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 [E
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 kern
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 a
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 call
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.
>
> N
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 i
34 matches
Mail list logo
