Re: Basesystem programs redefine routine symbols from libc

2017-12-18 Thread David Holland
On Sun, Dec 10, 2017 at 08:25:54PM -0600, David Young wrote: > > > The problem raised earlier as ps(1) wasn't buildable because of > > > duplicate symbol. This unveils the problems very early and so there is > > > no observed misbehavior. > > > > If the issue occures purely at link time,

Re: Basesystem programs redefine routine symbols from libc

2017-12-10 Thread David Young
On Sat, Dec 09, 2017 at 03:46:42PM +0100, Kamil Rytarowski wrote: > I'm testing LLVM sanitizers. Right now, not every one is compatible > as-is, because there are linker issues. The sanitizers redefine symbols > for routines in libc like uname(3) in order to sanitize it with internal > logic.

Re: Basesystem programs redefine routine symbols from libc

2017-12-10 Thread Kamil Rytarowski
On 10.12.2017 14:13, Robert Elz wrote: > Date:Sun, 10 Dec 2017 12:17:18 +0100 > From:Martin Husemann > Message-ID: <20171210111718.gb1...@mail.duskware.de> > > | I very well understand your POV here, but it is important to fully > | understand

Re: Basesystem programs redefine routine symbols from libc

2017-12-10 Thread Robert Elz
Date:Sun, 10 Dec 2017 12:17:18 +0100 From:Martin Husemann Message-ID: <20171210111718.gb1...@mail.duskware.de> | I very well understand your POV here, but it is important to fully | understand the problem before changing random things Let's

Re: Basesystem programs redefine routine symbols from libc

2017-12-10 Thread Martin Husemann
On Sat, Dec 09, 2017 at 11:35:07PM +0100, Kamil Rytarowski wrote: > I think that reusing symbol names of well-known standard functions from > libc is at least misleading and shouldn't happen - so the process of > renaming such functions is improving the situation. I disagree. The C standard (and

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread David Holland
On Sat, Dec 09, 2017 at 11:35:07PM +0100, Kamil Rytarowski wrote: > The problem raised earlier as ps(1) wasn't buildable because of > duplicate symbol. This unveils the problems very early and so there is > no observed misbehavior. If the issue occures purely at link time, then the problem is

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Kamil Rytarowski
On 09.12.2017 23:41, David Young wrote: > On Sat, Dec 09, 2017 at 03:46:42PM +0100, Kamil Rytarowski wrote: >> I'm testing LLVM sanitizers. Right now, not every one is compatible >> as-is, because there are linker issues. The sanitizers redefine symbols >> for routines in libc like uname(3) in

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Kamil Rytarowski
On 09.12.2017 23:35, Kamil Rytarowski wrote: > I think that reusing symbol names of well-known standard functions from > libc is at least misleading and shouldn't happen - so the process of > renaming such functions is improving the situation. > I've checked POSIX standard and it looks like

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread David Young
On Sat, Dec 09, 2017 at 03:46:42PM +0100, Kamil Rytarowski wrote: > I'm testing LLVM sanitizers. Right now, not every one is compatible > as-is, because there are linker issues. The sanitizers redefine symbols > for routines in libc like uname(3) in order to sanitize it with internal > logic.

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Kamil Rytarowski
On 09.12.2017 21:51, Robert Elz wrote: > Date:Sat, 9 Dec 2017 19:54:00 +0100 > From:Kamil Rytarowski > Message-ID: <2ae77bc6-0ccf-4b4a-02a5-84b218f81...@gmx.com> > > | The problem is not on the header files (preprocessor), but on the linker > |

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Robert Elz
Date:Sat, 9 Dec 2017 19:54:00 +0100 From:Kamil Rytarowski Message-ID: <2ae77bc6-0ccf-4b4a-02a5-84b218f81...@gmx.com> | The problem is not on the header files (preprocessor), but on the linker | level. The problem you are observing, yes, but that is

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Kamil Rytarowski
On 09.12.2017 20:11, Valery Ushakov wrote: > Kamil Rytarowski wrote: > >> The problem is not on the header files (preprocessor), but on the linker >> level. >> >> We are linking prebuilt .a / .so files with a target application. >> >> $ nm >>

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Valery Ushakov
Kamil Rytarowski wrote: > The problem is not on the header files (preprocessor), but on the linker > level. > > We are linking prebuilt .a / .so files with a target application. > > $ nm > /usr/local/lib/clang/6.0.0/lib/netbsd/libclang_rt.msan-x86_64.a|grep uname >

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Kamil Rytarowski
On 09.12.2017 19:15, Robert Elz wrote: > Date:Sat, 9 Dec 2017 15:46:42 +0100 > From:Kamil Rytarowski > Message-ID: > > | However there exist programs in the basesystem that shadow libc > | symbol

Re: Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Robert Elz
Date:Sat, 9 Dec 2017 15:46:42 +0100 From:Kamil Rytarowski Message-ID: | However there exist programs in the basesystem that shadow libc | symbol routines as well, There is nothing wrong with that, in

Basesystem programs redefine routine symbols from libc

2017-12-09 Thread Kamil Rytarowski
I'm testing LLVM sanitizers. Right now, not every one is compatible as-is, because there are linker issues. The sanitizers redefine symbols for routines in libc like uname(3) in order to sanitize it with internal logic. However there exist programs in the basesystem that shadow libc symbol