On 05-02-24 17:02, Brooks Davis wrote:
Could you do a quick test with an exe linked to libsys but not libc running
under Valgrind memcheck, please?
Could you suggest a more concrete example?
This little example seems to be OK
void _start(void)
{
_exit(0);
}
However I do see quite a
On Thu, Feb 22, 2024 at 10:16:30AM -0800, Mark Millard wrote:
> Brooks Davis wrote on
> Date: Thu, 22 Feb 2024 02:03:09 UTC :
>
> > On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote:
> > > On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> > > > That's probably wort
Brooks Davis wrote on
Date: Thu, 22 Feb 2024 02:03:09 UTC :
> On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote:
> > On Wed, Feb 21, 2024 at 08:20:25PM +, Brooks Davis wrote:
> > > That's probably worth a shot. Static linking will work anyway because
> > > libc.a in effect e
Am 2024-02-21 10:52, schrieb hartmut.bra...@dlr.de:
Hi,
I updated yesterday and now event a minimal program with
cc -fsanitize=address
produces
ld: error: undefined symbol: __elf_aux_vector
referenced by sanitizer_linux_libcdep.cpp:950
(/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer
On 21 Feb 2024, at 20:00, Brooks Davis wrote:
>
> The sanitizers reach somewhat questionably into libc internals that are
> exported to allow rtld to update them. I was unable to find an solution
> that didn't break this and I felt that fixing things like closefrom()
> using non-deprecated sysca
roduces
> > > >>
> > > >> ld: error: undefined symbol: __elf_aux_vector
> > > >>>>> referenced by sanitizer_linux_libcdep.cpp:950
> > > >>>>> (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_lib
tizer_common/sanitizer_linux_libcdep.cpp:950)
> > >>>>> sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in
> > >>>>> archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a
> > >> cc: error: linker command failed with exit co
a
> >> cc: error: linker command failed with exit code 1 (use -v to see
> >> invocation)
> >>
> >> I think this is caused by the libsys split.
> >>
> >> Cheers,
> >> Harti
> >>
> >> -Original Message-
&g
aused by the libsys split.
>>
>> Cheers,
>> Harti
>>
>> -Original Message-
>> From: owner-freebsd-curr...@freebsd.org
>> On Behalf Of Brooks Davis
>> Sent: Friday, February 2, 2024 11:32 PM
>> To: curr...@freebsd.org
>> Subject: li
Original Message-
> From: owner-freebsd-curr...@freebsd.org
> On Behalf Of Brooks Davis
> Sent: Friday, February 2, 2024 11:32 PM
> To: curr...@freebsd.org
> Subject: libc/libsys split coming soon
>
> TL;DR: The implementation of system calls is moving to a seperate libra
[Brooks' activity related to commit 99ea67573164637d633e8051eb0a5d52f1f9488e
looks likely for what changed the status: "lib{c,sys}: move auxargs more
firmly into libsys".]
On Feb 21, 2024, at 09:02, Mark Millard wrote:
> On Feb 21, 2024, at 08:38, Mark Millard wrote:
>
>> Mark Johnston wrote
On Feb 21, 2024, at 08:38, Mark Millard wrote:
> Mark Johnston wrote on
> Date: Wed, 21 Feb 2024 13:33:43 UTC :
>
>> On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
>>> Hi,
>>>
>>> I updated yesterday and now event a minimal program with
>>>
>>> cc -fsanitize=address
>>
Mark Johnston wrote on
Date: Wed, 21 Feb 2024 13:33:43 UTC :
> On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
> > Hi,
> >
> > I updated yesterday and now event a minimal program with
> >
> > cc -fsanitize=address
> >
> > produces
> >
> > ld: error: undefined symbol: __
MJ>> From: owner-freebsd-curr...@freebsd.org
On Behalf Of Brooks Davis
MJ>> Sent: Friday, February 2, 2024 11:32 PM
MJ>> To: curr...@freebsd.org
MJ>> Subject: libc/libsys split coming soon
MJ>>
MJ>> TL;DR: The implementation of system calls is moving to a seperate
are you running?
> Cheers,
> Harti
>
> -Original Message-
> From: owner-freebsd-curr...@freebsd.org
> On Behalf Of Brooks Davis
> Sent: Friday, February 2, 2024 11:32 PM
> To: curr...@freebsd.org
> Subject: libc/libsys split coming soon
>
> TL;DR: The
Cheers,
Harti
-Original Message-
From: owner-freebsd-curr...@freebsd.org On
Behalf Of Brooks Davis
Sent: Friday, February 2, 2024 11:32 PM
To: curr...@freebsd.org
Subject: libc/libsys split coming soon
TL;DR: The implementation of system calls is moving to a seperate library
(libsys).
Hi
> On 5 Feb 2024, at 17:02, Brooks Davis wrote:
>
>
>>> 2. It simplifies the implementation of restrictions on system calls such
>>> as those implemented by OpenBSD's msyscall(2)
>>> (https://man.openbsd.org/msyscall.2).
>>
>> That's one to ignore for tools that make syscalls out
On Sat, Feb 03, 2024 at 10:15:09AM +0100, Mateusz Guzik wrote:
> On 2/2/24, Brooks Davis wrote:
> > TL;DR: The implementation of system calls is moving to a seperate
> > library (libsys). No changes are required to existing software (except
> > to ensure that libsys is present when building custo
On Sat, Feb 03, 2024 at 05:11:42PM +0100, Paul Floyd wrote:
>
> On 02/02/2024 23:31, Brooks Davis wrote:
> > TL;DR: The implementation of system calls is moving to a seperate
> > library (libsys). No changes are required to existing software (except
> > to ensure that libsys is present when build
On Sat, Feb 03, 2024 at 11:10:14AM -0700, Warner Losh wrote:
> On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov
> wrote:
>
> > On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > > Will this break binary compatibility with older programs expecting those
> > symbols in libc and no
On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov
wrote:
> On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
>
> As was mentioned, libc filters libsys. This mean
On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
As was mentioned, libc filters libsys. This means that libc exports all
the same symbols as before, but forward t
On Sat, Feb 03, 2024 at 12:12:35PM +0100, Mateusz Guzik wrote:
> On 2/3/24, David Chisnall wrote:
> > On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
> >>
> >> Binary startup is very slow, for example execve of a hello world
> >> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
On 02/02/2024 23:31, Brooks Davis wrote:
TL;DR: The implementation of system calls is moving to a seperate
library (libsys). No changes are required to existing software (except
to ensure that libsys is present when building custom disk images).
Code:https://github.com/freebsd/freebsd-src/pull
Will this break binary compatibility with older programs expecting those
symbols in libc and not linked to libsys?
> On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber wrote:
>
> On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
>> TL;DR: The implementation of system calls is moving to a seperate
>>
Am Sat, Feb 03, 2024 at 10:15:09AM +0100 schrieb Mateusz Guzik:
> Do I read it correctly that everything dynamically linked will also be
> linked to libsys, as in executing such a binary will now require
> loading one extra .so?
>
> Binary startup is very slow, for example execve of a hello world
On 2/3/24, David Chisnall wrote:
> On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>>
>> Binary startup is very slow, for example execve of a hello world
>> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
>> compared to a native one. As such perf-wise this looks like a step in
On 3 Feb 2024, at 09:15, Mateusz Guzik wrote:
>
> Binary startup is very slow, for example execve of a hello world
> binary in a Linux-based chroot on FreeBSD is faster by a factor of 2
> compared to a native one. As such perf-wise this looks like a step in
> the wrong direction.
Have you profil
On 2/2/24, Brooks Davis wrote:
> TL;DR: The implementation of system calls is moving to a seperate
> library (libsys). No changes are required to existing software (except
> to ensure that libsys is present when building custom disk images).
>
> Code: https://github.com/freebsd/freebsd-src/pull/9
On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> TL;DR: The implementation of system calls is moving to a seperate
> library (libsys). No changes are required to existing software (except
> to ensure that libsys is present when building custom disk images).
>
> Code: https://github.com/freebsd/
Brooks Davis wrote in
:
|TL;DR: The implementation of system calls is moving to a seperate
|library (libsys). No changes are required to existing software (except
|to ensure that libsys is present when building custom disk images).
...
[]
|This change serves three primary purposes:
| 1
TL;DR: The implementation of system calls is moving to a seperate
library (libsys). No changes are required to existing software (except
to ensure that libsys is present when building custom disk images).
Code: https://github.com/freebsd/freebsd-src/pull/908
After nearly a decade of intermittent
32 matches
Mail list logo
