Abseil and QUICHE

106 views
Skip to first unread message

Victor Vasiliev

unread,
Jan 28, 2020, 12:01:14 AM1/28/20
to c...@chromium.org, net...@chromium.org, dani...@chromium.org, kwi...@chromium.org, mbon...@chromium.org, phog...@chromium.org
Hello cxx@ and //third_party/abseil owners,

Our team (QUIC) has code that's shared across google3 and Chromium, with google3 as a source of truth and Chromium code using a copy in //net/third_party/quiche.  We use a lot of Abseil types in our code, and in order to make that work in Chromium, we abstract them away using an sizable abstraction layer.  We would like to get rid of most of that layer, and just use Abseil directly.

This was previously blocked on the fact QUICHE did not have its own build targets.  Now that this has been fixed, we would like to opt //net/third_party/quiche into using Abseil.

(see this and this document for more context)

Thanks,
  Victor.

Daniel Cheng

unread,
Jan 28, 2020, 12:07:48 AM1/28/20
to Victor Vasiliev, cxx, net...@chromium.org, dani...@chromium.org, kwi...@chromium.org, mbon...@chromium.org, phog...@chromium.org
Will absl be needed outside the quiche code? I assume it would be similar to the situation today (i.e. absl::optional, absl::Span, and a few other things would be needed to interface across the boundaries)? What's the policy for whether those types would be transported outside of quiche code as absl types or as the corresponding //base types?

Daniel

--
You received this message because you are subscribed to the Google Groups "cxx" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cxx+uns...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/cxx/CAAZdMad_inkTD-T4kiTNUFcMCc8kbiqpfcxyXWSfOXYPWtxnoQ%40mail.gmail.com.

Victor Vasiliev

unread,
Jan 28, 2020, 12:28:21 AM1/28/20
to Daniel Cheng, cxx, net...@chromium.org, dani...@chromium.org, kwi...@chromium.org, mbon...@chromium.org, phog...@chromium.org
I believe there are roughly two types that are actively used as a part of the API, StringPiece and Optional.  My current plan is to keep those abstracted away (i.e. as an alias for corresponding base:: types) for now, and wait for C++17 support to solve that issue properly.

Nico Weber

unread,
Jan 28, 2020, 7:50:09 AM1/28/20
to Victor Vasiliev, Daniel Cheng, cxx, net-dev, dani...@chromium.org, kwi...@chromium.org, Mirko Bonadei, Patrik Höglund
Hello,

absl doesn't yet have a component build mode, and for that reason can be used by only one target at the moment. That target is absl. From what I understand, the absl folks are working on adding such a mode, but it's not done yet. Using absl in more targets than webrtc is blocked on that work being completed.

Nico

Mirko Bonadei

unread,
Jan 28, 2020, 7:55:43 AM1/28/20
to Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
On Tue, Jan 28, 2020 at 1:50 PM Nico Weber <tha...@chromium.org> wrote:
Hello,

absl doesn't yet have a component build mode, and for that reason can be used by only one target at the moment. That target is absl. From what I understand, the absl folks are working on adding such a mode, but it's not done yet. Using absl in more targets than webrtc is blocked on that work being completed.

Sorry, I have missed this one. Yes, as Nico said, broader usage of abseil in Chromium is blocked by the component build support. Other potential users are blocked on this issue and there are some discussions ongoing with the abseil team. I will keep you updated if anything changes in this regard.

David Benjamin

unread,
Jan 28, 2020, 11:19:14 AM1/28/20
to Mirko Bonadei, Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
Is there a bug or so to follow here? Could we just build //third_party/abseil without -fvisibility=hidden (i.e. blindly treat every symbol as exported)? I guess that probably wouldn't work for Windows since it has the dllimport and dllexport things to worry about.

Mirko Bonadei

unread,
Jan 28, 2020, 11:36:27 AM1/28/20
to David Benjamin, Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
On Tue, Jan 28, 2020 at 5:19 PM David Benjamin <davi...@chromium.org> wrote:
Is there a bug or so to follow here? Could we just build //third_party/abseil without -fvisibility=hidden (i.e. blindly treat every symbol as exported)? I guess that probably wouldn't work for Windows since it has the dllimport and dllexport things to worry about.

No, there is no bug yet. I will create one soon.

We can remove -fvisibility=default (https://cs.chromium.org/chromium/src/build/config/gcc/BUILD.gn?l=23-41&rcl=65a5774db4cfcbb3c5ce25f67d6dea6bdf3d0969) and it may be interesting to try but as you say, I am not sure it will work for Windows. Before doing that, I have to create an abseil component, at the moment the GN targets are mirroring the Bazel ones and are all source_sets.

Mirko Bonadei

unread,
Jan 28, 2020, 11:42:16 AM1/28/20
to David Benjamin, Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
On Tue, Jan 28, 2020 at 5:36 PM Mirko Bonadei <mbon...@chromium.org> wrote:
On Tue, Jan 28, 2020 at 5:19 PM David Benjamin <davi...@chromium.org> wrote:
Is there a bug or so to follow here? Could we just build //third_party/abseil without -fvisibility=hidden (i.e. blindly treat every symbol as exported)? I guess that probably wouldn't work for Windows since it has the dllimport and dllexport things to worry about.

No, there is no bug yet. I will create one soon.

We can remove -fvisibility=default (https://cs.chromium.org/chromium/src/build/config/gcc/BUILD.gn?l=23-41&rcl=65a5774db4cfcbb3c5ce25f67d6dea6bdf3d0969) and it may be interesting to try but as you say, I am not sure it will work for Windows. Before doing that, I have to create an abseil component, at the moment the GN targets are mirroring the Bazel ones and are all source_sets.

Typo, I meant "remove -fvisibility=hidden" and use "-fvisibility=default".

Chris Palmer

unread,
Jan 31, 2020, 4:46:26 PM1/31/20
to Mirko Bonadei, David Benjamin, Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
Also, what about safety checks in Abseil? (E.g. bounds-checking operator[] and so on.)

Mirko Bonadei

unread,
Feb 3, 2020, 2:53:30 AM2/3/20
to Chris Palmer, David Benjamin, Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
On Fri, Jan 31, 2020 at 10:46 PM Chris Palmer <pal...@chromium.org> wrote:
Also, what about safety checks in Abseil? (E.g. bounds-checking operator[] and so on.)

Good point. +Daniel Cheng to reply to this point. (If I remember correctly Daniel was looking into these some months ago).

Chris Palmer

unread,
Feb 3, 2020, 2:09:35 PM2/3/20
to Mirko Bonadei, David Benjamin, Nico Weber, Victor Vasiliev, Daniel Cheng, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
I'm pretty happy with the thorough existence of safety checks in LLVM's libcxx. I'd really like to see the same for Abseil, and for Chromium to turn them on.

Daniel Cheng

unread,
Feb 3, 2020, 10:07:52 PM2/3/20
to Chris Palmer, Mirko Bonadei, David Benjamin, Nico Weber, Victor Vasiliev, cxx, net-dev, Danil Chapovalov, Karl Wiberg, Patrik Höglund
I guess we (chrome security) will have to sync up with absl about the status of these. IIRC, absl really wanted to avoid adding their first real buildflag, there were some other questions if we could use the ubsan hook (probably not, for binary size reasons), and I think the conversation mostly stalled out from there.

Daniel
Reply all
Reply to author
Forward
0 new messages