[LLVMdev] Compiling bash-3.0 with llvm

[xia_nai@yahoo.com.cn]

On Friday 14 April 2006 13:26, you wrote:
> On Fri, 14 Apr 2006, xia_nai at yahoo.com.cn wrote:
> >> Have you tried compiling bash with a native GCC then running it through
> >> valgrind?
> >
> > The native compiled bash can run properly, but valgrind detect memory errors with the error summary
> > below:
> 
> This is probably a bug in bash or something.  LLVM does more aggressive 
> optimizations than GCC does, which causes it to turn latent bugs like this 
> into actual bugs.
> 
> Also, you could try compiling the program with llc and see if it works 
> better.  Sometimes the JIT exacerbates bugs in programs that expect memory 
> returned by malloc to be zero'd.
> 

Yeah~,it works now. You are right, Chris.
Thank you very much!
And actually I am thinking that maybe someone could turn LLVM into another bug tracker :) 

btw: The LLVM 1.7 release improvements list seems rather exciting :-)

> -Chris
> 
> 
> > ==15243== Conditional jump or move depends on uninitialised value(s)
> > ==15243==    at 0x4009000: (within /lib/ld-2.3.6.so)
> > ==15243==    by 0x41783DB: dl_open_worker (dl-open.c:343)
> > ==15243==    by 0x400BAAE: (within /lib/ld-2.3.6.so)
> > ==15243==    by 0x4178A7A: _dl_open (dl-open.c:577)
> > ==15243==    by 0x417A06C: do_dlopen (dl-libc.c:80)
> > ==15243==    by 0x400BAAE: (within /lib/ld-2.3.6.so)
> > ==15243==    by 0x417A022: dlerror_run (dl-libc.c:42)
> > ==15243==    by 0x417A135: __libc_dlopen_mode (dl-libc.c:153)
> > ==15243==    by 0x4155306: __nss_lookup_function (nsswitch.c:344)
> > ==15243==    by 0x415549E: __nss_lookup (nsswitch.c:150)
> > ==15243==    by 0x415707F: __nss_passwd_lookup (XXX-lookup.c:73)
> > ==15243==    by 0x4110C01: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:171)
> > ==15244==
> > ==15244== ERROR SUMMARY: 12 errors from 2 contexts (suppressed: 15 from 1)
> > ==15244== malloc/free: in use at exit: 0 bytes in 0 blocks.
> > ==15244== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> > ==15244== For counts of detected errors, rerun with: -v
> > ==15244== All heap blocks were freed -- no leaks are possible.
> >
> >
> >
> >>
> >> -Chris
> >>
> >
> 
> -Chris
>