Cyril Brulebois (22/06/2009):
> Aurelien Jarno (22/06/2009):
> > I agree this starts to be critical, however please try to contact
> > the maintainers one more before actually doing the NMU, one of them
> > (Nathan Scott) has already answered to the bug report.
>
> That was of course the plan.
There will be also significant slowdown, as we have to prepare aguments
on stack, alter stack to get exactly the same stack layout as the
standard syscall would be used. We will lose correct unwinding info, et
cetera, et cetera.
After some discussions on IRC, it seems the easiest way do to it,
Aurelien Jarno (22/06/2009):
> > I could take care of that this week.
>
> I agree this starts to be critical, however please try to contact the
> maintainers one more before actually doing the NMU, one of them
> (Nathan Scott) has already answered to the bug report.
That was of course the plan.
On Mon, Jun 22, 2009 at 10:19:05AM +0200, Petr Salinger wrote:
>>> INTERNAL_SYSCALL_close(name, err, nr, fd)
>>> INTERNAL_SYSCALL_writev(name, err, nr, fd, iov, cnt)
>>>
>>> Testsuite is OK, code is in glibc-bsd and pkg-glibc SVNs.
>
>> However I still think we should plan using real inline syscall
On Mon, Jun 22, 2009 at 07:05:55PM +0200, Cyril Brulebois wrote:
> Petr Salinger (22/06/2009):
> > BTW, the fix for #531950 attr: FTBFS on GNU/kFreeBSD, have been applied
> > upstream
> > http://git.savannah.gnu.org/cgit/attr.git/commit/?id=b4636a4e9e9ea69ea2f3301cec7f446328a6
> >
> > May be
Petr Salinger (22/06/2009):
> BTW, the fix for #531950 attr: FTBFS on GNU/kFreeBSD, have been applied
> upstream
> http://git.savannah.gnu.org/cgit/attr.git/commit/?id=b4636a4e9e9ea69ea2f3301cec7f446328a6
>
> May be there is a time for porter NMU, in the past two years, package
> have been up
INTERNAL_SYSCALL_close(name, err, nr, fd)
INTERNAL_SYSCALL_writev(name, err, nr, fd, iov, cnt)
Testsuite is OK, code is in glibc-bsd and pkg-glibc SVNs.
However I still think we should plan using real inline syscalls sooner
or later to avoid future problems like this one, but at least now we
h
Petr Salinger a écrit :
>> But in fact, the HAVE_INLINED_SYSCALLS currently
>> means only HAVE_INTERNAL_SYSCALLS ...
>>
>>> The calls to INLINE_SYSCALL is not the part that worries me the most. It's
>>> rather the code between #ifdef HAVE_INLINED_SYSCALLS in the elf/
>>> directory. Not something we
But in fact, the HAVE_INLINED_SYSCALLS currently
means only HAVE_INTERNAL_SYSCALLS ...
The calls to INLINE_SYSCALL is not the part that worries me the most. It's
rather the code between #ifdef HAVE_INLINED_SYSCALLS in the elf/
directory. Not something we can workaround easily from our
ports/sys
There are two different macros INTERNAL_SYSCALL and INLINE_SYSCALL.
It remains to persuade Ulrich Drepper to distinct between them :-(
Unfortunately he his not someone easy to convince...
I know ...
But in fact, the HAVE_INLINED_SYSCALLS currently
means only HAVE_INTERNAL_SYSCALLS ...
The c
On Wed, Jun 17, 2009 at 08:07:58AM +0200, Petr Salinger wrote:
>> The GNU/kFreeBSD port of the GNU libc uses normal syscalls (each syscall
>> is mapped to a function), while the GNU/Linux version only uses inline
>> syscalls (each syscall is mapped to asm inline code). The difference
>> mainly come
The GNU/kFreeBSD port of the GNU libc uses normal syscalls (each syscall
is mapped to a function), while the GNU/Linux version only uses inline
syscalls (each syscall is mapped to asm inline code). The difference
mainly comes from the fact that the FreeBSD kernel is also using the
architecture ABI
Hi all,
The GNU/kFreeBSD port of the GNU libc uses normal syscalls (each syscall
is mapped to a function), while the GNU/Linux version only uses inline
syscalls (each syscall is mapped to asm inline code). The difference
mainly comes from the fact that the FreeBSD kernel is also using the
architec
13 matches
Mail list logo
