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
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 embeds libsys to retain compatability.
> Please do not add libsys.so t
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 embeds libsys to retain compatability.
Please do not add libsys.so to the ABI. Right now it is an implementation
detail of libthr and libc, and
That's probably worth a shot. Static linking will work anyway because
libc.a in effect embeds libsys to retain compatability.
-- Brooks
On Wed, Feb 21, 2024 at 09:12:41PM +0100, Dimitry Andric wrote:
> Can't we just add libsys.so to the /usr/lib/libc.so linker script? That would
> work for ever
Can't we just add libsys.so to the /usr/lib/libc.so linker script? That would
work for everything except static linking?
-Dimitry
> On 21 Feb 2024, at 21:00, Brooks Davis wrote:
>
> TL;DR: you can work around this by adding -lsys to the link line and I
> aim to improve the situation soon.
>
>
TL;DR: you can work around this by adding -lsys to the link line and I
aim to improve the situation soon.
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 t
[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: __
On Wed, 21 Feb 2024, Mark Johnston wrote:
MJ>On Wed, Feb 21, 2024 at 09:52:23AM +, hartmut.bra...@dlr.de wrote:
MJ>> Hi,
MJ>>
MJ>> I updated yesterday and now event a minimal program with
MJ>>
MJ>> cc -fsanitize=address
MJ>>
MJ>> produces
MJ>>
MJ>> ld: error: undefined symbol: __elf_aux_ve
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: __elf_aux_vector
> >>> referenced by sanitizer_linux_libcdep.cpp:950
> >>> (/usr/src
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_common/sanitizer_linux_libcdep.cpp:950)
>>>
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
31 matches
Mail list logo
