On Feb 7, 6:34pm, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: libpthread_dbg removal from base
| http://netbsd.org/~kamil/patch-00027-pthread_dbg-detach-from-base-gdb.txt
|
| I've checked and there are no (local to) me regressions.
|
| GDB on NetBSD has a lot of room for improvement.
Apparently as an alternative to preloading a separate ld.elf_so
and others, I can disable ASLR.
Still unsure what to do with the pthread stuff.
I get the impression I should be compiling everything with asan,
but it's unclear to me how to start to build all of netbsd this
way.
On 07.02.2017 15:56, Christos Zoulas wrote:
> In article ,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> libpthread_dbg(3) is a remnant library from the M:N thread model
>> (pre-NetBSD-5.0) API to introspect threads within a process and for use
>> of a debuggers.
>>
>> Currently i
In article ,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>libpthread_dbg(3) is a remnant library from the M:N thread model
>(pre-NetBSD-5.0) API to introspect threads within a process and for use
>of a debuggers.
>
>Currently in the 1:1 model it's not used in GDB neither in LLDB and it's
libpthread_dbg(3) is a remnant library from the M:N thread model
(pre-NetBSD-5.0) API to introspect threads within a process and for use
of a debuggers.
Currently in the 1:1 model it's not used in GDB neither in LLDB and it's
not either planned to be used. It's current function to read pthread_t
s
On Tue, Feb 07, 2017 at 11:16:20AM +, co...@sdf.org wrote:
> env LD_PRELOAD="/usr/amd64/ ..
The crazy LD_PRELOAD command is because of this:
==15831==Shadow memory range interleaves with an existing memory mapping. ASan
cannot proceed correctly. ABORTING.
==15831==P
Hi,
I wanted to run our tests with asan/ubsan.
I've used the following:
cd /usr/src
./build.sh ... -O /usr/amd64 release
cd /usr/src/lib/libm
env USETOOLS=never CFLAGS="-fsanitize=undefined -fsanitize=address
-U_FORTIFY_SOURCE" LDFLAGS="-lasan -pthread -lubsan" make -j20
cd /usr/tests/lib/libm
