headers
David Laight | 3 Nov 2007 12:28
Picon

syscall() system call stub

The amd64 stub for syscall() is:

ENTRY(syscall)
	movl	%edi,%eax
	syscall

(from libc/arch/x86_64/sys/syscall.S)

This looks completely wrong to me.
I think it needs to be:
	mov	$0,%eax
	mov	%rcx,%r10
	syscall

probably generated by RSYSCALL(syscall)

I actually suspect there are no actual calls to it in the amd64 userspace.

Which is rather fortunate since there are calls lurking like:
	syscall(SYS___syscall, SYS_foo, args)
which really isn't going to DTRT unless syscall() is implemented in
the library - which it cannot be for some architectures like amd64 (& sparc)
where some, but not all, of the system call arguments are passed in registers.

	David

--

-- 
David Laight: david <at> l8s.co.uk
(Continue reading)

Permalink | Reply | 4 comments |
headers
Andrew Doran | 4 Nov 2007 03:28
Picon

Re: syscall() system call stub

Hi,

On Sat, Nov 03, 2007 at 11:28:11AM +0000, David Laight wrote:

> The amd64 stub for syscall() is:
> 
> ENTRY(syscall)
> 	movl	%edi,%eax
> 	syscall
> 
> (from libc/arch/x86_64/sys/syscall.S)
> 
> This looks completely wrong to me.
> I think it needs to be:
> 	mov	$0,%eax
> 	mov	%rcx,%r10
> 	syscall
> 
> probably generated by RSYSCALL(syscall)
> 
> I actually suspect there are no actual calls to it in the amd64 userspace.
> 
> Which is rather fortunate since there are calls lurking like:
> 	syscall(SYS___syscall, SYS_foo, args)
> which really isn't going to DTRT unless syscall() is implemented in
> the library - which it cannot be for some architectures like amd64 (& sparc)
> where some, but not all, of the system call arguments are passed in registers.

I'm not sure about this one. But it occurs to me syscall and _syscall can
probably be turned into proper systems calls of their own *, so we don't
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Laight | 4 Nov 2007 11:31
Picon

Re: syscall() system call stub

On Sun, Nov 04, 2007 at 02:28:09AM +0000, Andrew Doran wrote:

> I'm not sure about this one. But it occurs to me syscall and _syscall can
> probably be turned into proper systems calls of their own *, so we don't
> have to do the tests in the syscall path. Does that make sense?
> 
> * ignoring systrace and to a much lesser extent ktrace

Yes I've had that thought as well.
I think 2 generic functions will suffice.

Adding a SYSCALL_NOTRACE [1] flag, and saving the 'code' from the syscall
entry trace for the exit one would solve the trace issue.

I think the code would be something like:

sys_syscall(lwp *l, register_t *args, register_t *rval)
{
	p = l->l_proc;
	code = args[0];
	callp = p->p_emul->e_sysent + code;
	if (p->p_trace_enabled)
		trace_enter(l, code, code, args + 1, callp->sy_argsize);
	return callp->sy_call(l, args + 1, rval);
}

Modulo some error checking and the argument types etc.

	David
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Doran | 4 Nov 2007 17:32
Picon

Re: syscall() system call stub

On Sun, Nov 04, 2007 at 10:31:19AM +0000, David Laight wrote:

> Yes I've had that thought as well.
> I think 2 generic functions will suffice.
> 
> Adding a SYSCALL_NOTRACE [1] flag, and saving the 'code' from the syscall
> entry trace for the exit one would solve the trace issue.
> 
> I think the code would be something like:
> 
> sys_syscall(lwp *l, register_t *args, register_t *rval)
> {
> 	p = l->l_proc;
> 	code = args[0];
> 	callp = p->p_emul->e_sysent + code;
> 	if (p->p_trace_enabled)
> 		trace_enter(l, code, code, args + 1, callp->sy_argsize);
> 	return callp->sy_call(l, args + 1, rval);
> }
> 
> Modulo some error checking and the argument types etc.

I think the beauty of it is we don't really need to have any special
handling for tracing + syscall() in the fast path. Again, I'm going to
ignore systrace for a moment but we have some options:

We could have trace_enter() be smart enought to fix up the arguments and
realise that it is syscall() then DTRT.

Or my favourite: do nothing. The only thing that is really interested in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Laight | 4 Nov 2007 22:58
Picon

Re: syscall() system call stub

On Sat, Nov 03, 2007 at 11:28:11AM +0000, David Laight wrote:
> The amd64 stub for syscall() is:
> 
> ENTRY(syscall)
> 	movl	%edi,%eax
> 	syscall
> 
> (from libc/arch/x86_64/sys/syscall.S)
> 
> This looks completely wrong to me.
> I think it needs to be:
> 	mov	$0,%eax
> 	mov	%rcx,%r10
> 	syscall
> 
> probably generated by RSYSCALL(syscall)

Certainly the current libc code doesn't DTRT:
	syscall(6, 10);
generates close(6) not close(10)

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 0 comments |
headers
Huub | 5 Nov 2007 11:23
Picon

Problems installing gimp

Hi,

I'm trying to install gimp-2.2.15nb2 by pkg_add from ftp, but it doesn't 
  autoload librsvg2-2.16.1nb2. It turns out not to be available for x64, 
so I try to build it and the build fails on libglade-2.6.2:

===> Creating toolchain wrappers for libglade-2.6.2
ERROR: fontconfig is not installed; can't buildlink files.

I already did "make distclean", but the errors keeps coming. What can I do?

Thanks.
Permalink | Reply | 2 comments |
headers
Zafer Aydogan | 5 Nov 2007 17:34
Picon

Re: Problems installing gimp

2007/11/5, Huub <huubvanniekerk <at> gmail.com>:
> Hi,
>
> I'm trying to install gimp-2.2.15nb2 by pkg_add from ftp, but it doesn't
>   autoload librsvg2-2.16.1nb2. It turns out not to be available for x64,
> so I try to build it and the build fails on libglade-2.6.2:
>
> ===> Creating toolchain wrappers for libglade-2.6.2
> ERROR: fontconfig is not installed; can't buildlink files.
>
> I already did "make distclean", but the errors keeps coming. What can I do?
>

You could try to install install it, by building it from source via
pkgsrc. That way, you would also get a newer version (2.4.1) of gimp.

I've recently installed it:
http://wiki.netbsd.se/Image:2007-11-01-205014_1680x1050_scrot.jpg

Zafer.

> Thanks.
>
>
Permalink | Reply | 1 comment |
headers
Huub | 5 Nov 2007 18:36
Picon

Re: Problems installing gimp

> You could try to install install it, by building it from source via
> pkgsrc. That way, you would also get a newer version (2.4.1) of gimp.
> 
> I've recently installed it:
> http://wiki.netbsd.se/Image:2007-11-01-205014_1680x1050_scrot.jpg
> 
> Zafer.
> 
>> Thanks.
>>
>>
> 

I tried that, and now again: same error. That's why I tried to install 
it using pkg_add
Permalink | Reply | 0 comments |
headers
Steven M. Bellovin | 6 Nov 2007 05:03

rbus not calculated on amd64?

Some time back, a change was made (by Greg Troxel, I thought) so that
rbus was calculated automatically.  It doesn't seem to happen on
amd64.  I have 3GB machine; here's what happened:

cbb0 at pci6 dev 0 function 0: Ricoh 5C476 PCI-CardBus bridge (rev.
0xba) cbb0: can't map socket base address 0xf8300000
cbb0: can't map socket base address 0xffffffff80d02810: io mode
cbb0: WARNING: power management not supported
cbb0: bad Vcc request. sock_ctrl 0xffffff88, sock_status 0xffffffff
cbb0: disabling socket
cbb0: interrupting at ioapic0 pin 16 (irq 10)
cbb0: WARNING: powerhook_establish is deprecated
cardslot0 at cbb0 slot 0 flags 0

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
Permalink | Reply | 7 comments |
headers
Arto Huusko | 6 Nov 2007 11:32
Picon
Picon

32 bit linux java

Hello,

I've been trying to analyse the problem I'm seeing with 32 bit linux
java on NetBSD/amd64 (4.99.34, with the recent linux32 changes), but
I'm not getting very far.

The problem I'm now trying to resolve is that an ant compilation task
hangs (there are others, such as memory faults sometimes). When the
hang occurs, I see two java processes eating up all CPU time, and they
don't respond to SIGTERM, but SIGKILL does work. Both processes eat
mostly system time (about 90% sys, 10% user time). The machine
is dual core, and one of the processes sits on the other CPU, and
the other process on the other CPU. The states are RUN/0 and CPU/1.

I ktraced the ant job, and found out that the other process (both
processes are cloned so they are java threads) is in tight loop
calling sched_yield, while the other process is apparently not doing
anything at all.

The last line for the "idle" process in the ktrace dump is return
from syscall, and not a call to syscall. I did a few runs, and the
syscall returned from changes every time. It looks like the process
just stops doing work at random location, and that the system time
the process is eating is not due to a system call it made.
Maybe the process is being switched to, and some work done in kernel
before giving control to user land is looping, or it won't switch
to the process, but since there are no other ready processes, it
keeps on trying the same one.

I also checked the ktrace dump if some other process had sent a
(Continue reading)

Permalink | Reply | 15 comments |

Gmane