Today I noticed that the Osmocom_Sanitizer build has been broken for a long time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault of the way the Osmocom_Sanitizer builds:
When I build libosmocore with --enable-sanitize, everything works out. When I instead build with `make CFLAGS+="..."', some CFLAGS are dropped and the build fails.
The working commandline is:
./configure --enable-sanitize make V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -g -O2 -fsanitize=address -fsanitize=undefined -msse3 -msse4.1 -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o
The failing one is:
./configure make CFLAGS+="-fsanitize=address -fsanitize=undefined" V=1 [...] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -fsanitize=address -fsanitize=undefined -Wall -fsanitize=address -fsanitize=undefined -MT viterbi_sse.lo -MD -MP -MF .deps/viterbi_sse.Tpo -c viterbi_sse.c -fPIC -DPIC -o .libs/viterbi_sse.o
i.e. in the failing build, these cmdline args are missing: -O2 -g -msse3 -msse4.1
So it seems that the CFLAGS+="stuff" is not working as intended.
The alternative is to build with the ./configure --enable-sanitize, which I added at some point. But not all libs have this switch, AFAIR. I have added the --enable-sanitize configure option to libosmocore, and asked others to follow up in other repositories in the same fashion. I think this hasn't worked out everywhere yet.
Does it make sense to refresh the sanitize build effort?: switch the Osmocom_Sanitizer build to using this configure flag and add it where it is missing.
But I guess we should instead add the sanitize switch to each individual build script for the various *osmo* build jobs and switch off the Osmocom_Sanitizer build instead.
I repeat myself, but adding --enable-sanitize is not a lot of effort. See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da50...
I created https://osmocom.org/issues/2330
~N
On 18. Jun 2017, at 22:18, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Hi!
Today I noticed that the Osmocom_Sanitizer build has been broken for a long time, failing at libosmocore/src/viterbi_sse.c. But that seems like the fault of the way the Osmocom_Sanitizer builds:
can you think of a way to help us "spot" such things more early?
So it seems that the CFLAGS+="stuff" is not working as intended.
Right. The Makefile.am probably should use AM_CFLAGS an do not set CFLAGS directly?
I repeat myself, but adding --enable-sanitize is not a lot of effort. See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da50...
I like it as it has helped us to find a build system error. When I debug an issue I most frequently build with CFLAGS+="-ggdb3" and would like this to keep working. :)
holger
On Mon, Jun 19, 2017 at 12:39:19AM +0800, Holger Freyther wrote:
can you think of a way to help us "spot" such things more early?
our osmocom jenkins is unable to send emails. I once failed to get it working by using my own smtp account (IIRC). Important build failures should be sent to to the "high noise" ML gerrit-log@lists.osmocom.org.
That list is a bit of a misnomer, we could create a high-noise@ ML. Or just live with the name.
So it seems that the CFLAGS+="stuff" is not working as intended.
Right. The Makefile.am probably should use AM_CFLAGS an do not set CFLAGS directly?
I usually have no clue about automake until you turn up one day and teach me how it's done :) I'd believe you any day.
I repeat myself, but adding --enable-sanitize is not a lot of effort. See http://git.osmocom.org/libosmocore/commit/?id=a23817622b28cb1969a73ffd36da50...
I like it as it has helped us to find a build system error. When I
Wasn't aware that passing CFLAGS+= is a feature that should not be broken, if that is so then let's fix it.
libosmocore/$ rgrep CFLAGS |grep Makefile.am | grep -v _CFLAGS src/Makefile.am:29:viterbi_sse.lo : CFLAGS += -msse3 -msse4.1 src/Makefile.am:31:viterbi_sse.lo : CFLAGS += -msse3 src/Makefile.am:37:viterbi_sse_avx.lo : CFLAGS += -msse3 -mavx2 -msse4.1 src/Makefile.am:39:viterbi_sse_avx.lo : CFLAGS += -msse3 -mavx2
It seems to be firmly related to the viterbi build. @vadim, could you fix this to not use CFLAGS? Look around in the Makefile.am s to find the proper way to do it, I guess.
~N
Hi Neels, Holger,
@vadim, could you fix this to not use CFLAGS? Look around in the Makefile.am s to find the proper way to do it, I guess.
There is the main problem that automake does not support per-object flags :(
According to https://www.gnu.org/software/automake/ manual/html_node/Per_002dObject-Flags.html we can only specify per-program and per-library compilation flags. In OsmoTRX we have several static libraries for specific architectures. In libosmocore, we can not go the same way, because it's a shared library.
Keeping this in mind, I found a way to use per-object flags on Stack Overflow. The solution was to use the Target-specific Variable Values feature of GNU Make.
I thought "CFLAGS +=" will not overwrite anything... So, let me some time to find a proper solution. If you have any ideas, please let me know.
With best regards, Vadim Yanitskiy.
On Mon, Jun 19, 2017 at 03:47:20AM +0700, Vadim Yanitskiy wrote:
So, let me some time to find a proper solution. If you have any ideas, please let me know.
Take a look at https://gerrit.osmocom.org/#/c/2975/ and http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/578/ built with that patch which succeeds for libosmocore (still red because of a later failure)
~N
Take a look at https://gerrit.osmocom.org/#/c/2975/
Looks great to me! So simple change :)
With best regards, Vadim Yanitskiy.
-
Holger Freyther -
Neels Hofmeyr -
Vadim Yanitskiy