On Thu, Oct 25, 2012 at 1:24 PM, Xinliang David Li wrote:
> I don't know why you think so (It seems that the points mentioned in
> http://www.akkadia.org/drepper/no_static_linking.html mainly apply to
> release binaries, not sanitized ones), but for now let's drop the
> static link request.
Yeah
On Thu, Oct 25, 2012 at 10:19 AM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 10:00:03AM -0700, Xinliang David Li wrote:
>> How about statically linking just for executables, not shared library buid?
>
> That is IMHO still a bad idea.
I don't know why you think so (It seems that the points men
On Thu, Oct 25, 2012 at 10:00:03AM -0700, Xinliang David Li wrote:
> How about statically linking just for executables, not shared library buid?
That is IMHO still a bad idea.
Jakub
On Thu, Oct 25, 2012 at 9:55 AM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 09:48:54AM -0700, Xinliang David Li wrote:
>> > Why should be libasan linked statically by default?
>
>> There are a couple of reasons:
>>
>> 1) it makes running sanitized binary on remote machines which does not
>> ha
On Thu, Oct 25, 2012 at 09:48:54AM -0700, Xinliang David Li wrote:
> > Why should be libasan linked statically by default?
> There are a couple of reasons:
>
> 1) it makes running sanitized binary on remote machines which does not
> have libasan installed easier;
> 2) There is no guarantee that l
On Thu, Oct 25, 2012 at 9:52 AM, Diego Novillo wrote:
> On Thu, Oct 25, 2012 at 12:48 PM, Xinliang David Li
> wrote:
>> On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek wrote:
>>>
>>> librt is a very bad name, that clashes with glibc librt, would only create
>>> confusion.
>>
>> Ok, then we shoul
On Thu, Oct 25, 2012 at 12:48 PM, Xinliang David Li wrote:
> On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek wrote:
>>
>> librt is a very bad name, that clashes with glibc librt, would only create
>> confusion.
>
> Ok, then we should pick something that is not confusing but reflect
> the fact the
On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek wrote:
> On Thu, Oct 25, 2012 at 09:24:51AM -0700, Xinliang David Li wrote:
>> To accommodate tsan (and msan in the future), the directory structure
>> needs to be changed. The top level directory can be called something
>> like librt with the followi
On Thu, Oct 25, 2012 at 09:24:51AM -0700, Xinliang David Li wrote:
> To accommodate tsan (and msan in the future), the directory structure
> needs to be changed. The top level directory can be called something
> like librt with the following subdirs: asan, tsan, sanitizer_common,
> and interception
To accommodate tsan (and msan in the future), the directory structure
needs to be changed. The top level directory can be called something
like librt with the following subdirs: asan, tsan, sanitizer_common,
and interception. Also the libasan should be linked in statically by
default.
thanks,
Da
On Fri, Oct 19, 2012 at 3:52 PM, Xinliang David Li wrote:
> The library builds fine with the following diff. The file acinclude.m4
> is cloned from libmudflap.
This is OK with the corresponding ChangeLog entry (in ChangeLog.asan).
Diego.
The library builds fine with the following diff. The file acinclude.m4
is cloned from libmudflap.
David
index 485d169..3e847f1 100644
--- a/libasan/aclocal.m4
+++ b/libasan/aclocal.m4
@@ -1037,8 +1037,8 @@ AC_SUBST([am__tar])
AC_SUBST([am__untar])
]) # _AM_PROG_TAR
-m4_include([m4/libtool.m4])
David, I put the m4 subdir under libasan because once I use the .m4
files (libtool.m4 lt~obsolete.m4 ltoptions.m4 ltsugar.m4
ltversion.m4) and ltmain.sh under $topsrcdir, the problem that a bad
libtool was generated under
$topbuilddir/x86_64-unknown-linux-gnu/libasan you met yesterday
appeared.
On 2012-10-19 13:16 , Xinliang David Li wrote:
Other than that, if there are no other comments, the change is good to
check into the branch. Remaining bugs can always be found and fixed
later.
Agreed. David, could you commit the patch after Wei has addressed your
feedback? I have just commi
I tried it, and this version works for me.
Your probably do not need to add the m4 subdir under libasan. The
required m4 files are either in .. or ../config dir. See how
libmudflap does it.
Other than that, if there are no other comments, the change is good to
check into the branch. Remaining bu
thanks. If libasan is statically linked in (which is the case for
clang), removing the dependency on libstdc++ is a must.
David
On Thu, Oct 18, 2012 at 9:05 PM, Kostya Serebryany wrote:
> +few more folks
>
> libasan does not (and should not) depend on libstdc++-v3.
> In llvm build system it is
On Thu, Oct 18, 2012 at 11:16 AM, Jakub Jelinek wrote:
> On Thu, Oct 18, 2012 at 09:46:36AM -0700, Wei Mi wrote:
>> --- gcc/gcc.c (revision 192567)
>> +++ gcc/gcc.c (working copy)
>> @@ -679,6 +679,7 @@ proper position among the other output f
>> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
+ kcc the author of the libasan library.
Koystya, does libasan build (need to ) depend on C++ library ?
thanks,
David
On Thu, Oct 18, 2012 at 12:26 PM, Xinliang David Li wrote:
> On Thu, Oct 18, 2012 at 11:22 AM, Jakub Jelinek wrote:
>> On Thu, Oct 18, 2012 at 11:15:33AM -0700, Xinliang David
On Thu, Oct 18, 2012 at 11:22 AM, Jakub Jelinek wrote:
> On Thu, Oct 18, 2012 at 11:15:33AM -0700, Xinliang David Li wrote:
>> >> --- Makefile.def (revision 192487)
>> >> +++ Makefile.def (working copy)
>> >> @@ -119,6 +119,7 @@ target_modules = { module= libstdc++-v3;
>> >>
On Thu, Oct 18, 2012 at 11:15:33AM -0700, Xinliang David Li wrote:
> >> --- Makefile.def (revision 192487)
> >> +++ Makefile.def (working copy)
> >> @@ -119,6 +119,7 @@ target_modules = { module= libstdc++-v3;
> >> lib_path=src/.libs;
> >> raw_cxx=true; }
On Thu, Oct 18, 2012 at 09:46:36AM -0700, Wei Mi wrote:
> --- gcc/gcc.c (revision 192567)
> +++ gcc/gcc.c (working copy)
> @@ -679,6 +679,7 @@ proper position among the other output f
> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
> %(mflib) " STACK_SPLIT_SPEC "\
> %{fprofile-arcs|f
On Tue, Oct 16, 2012 at 12:27 AM, Jakub Jelinek wrote:
> On Mon, Oct 15, 2012 at 11:39:52PM -0700, Wei Mi wrote:
>> --- gcc/gcc.c (revision 192487)
>> +++ gcc/gcc.c (working copy)
>> @@ -679,6 +679,7 @@ proper position among the other output f
>> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
On Mon, Oct 15, 2012 at 11:39:52PM -0700, Wei Mi wrote:
> --- gcc/gcc.c (revision 192487)
> +++ gcc/gcc.c (working copy)
> @@ -679,6 +679,7 @@ proper position among the other output f
> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
> %(mflib) " STACK_SPLIT_SPEC "\
> %{fprofile-arcs|f
On Mon, Oct 15, 2012 at 11:39 PM, Wei Mi wrote:
>>
>> This is a good start. Can you send a patch out without including
>> libasan so at least the toplevel parts can be reviewed easier?
>> Also the changelog entry for gcc.c go under the gcc/ChangeLog rather
>> than the toplevel one.
>>
>> Thanks,
>
> This is a good start. Can you send a patch out without including
> libasan so at least the toplevel parts can be reviewed easier?
> Also the changelog entry for gcc.c go under the gcc/ChangeLog rather
> than the toplevel one.
>
> Thanks,
> Andrew Pinski
Sure, I attach it. Thanks for pointing
On Mon, Oct 15, 2012 at 11:25 PM, Wei Mi wrote:
> Hi,
>
> I create a patch to migrate llvm runtime to asan branch. The
> configure.ac is a preliminary version and almost doesn't contain any
> portability check. I build it and test my own small case only and it
> works. Just send it out to ask for
26 matches
Mail list logo
