Re: more on MT debugging

[<don...@is...>]

I'm finally about to try this, and I realize that I don't know what
to do with these sanitize settings.  I'm guessing this line:

./configure CC='gcc -m64' --with-threads=POSIX_THREADS --disable-maintainer-mode --with-debug --with-module=rawsock build-mt

should be changed with some additional stuff in the CC=... ?

Also, was this for some particular shell?  
If I'm using bash what should I do?

And is the sanitize_ld a gcc flag or does it go somewhere else?

And finally, I'm guessing that the result is going to be thousands of
warnings that I probably won't understand or know how to fix.
Is that right?
(There are already plenty of warnings in the build transcript BTW.
I've been assuming those don't have to be fixed.)

So should I post the output on this list?  


Pascal Bourguignon wrote (almost a month ago):

 > Now, perhaps it would be a little difficult to apply to the sources
 > of clisp, (would valgrind be appliable?), but I would start by
 > compiling with a recent gcc (eg. gcc-8.2) using a whole complement
 > of -fsanitize options, and correct all the problems found there
 > first. I'd suggest the following as a basis.
 > 
 > sanitize_ld=(
 >         -fsanitize=leak
 > )
 > 
 > sanitize_cc=(
 >     -fsanitize=address
 >     -fsanitize=null
 >     -fsanitize=bounds
 >     -fsanitize=vla-bound
 >     -fsanitize=object-size
 > 
 >     -fsanitize=unreachable
 >     -fsanitize=return # C++ only
 > 
 >     -fsanitize=shift
 >     -fsanitize=shift-exponent
 >     -fsanitize=shift-base
 >     -fsanitize=integer-divide-by-zero
 >     -fsanitize=signed-integer-overflow
 > 
 >     -fsanitize=float-divide-by-zero
 >     -fsanitize=float-cast-overflow
 >     -fsanitize=nonnull-attribute
 >     -fsanitize=returns-nonnull-attribute
 >     -fsanitize=bool
 >     -fsanitize=enum
 >     -fsanitize=vptr # C++ only
 > 
 > 
 >     -fsanitize-address-use-after-scope
 >     -fsanitize-undefined-trap-on-error
 >     -fstack-protector-all
 >     -fstack-check
 > )
 > 
 > 
 > Once the program can be compiled and run successfully with those correction, to debug the remaining segfault, you would run it under gdb to be able to inspect the stack when the segfault occur, and try to locate the place in the source where it occured.  This may also be done on the core file, but it is easier to debug in a live process.
 > 
 > -- 
 > __Pascal J. Bourguignon__
 > 
 > 
 > 
 >