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,
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.
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
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
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
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
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
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
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.
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
> |
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
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
>>
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
>
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
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
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
16 matches
Mail list logo