|
|
Created:
5 years, 7 months ago by Michael Achenbach Modified:
5 years, 6 months ago CC:
jochen (gone - plz use gerrit), Sven Panne, v8-dev Base URL:
https://chromium.googlesource.com/v8/v8.git@master Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
Description[test] Use instrumented libc++ for asan and tsan builds.
BUG=chromium:489254
LOG=n
Committed: https://crrev.com/77b7b39b4ee2428ced631227b8f19d42997b1718
Cr-Commit-Position: refs/heads/master@{#28676}
Patch Set 1 #Patch Set 2 : Rebase #Patch Set 3 : Rebase #Messages
Total messages: 16 (3 generated)
machenbach@chromium.org changed reviewers: + earthdok@chromium.org, glider@chromium.org
PTAL. After incorporating the take-aways from https://codereview.chromium.org/1146863006/, there still remain problems for using libcxx with v8 snapshot builds (here asan and tsan). The msan bot works because it's nosnap. Will I need a host/target toolset separation in libcxx?
On 2015/05/26 15:21:55, Michael Achenbach wrote: > PTAL. After incorporating the take-aways from > https://codereview.chromium.org/1146863006/, there still remain problems for > using libcxx with v8 snapshot builds (here asan and tsan). The msan bot works > because it's nosnap. > > Will I need a host/target toolset separation in libcxx? No no, this has nothing to do with snapshots. The problem is that we're not passing -fPIC when compiling libc++. * -fPIC is requred for any shared library build on x86_64 Linux * Chromium supplies it everywhere: https://chromium.googlesource.com/chromium/src/+/6138f464f771b325fb8399401133... * v8 standalone doesn't do that, so libc++ will not compile unless PIC is enabled implicitly by either of -fsanitize=... * Only -fsanitize=memory actually implies PIC, -fsanitize={address,thread} don't (I was wrong previously if I said they did - sorry). I'm submitting a CL to buildtools/ to fix some libc++ build flags, so I'll just add this flag to the list. On an unrelated note, something that caught my eye in the logs: > GYP_DEFINES': 'asan=1 clang=1 dcheck_always_on=0 fastbuild=1 Note that Chromium sets fastbuild=0 for non-Linux ASan bots: https://code.google.com/p/chromium/codesearch#chromium/build/scripts/slave/re... glider@ should be able to explain the significance of that.
On 2015/05/26 17:38:18, earthdok wrote: > I'm submitting a CL to buildtools/ to fix some libc++ build flags, so I'll just > add this flag to the list. For reference: https://codereview.chromium.org/1154213002/
On 2015/05/26 17:46:43, earthdok wrote: > On 2015/05/26 17:38:18, earthdok wrote: > > I'm submitting a CL to buildtools/ to fix some libc++ build flags, so I'll > just > > add this flag to the list. > > For reference: https://codereview.chromium.org/1154213002/ Thanks for the buildtools fix! I'll wait until it rolled through and then retry.
> On an unrelated note, something that caught my eye in the logs: > > > GYP_DEFINES': 'asan=1 clang=1 dcheck_always_on=0 fastbuild=1 > > Note that Chromium sets fastbuild=0 for non-Linux ASan bots: > > https://code.google.com/p/chromium/codesearch#chromium/build/scripts/slave/re... > > glider@ should be able to explain the significance of that. V8's gyp configs don't support fastbuild. Its value is therefore irrelevant. I assume it bubbles up in the recipes from some common tryserver setting from chrome's configs. I also don't believe we should implement it as we already build quite fast.
PTAL. Reran after the buildtools roll. Now there are new failures.
On 2015/05/27 14:45:12, Michael Achenbach wrote: > PTAL. Reran after the buildtools roll. Now there are new failures. Somehow, you have Ninja enabled on your MSan bot, whereas ASan and TSan bots use make. This problem happens because make puts libc++.so in Release/lib.host/ and Release/lib.target/. Our libc++ GYP config expects it to be in Release/lib, as it is in a Ninja build. Is it time to drop make support maybe?
On 2015/05/27 16:58:17, earthdok wrote: > On 2015/05/27 14:45:12, Michael Achenbach wrote: > > PTAL. Reran after the buildtools roll. Now there are new failures. > > Somehow, you have Ninja enabled on your MSan bot, whereas ASan and TSan bots use > make. > > This problem happens because make puts libc++.so in Release/lib.host/ and > Release/lib.target/. Our libc++ GYP config expects it to be in Release/lib, as > it is in a Ninja build. > > Is it time to drop make support maybe? Thanks for the hint. Works now after switching to ninja. Does the patch as such look good?
jochen@chromium.org changed reviewers: + jochen@chromium.org
lgtm
The CQ bit was checked by machenbach@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1143173005/40001
Message was sent while issue was closed.
Committed patchset #3 (id:40001)
Message was sent while issue was closed.
Patchset 3 (id:??) landed as https://crrev.com/77b7b39b4ee2428ced631227b8f19d42997b1718 Cr-Commit-Position: refs/heads/master@{#28676}
Message was sent while issue was closed.
lgtm |