[Lldb-commits] [lldb] r351631 - Install new LLVM license structure and new developer policy.

[Chandler Carruth via lldb-commits]

Author: chandlerc
Date: Fri Jan 18 22:14:24 2019
New Revision: 351631

URL: http://llvm.org/viewvc/llvm-project?rev=351631&view=rev
Log:
Install new LLVM license structure and new developer policy.

This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.

Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.

I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.

This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.

Differential Revision: https://reviews.llvm.org/D56897

Modified:
lldb/trunk/LICENSE.TXT

Modified: lldb/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/LICENSE.TXT?rev=351631&r1=351630&r2=351631&view=diff
==
--- lldb/trunk/LICENSE.TXT (original)
+++ lldb/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019
@@ -1,3 +1,241 @@
+==
+The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:
+==
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+ 

[Lldb-commits] [lldb] r351731 - Fix typos throughout the license files that somehow I and my reviewers

[Chandler Carruth via lldb-commits]

Author: chandlerc
Date: Mon Jan 21 01:52:34 2019
New Revision: 351731

URL: http://llvm.org/viewvc/llvm-project?rev=351731&view=rev
Log:
Fix typos throughout the license files that somehow I and my reviewers
all missed!

Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.

Modified:
lldb/trunk/LICENSE.TXT

Modified: lldb/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/LICENSE.TXT?rev=351731&r1=351730&r2=351731&view=diff
==
--- lldb/trunk/LICENSE.TXT (original)
+++ lldb/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 University of Illinois/NCSA
 Open Source License


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r353324 - [Reproducers] SBReproducer framework: Capture & Replay

[Chandler Carruth via lldb-commits]

Several files in this commit incorrectly use the old file headers from
before the relicense. I've fixed them, but please be careful with any other
outstanding commits.

On Wed, Feb 6, 2019 at 10:57 AM Jonas Devlieghere via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jdevlieghere
> Date: Wed Feb  6 10:57:42 2019
> New Revision: 353324
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353324&view=rev
> Log:
> [Reproducers] SBReproducer framework: Capture & Replay
>
> This is part two of the reproducer instrumentation framework. It
> contains the code to capture and replay function calls. The main user of
> this framework will be the SB API layer.
>
> For all the details refer to the RFC on the mailing list:
> http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html
>
> Differential revision: https://reviews.llvm.org/D56322
>
> Added:
> lldb/trunk/include/lldb/API/SBReproducer.h
> lldb/trunk/source/API/SBReproducer.cpp
> lldb/trunk/source/API/SBReproducerPrivate.h
> Modified:
> lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h
> lldb/trunk/source/API/CMakeLists.txt
> lldb/trunk/source/Utility/ReproducerInstrumentation.cpp
> lldb/trunk/tools/driver/Driver.cpp
> lldb/trunk/unittests/Utility/ReproducerInstrumentationTest.cpp
>
> Added: lldb/trunk/include/lldb/API/SBReproducer.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBReproducer.h?rev=353324&view=auto
>
> ==
> --- lldb/trunk/include/lldb/API/SBReproducer.h (added)
> +++ lldb/trunk/include/lldb/API/SBReproducer.h Wed Feb  6 10:57:42 2019
> @@ -0,0 +1,23 @@
> +//===-- SBReproducer.h --*- C++
> -*-===//
> +//
> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM
> Exceptions.
> +// See https://llvm.org/LICENSE.txt for license information.
> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> +//
>
> +//===--===//
> +
> +#ifndef LLDB_API_SBREPRODUCER_H
> +#define LLDB_API_SBREPRODUCER_H
> +
> +#include "lldb/lldb-defines.h"
> +
> +namespace lldb {
> +
> +class LLDB_API SBReproducer {
> +public:
> +  static bool Replay();
> +};
> +
> +} // namespace lldb
> +
> +#endif
>
> Modified: lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h?rev=353324&r1=353323&r2=353324&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h (original)
> +++ lldb/trunk/include/lldb/Utility/ReproducerInstrumentation.h Wed Feb  6
> 10:57:42 2019
> @@ -1,5 +1,4 @@
>  //===-- ReproducerInstrumentation.h -*- C++
> -*-===//
> -//
>  // Part of the LLVM Project, under the Apache License v2.0 with LLVM
> Exceptions.
>  // See https://llvm.org/LICENSE.txt for license information.
>  // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> @@ -18,7 +17,104 @@
>  #include "llvm/Support/ErrorHandling.h"
>
>  #include 
> -#include 
> +
> +#define LLDB_REGISTER_CONSTRUCTOR(Class, Signature)
>   \
> +  Register(&construct::doit)
> +#define LLDB_REGISTER_METHOD(Result, Class, Method, Signature)
>  \
> +  Register(&invoke Signature>::method<&Class::Method>::doit)
> +#define LLDB_REGISTER_METHOD_CONST(Result, Class, Method, Signature)
>  \
> +  Register(&invoke   \
> +   Signature
> const>::method_const<&Class::Method>::doit)
> +#define LLDB_REGISTER_STATIC_METHOD(Result, Class, Method, Signature)
>   \
> +  Register(static_cast Signature>(&Class::Method))
> +
> +#define LLDB_RECORD_CONSTRUCTOR(Class, Signature, ...)
>  \
> +  if (lldb_private::repro::InstrumentationData data =
>   \
> +  LLDB_GET_INSTRUMENTATION_DATA()) {
>  \
> +lldb_private::repro::Recorder sb_recorder(
>  \
> +data.GetSerializer(), data.GetRegistry(), LLVM_PRETTY_FUNCTION);
>  \
> +sb_recorder.Record(&lldb_private::repro::construct Signature>::doit, \
> +   __VA_ARGS__);
>  \
> +sb_recorder.RecordResult(this);
>   \
> +  }
> +
> +#define LLDB_RECORD_CONSTRUCTOR_NO_ARGS(Class)
>  \
> +  if (lldb_private::repro::InstrumentationData data =
>   \
> +  LLDB_GET_INSTRUMENTATION_DATA()) {
>  \
> +lldb_private::repro::Recorder sb_recorder(
>  \
> +data.GetSerializer(), data.GetRegistry(), LLVM_PRETTY_FUNCTION);
>  \
> +sb_recorder.Record(&lldb_private::repro::construct::doit);
>   \
> +sb_recorder.RecordResult(this);
>   \
> +  }
> +
> +#define LLDB_RECORD_METHOD(Result, Class, Method, Signature, ...)
>   \
> +  llvm::Optional sb_recorder;
>  \
> +  if (lldb_private::repro::InstrumentationData data =
>   \
> +

[Lldb-commits] [lldb] r353663 - Update files to the new header that were incorrectly landed with the old

[Chandler Carruth via lldb-commits]

Author: chandlerc
Date: Mon Feb 11 00:03:41 2019
New Revision: 353663

URL: http://llvm.org/viewvc/llvm-project?rev=353663&view=rev
Log:
Update files to the new header that were incorrectly landed with the old
one.

Modified:
lldb/trunk/source/API/SBReproducer.cpp
lldb/trunk/source/API/SBReproducerPrivate.h

Modified: lldb/trunk/source/API/SBReproducer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBReproducer.cpp?rev=353663&r1=353662&r2=353663&view=diff
==
--- lldb/trunk/source/API/SBReproducer.cpp (original)
+++ lldb/trunk/source/API/SBReproducer.cpp Mon Feb 11 00:03:41 2019
@@ -1,9 +1,8 @@
 //===-- SBReproducer.cpp *- C++ 
-*-===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 

Modified: lldb/trunk/source/API/SBReproducerPrivate.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBReproducerPrivate.h?rev=353663&r1=353662&r2=353663&view=diff
==
--- lldb/trunk/source/API/SBReproducerPrivate.h (original)
+++ lldb/trunk/source/API/SBReproducerPrivate.h Mon Feb 11 00:03:41 2019
@@ -1,10 +1,9 @@
 //===-- SBReproducerPrivate.h ---*- C++ 
-*-===//
 //
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D24369: [support] copying JSON parser/writer from lldb

[Chandler Carruth via lldb-commits]

chandlerc added a comment.

In https://reviews.llvm.org/D24369#538472, @zturner wrote:

> In https://reviews.llvm.org/D24369#538422, @aizatsky wrote:
>
> > > I'm a bit surprised there's not already a json parser in LLVM.  Maybe 
> > > there's a reason for it.  I think this CL needs a few more reviewers on 
> > > the LLVM side, so I'm adding a few people.
> >
>


There is already a JSON parser in LLVM.

> > I can't actually find json parser within clang-tidy. Only references that I 
> > see lead eventually to YAML parsing:

> 

> 

> I was thinking of `lib/Tooling/JSONCompilationDatabase`, but looking at it, 
> it seems to be pretty specialized and doesn't support arbitrary JSON.


It uses the YAML parser because JSON is a strict subset of YAML: 
https://en.wikipedia.org/wiki/JSON#YAML

Please don't add a JSON parser to LLVM. I would much rather teach LLDB to use 
the YAML parser and improve that parser if and where useful.


https://reviews.llvm.org/D24369



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r256616 - [ptr-traits] Add an #include to provide the complete type for Section

[Chandler Carruth via lldb-commits]

Author: chandlerc
Date: Tue Dec 29 21:48:24 2015
New Revision: 256616

URL: http://llvm.org/viewvc/llvm-project?rev=256616&view=rev
Log:
[ptr-traits] Add an #include to provide the complete type for Section
which is the pointee in a pointer keyed DenseMap.

Pointer keys in a DenseMap have their low bits used by the map
implementation and in order to do this safely we need to know the
alignment of the pointer. We can only do this if we have the complete
type of the pointee. This is part of larger cleanup across LLVM and
subprojects to allow us to start enforcing this strictly.

Modified:
lldb/trunk/include/lldb/Target/SectionLoadList.h

Modified: lldb/trunk/include/lldb/Target/SectionLoadList.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/SectionLoadList.h?rev=256616&r1=256615&r2=256616&view=diff
==
--- lldb/trunk/include/lldb/Target/SectionLoadList.h (original)
+++ lldb/trunk/include/lldb/Target/SectionLoadList.h Tue Dec 29 21:48:24 2015
@@ -18,6 +18,7 @@
 #include "llvm/ADT/DenseMap.h"
 // Project includes
 #include "lldb/lldb-public.h"
+#include "lldb/Core/Section.h"
 #include "lldb/Host/Mutex.h"
 
 namespace lldb_private {


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] 3bea730 - [lldb] Fix compilation with gcc-6.5

[Chandler Carruth via lldb-commits]

+Tom Stellard  - Could this get cherry-picked into
12.0.N for the next point release? Without it, LLDB in the 12 release
doesn't build with GCC <= 6.5 which the docs indicate is supposed to work.

On Wed, Mar 31, 2021 at 11:45 PM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

>
> Author: Pavel Labath
> Date: 2021-04-01T08:44:50+02:00
> New Revision: 3bea7306e8669f94bacafae68748a9139cfc0b98
>
> URL:
> https://github.com/llvm/llvm-project/commit/3bea7306e8669f94bacafae68748a9139cfc0b98
> DIFF:
> https://github.com/llvm/llvm-project/commit/3bea7306e8669f94bacafae68748a9139cfc0b98.diff
>
> LOG: [lldb] Fix compilation with gcc-6.5
>
> This fixes (works around) two errors with gcc-6.5.
> - in the RegisterContext_x86 files, gcc is unable to synthesize a
>   default constructor -- it thinks it needs to initialize the virtual
>   base class, even though said classes are abstract. I fix that by
>   providing a dummy constructor.
> - In ReproducerInstrumentationTest, it is not able to deduce that the
>   TestingRegistry class is movable (it contains a map of unique
>   pointers). I change the type from Optional to
>   unique_ptr   (copying/moving a polymorphic type is not a very good idea in any
>   case).
>
> Added:
>
>
> Modified:
> lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> lldb/unittests/Utility/ReproducerInstrumentationTest.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git
> a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> index dfd0106837853..7d5ea575269dc 100644
> --- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> +++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> @@ -58,6 +58,12 @@ class NativeRegisterContextLinux
>virtual llvm::Optional GetMmapData() { return llvm::None; }
>
>  protected:
> +  // NB: This constructor is here only because gcc<=6.5 requires a
> virtual base
> +  // class initializer on abstract class (even though it is never used).
> It can
> +  // be deleted once we move to gcc>=7.0.
> +  NativeRegisterContextLinux(NativeThreadProtocol &thread)
> +  : NativeRegisterContextRegisterInfo(thread, nullptr) {}
> +
>lldb::ByteOrder GetByteOrder() const;
>
>virtual Status ReadRegisterRaw(uint32_t reg_index, RegisterValue
> ®_value);
>
> diff  --git
> a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> index c197d70825b4b..bd4b168f4964e 100644
> ---
> a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> +++
> b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> @@ -292,6 +292,8 @@
> NativeRegisterContextLinux_x86_64::NativeRegisterContextLinux_x86_64(
>  const ArchSpec &target_arch, NativeThreadProtocol &native_thread)
>  : NativeRegisterContextRegisterInfo(
>native_thread, CreateRegisterInfoInterface(target_arch)),
> +  NativeRegisterContextLinux(native_thread),
> +  NativeRegisterContextDBReg_x86(native_thread),
>m_xstate_type(XStateType::Invalid), m_ymm_set(), m_mpx_set(),
>m_reg_info(), m_gpr_x86_64() {
>// Set up data about ranges of valid registers.
>
> diff  --git
> a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> index c0c6ce29eab53..a4ed8bfb97eaf 100644
> --- a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> +++ b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> @@ -16,6 +16,12 @@ namespace lldb_private {
>  class NativeRegisterContextDBReg_x86
>  : public virtual NativeRegisterContextRegisterInfo {
>  public:
> +  // NB: This constructor is here only because gcc<=6.5 requires a
> virtual base
> +  // class initializer on abstract class (even though it is never used).
> It can
> +  // be deleted once we move to gcc>=7.0.
> +  NativeRegisterContextDBReg_x86(NativeThreadProtocol &thread)
> +  : NativeRegisterContextRegisterInfo(thread, nullptr) {}
> +
>Status IsWatchpointHit(uint32_t wp_index, bool &is_hit) override;
>
>Status GetWatchpointHitIndex(uint32_t &wp_index,
>
> diff  --git a/lldb/unittests/Utility/ReproducerInstrumentationTest.cpp
> b/lldb/unittests/Utility/ReproducerInstrumentationTest.cpp
> index e9f6fcf34e17f..ce259c5969e09 100644
> --- a/lldb/unittests/Utility/ReproducerInstrumentationTest.cpp
> +++ b/lldb/unittests/Utility/ReproducerInstrumentationTest.cpp
> @@ -50,7 +50,7 @@ class TestingRegistry : public Registry {
>TestingRegistry();
>  };
>
> -static llvm::Optional g_registry;
> +static std::unique_ptr g_registry;
>

Re: [Lldb-commits] [lldb] 3bea730 - [lldb] Fix compilation with gcc-6.5

[Chandler Carruth via lldb-commits]

On Tue, Jun 15, 2021 at 4:29 PM Tom Stellard  wrote:

> On 6/15/21 4:28 PM, Chandler Carruth wrote:
> > +Tom Stellard  - Could this get
> cherry-picked into 12.0.N for the next point release? Without it, LLDB in
> the 12 release doesn't build with GCC <= 6.5 which the docs indicate is
> supposed to work.
> >
>
> Can you file a bug for this?
>

Sure https://bugs.llvm.org/show_bug.cgi?id=50732

>
> -Tom
>
> > On Wed, Mar 31, 2021 at 11:45 PM Pavel Labath via lldb-commits <
> lldb-commits@lists.llvm.org > wrote:
> >
> >
> > Author: Pavel Labath
> > Date: 2021-04-01T08:44:50+02:00
> > New Revision: 3bea7306e8669f94bacafae68748a9139cfc0b98
> >
> > URL:
> https://github.com/llvm/llvm-project/commit/3bea7306e8669f94bacafae68748a9139cfc0b98
> <
> https://github.com/llvm/llvm-project/commit/3bea7306e8669f94bacafae68748a9139cfc0b98
> >
> > DIFF:
> https://github.com/llvm/llvm-project/commit/3bea7306e8669f94bacafae68748a9139cfc0b98.diff
> <
> https://github.com/llvm/llvm-project/commit/3bea7306e8669f94bacafae68748a9139cfc0b98.diff
> >
> >
> > LOG: [lldb] Fix compilation with gcc-6.5
> >
> > This fixes (works around) two errors with gcc-6.5.
> > - in the RegisterContext_x86 files, gcc is unable to synthesize a
> >default constructor -- it thinks it needs to initialize the
> virtual
> >base class, even though said classes are abstract. I fix that by
> >providing a dummy constructor.
> > - In ReproducerInstrumentationTest, it is not able to deduce that the
> >TestingRegistry class is movable (it contains a map of unique
> >pointers). I change the type from Optional to
> >unique_ptr >(copying/moving a polymorphic type is not a very good idea in any
> >case).
> >
> > Added:
> >
> >
> > Modified:
> >  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> >
> lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> >
> lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> >  lldb/unittests/Utility/ReproducerInstrumentationTest.cpp
> >
> > Removed:
> >
> >
> >
> >
>  
> 
> > diff  --git
> a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> > index dfd0106837853..7d5ea575269dc 100644
> > --- a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> > +++ b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h
> > @@ -58,6 +58,12 @@ class NativeRegisterContextLinux
> > virtual llvm::Optional GetMmapData() { return
> llvm::None; }
> >
> >   protected:
> > +  // NB: This constructor is here only because gcc<=6.5 requires a
> virtual base
> > +  // class initializer on abstract class (even though it is never
> used). It can
> > +  // be deleted once we move to gcc>=7.0.
> > +  NativeRegisterContextLinux(NativeThreadProtocol &thread)
> > +  : NativeRegisterContextRegisterInfo(thread, nullptr) {}
> > +
> > lldb::ByteOrder GetByteOrder() const;
> >
> > virtual Status ReadRegisterRaw(uint32_t reg_index, RegisterValue
> ®_value);
> >
> > diff  --git
> a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> > index c197d70825b4b..bd4b168f4964e 100644
> > ---
> a/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> > +++
> b/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_x86_64.cpp
> > @@ -292,6 +292,8 @@
> NativeRegisterContextLinux_x86_64::NativeRegisterContextLinux_x86_64(
> >   const ArchSpec &target_arch, NativeThreadProtocol
> &native_thread)
> >   : NativeRegisterContextRegisterInfo(
> > native_thread, CreateRegisterInfoInterface(target_arch)),
> > +  NativeRegisterContextLinux(native_thread),
> > +  NativeRegisterContextDBReg_x86(native_thread),
> > m_xstate_type(XStateType::Invalid), m_ymm_set(), m_mpx_set(),
> > m_reg_info(), m_gpr_x86_64() {
> > // Set up data about ranges of valid registers.
> >
> > diff  --git
> a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> > index c0c6ce29eab53..a4ed8bfb97eaf 100644
> > ---
> a/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> > +++
> b/lldb/source/Plugins/Process/Utility/NativeRegisterContextDBReg_x86.h
> > @@ -16,6 +16,12 @@ namespace lldb_private {
> >   class NativeRegisterContextDBReg_x86
> >   : public virtual NativeRegisterContextRegisterInfo {
> >   public:
> > +  // NB: This constructor is here only because gcc<=

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

chandlerc wrote:

> If you look for:
> 
> ```
> FAILED: 
> �[0mtools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CompileCommands.cpp.o
>  
> ```
> 
> In the build log that's the failure reason.

NP, and thanks. Sorry I missed that set of tests. Pushed a fix that makes 
`check-clang-tools` clean.

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

@@ -53,10 +53,8 @@ class OptTable {
 public:
   /// Entry for a single option instance in the option data table.
   struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+unsigned PrefixesOffset;

chandlerc wrote:

FWIW, I put together a simple abstraction here: 
https://github.com/llvm/llvm-project/pull/119488

Happy for suggestions on a stronger one, a different API, etc.

My preference would be to land independently and then connect. But if you'd 
like to see one or the other land first and roll in, let me know.

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

@@ -80,15 +78,56 @@ class OptTable {
 const char *AliasArgs;
 const char *Values;
 
-StringRef getName() const {
-  unsigned PrefixLength = Prefixes.empty() ? 0 : Prefixes[0].size();
-  return PrefixedName.drop_front(PrefixLength);
+bool hasNoPrefix() const { return PrefixesOffset == 0; }
+
+unsigned getNumPrefixes(ArrayRef PrefixesTable) const {
+  return PrefixesTable[PrefixesOffset];
+}
+
+ArrayRef
+getPrefixOffsets(ArrayRef PrefixesTable) const {
+  return hasNoPrefix() ? ArrayRef()
+   : PrefixesTable.slice(PrefixesOffset + 1,
+ 
getNumPrefixes(PrefixesTable));
+}
+
+void appendPrefixes(const char *StrTable, ArrayRef PrefixesTable,
+SmallVectorImpl &Prefixes) const {
+  for (unsigned PrefixOffset : getPrefixOffsets(PrefixesTable))
+Prefixes.push_back(&StrTable[PrefixOffset]);
+}
+
+StringRef getPrefix(const char *StrTable, ArrayRef PrefixesTable,
+unsigned PrefixIndex) const {
+  return &StrTable[getPrefixOffsets(PrefixesTable)[PrefixIndex]];
+}
+
+StringRef getPrefixedName(const char *StrTable) const {
+  return &StrTable[PrefixedNameOffset];
+}
+
+StringRef getName(const char *StrTable,
+  ArrayRef PrefixesTable) const {
+  unsigned PrefixLength =
+  hasNoPrefix() ? 0 : getPrefix(StrTable, PrefixesTable, 0).size();
+  return getPrefixedName(StrTable).drop_front(PrefixLength);
 }
   };
 
 private:
+  // A unified string table for these options. Individual strings are stored as
+  // null terminated C-strings at offsets within this table.
+  const char *StrTable;

chandlerc wrote:

Happy to use a `StringRef` if folks want here.

I'm not sure about the exact construction though -- I think it'll be annoyingly 
important that we use something that gets the accelerated implementations of 
`strlen` when extracting strings from the table. And not sure that `StringRef` 
has a good tool for doing that in a way that *also* tracks a bound.

But what's your preference about me cutting `StringRef` into the code as-is, 
versus waiting and coming back through to add a dedicated string table 
abstraction? Because that would let us have much nicer APIs compared to lifting 
this into `StringRef`. And it'll have to touch almost exactly the same lines I 
think.

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

@@ -845,13 +845,14 @@ MemoryBufferRef 
LinkerDriver::convertResToCOFF(ArrayRef mbs,
 
 // Create OptTable
 
+#define OPTTABLE_STR_TABLE_CODE

chandlerc wrote:

I have no idea. It took a lot of work to get even this to work, figuring out 
each of the different ways that these macros fail.

Unless its impossible to get this reviewed as-is, I'd really rather not add an 
intermediate state that is entirely artificial compared to what is here...

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

@@ -53,10 +53,8 @@ class OptTable {
 public:
   /// Entry for a single option instance in the option data table.
   struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+unsigned PrefixesOffset;

chandlerc wrote:

Maybe? I'm not opposed to adding a string table abstraction similar to what 
you're mentioning -- I would probably strucutre it a bit the other way around 
but that's neither here nor there.

That said, could that be a follow-up rather than blocking? There are many uses 
of raw string tables and `unsigned` indices for them from TableGen-ed code 
already, and so I don't feel like this is a terribly problematic intermediate 
state.

And it should be relatively trivial to switch this code to use the abstraction 
once its using tables everywhere. The much more disruptive change I've found is 
getting the existing code to use tables at all.

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

@@ -53,10 +53,8 @@ class OptTable {
 public:
   /// Entry for a single option instance in the option data table.
   struct Info {
-/// A null terminated array of prefix strings to apply to name while
-/// matching.
-ArrayRef Prefixes;
-StringLiteral PrefixedName;
+unsigned PrefixesOffset;
+unsigned PrefixedNameOffset;
 const char *HelpText;

chandlerc wrote:

Yep, I stopped at the "smallest" increment where it seemed self-cohesive.

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

https://github.com/chandlerc edited 
https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

chandlerc wrote:

Thanks for the careful review, merging! (And starting on the follow-ups!)

https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [clang-tools-extra] [lld] [lldb] [llvm] Rework the `Option` library to reduce dynamic relocations (PR #119198)

[Chandler Carruth via lldb-commits]

https://github.com/chandlerc closed 
https://github.com/llvm/llvm-project/pull/119198
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [StrTable] Switch the option parser to `llvm::StringTable` (PR #123308)

[Chandler Carruth via lldb-commits]

@@ -117,13 +121,13 @@ class OptTable {
 private:
   // A unified string table for these options. Individual strings are stored as
   // null terminated C-strings at offsets within this table.
-  const char *StrTable;
+  const StringTable *StrTable;

chandlerc wrote:

Using a const reference makes the type unassignable (without UB) sadly, because 
references can't be re-bound.

Technically, this type could probably be unassignable, but I always prefer 
regular types that don't have complex constraints like that and so I much 
prefer pointers rather than references as members.

That said, if there is a strong preference, I can try switching to a reference 
and see if I can get it all to compile.

https://github.com/llvm/llvm-project/pull/123308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [StrTable] Switch the option parser to `llvm::StringTable` (PR #123308)

[Chandler Carruth via lldb-commits]

@@ -33,25 +33,26 @@ using namespace llvm::opt;
 
 namespace {
 struct OptNameLess {
-  const char *StrTable;
-  ArrayRef PrefixesTable;
+  const StringTable *StrTable;

chandlerc wrote:

(same as above)

https://github.com/llvm/llvm-project/pull/123308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [StrTable] Switch the option parser to `llvm::StringTable` (PR #123308)

[Chandler Carruth via lldb-commits]

https://github.com/chandlerc closed 
https://github.com/llvm/llvm-project/pull/123308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] Patch series to reapply #118734 and substantially improve it (PR #120534)

[Chandler Carruth via lldb-commits]

chandlerc wrote:

@dyung - OK, I think the current just-pushed version of this PR is worth 
another test.

I've taught the TableGen string table emission to go back to working around the 
MSVC issues using a different table form that we used to use in LLVM when MSVC 
had a reliable error on it. It appears that now it only sometimes gets 
miscompiled, and so this workaround got accidentally removed without really 
being in a reliable place.

But that still requires that all of the large string tables go through TableGen 
to get emitted in this form. So I've sent two PRs (separately, they seem 
independently good) to move NVPTX and Hexagon to TableGen, and this PR contains 
patches to move more of the ARM builtins to TableGen.

I *think* this gets all of the ones that produced too-large string tables, but 
testing should show. Let me know. If this works and there isn't a really short 
path to upgrade, I'll start pulling some of the pre-requisite PRs out for 
independent review, and then update this PR once I'm down to the minimal chain 
of PRs that do the full conversion of builtins to string tables.

Thanks,
-Chandler

https://github.com/llvm/llvm-project/pull/120534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] Patch series to reapply #118734 and substantially improve it (PR #120534)

[Chandler Carruth via lldb-commits]

chandlerc wrote:

> Some good news, everything seems to pass after your latest changes in this 
> PR! I didn't believe it at first and did a clean rebuild and test to verify. 
> In the end everything passed again.
> 
> That being said, I am working on deploying an updated version of VS2019 to 
> our internal builders. I have gotten agreement with the plan, the only 
> possible hold-up is that we would need to rebuild our internal builders which 
> likely may not get done for a few weeks. I can apply quick work-arounds to 
> the machines, but they ultimately will need to be rebuilt.
> 
> Would you prefer to move forward with the solution currently implemented in 
> this PR or for us to update our internal builders?

Let's see if we can land the solution in this PR. Now that its done, it'll 
remove all time pressure on upgrading.

Mostly need code review on all the factored out PRs, currently:

- [ ] #123308 
- [ ] #123302
- [ ] #123548 
- [ ] #122873 
- [ ] #123460

Once all of those land, I can polish this up a bit to make it easier to review 
the latest version.

https://github.com/llvm/llvm-project/pull/120534
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [StrTable] Switch intrinsics to StringTable and work around MSVC (PR #123548)

[Chandler Carruth via lldb-commits]

https://github.com/chandlerc created 
https://github.com/llvm/llvm-project/pull/123548

**Note:** This PR depends on #123302 and #123308 -- only the last of the three 
commits should be reviewed here.

---

Historically, the main example of *very* large string tables used the
`EmitCharArray` to work around MSVC limitations with string literals,
but that was switched (without removing the API) in order to consolidate
on a nicer emission primitive.

While this large string table in `IntrinsicsImpl.inc` seems to compile
correctly on MSVC without the work around in `EmitCharArray` (and that
this PR adds back to the nicer emission path), other users have
repeatedly hit this MSVC limitation as you can see in the discussion on
PR https://github.com/llvm/llvm-project/pull/120534. This PR teaches the string 
offset table emission to look at
the size of the table and switch to the char array emission strategy
when the table becomes too large.

This work around does have the downside of making compile times worse
for large string tables, but that appears unavoidable until we can
identify known good MSVC versions and switch to requiring them for all
LLVM users. It also reduces searchability of the generated string table
-- I looked at emitting a comment with each string but it is tricky
because the escaping rules for an inline comment are different from
those of of a string literal, and there's no real way to turn the string
literal into a comment.

This PR also switches the `IntrinsicsImpl.inc` string tables over to the
new `StringTable` runtime abstraction. I didn't want to do this until
landing the MSVC workaround in case it caused even this example to start
hitting the MSVC bug, but I wanted to switch here so that I could
simplify the API for emitting the string table with the workaround
present. With the two different emission strategies, its important to
use a very exact syntax and that seems better encapsulated in the API.

This PR should unblock landing https://github.com/llvm/llvm-project/pull/120534 
and letting us switch all of
Clang's builtins to use string tables. That PR has all the details
motivating the overall effort.

Follow-up patches will try to consolidate the remaining users onto the
single interface, but those at least were easy to separate into
follow-ups and keep this PR somewhat smaller.

>From 9a525fa4322d6a46154305097185ec017916d01f Mon Sep 17 00:00:00 2001
From: Chandler Carruth 
Date: Fri, 17 Jan 2025 08:50:44 +
Subject: [PATCH 1/3] [StrTable] Switch the option parser to
 `llvm::StringTable`

Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over to it rather than using a raw
`const char*`. Also try to use the `StringTable::Offset` type rather
than a raw `unsigned` where we can to avoid accidental increments or
other issues.

This is based on review feedback for the initial switch of options to
a string table. Happy to tweak or adjust if desired here.
---
 clang/lib/Frontend/CompilerInvocation.cpp |  2 +-
 .../Platform/MacOSX/PlatformDarwin.cpp|  3 +-
 llvm/include/llvm/Option/OptTable.h   | 67 ++
 llvm/lib/Option/OptTable.cpp  | 70 ++-
 llvm/tools/llvm-objdump/llvm-objdump.cpp  |  3 +-
 .../Option/OptionMarshallingTest.cpp  |  3 +-
 llvm/utils/TableGen/OptionParserEmitter.cpp   | 11 +--
 7 files changed, 88 insertions(+), 71 deletions(-)

diff --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 58658dedbaf1ee..3bf124e4827be9 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -282,7 +282,7 @@ using ArgumentConsumer = 
CompilerInvocation::ArgumentConsumer;
 #undef OPTTABLE_STR_TABLE_CODE
 
 static llvm::StringRef lookupStrInTable(unsigned Offset) {
-  return &OptionStrTable[Offset];
+  return OptionStrTable[Offset];
 }
 
 #define SIMPLE_ENUM_VALUE_TABLE
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index 2a36f95c94d0ce..51e9a6d81b8390 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -42,6 +42,7 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/Timer.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringTable.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Threading.h"
@@ -1083,7 +1084,7 @@ void 
PlatformDarwin::AddClangModuleCompilationOptionsForSDKType(
   if (!version.empty() && sdk_type != XcodeSDK::Type::Linux &&
   sdk_type != XcodeSDK::Type::XROS) {
 #define OPTION(PREFIX_OFFSET, NAME_OFFSET, VAR, ...)   
\
-  llvm::StringRef opt_##VAR = &OptionStrTable[NAME_OFFSET];
\
+  llvm::StringRef opt_##VAR = OptionStrTable[NAME_OFFSET]; 
\
   (void)opt_##V

[Lldb-commits] [clang] [lldb] [llvm] [StrTable] Switch the option parser to `llvm::StringTable` (PR #123308)

[Chandler Carruth via lldb-commits]

chandlerc wrote:

Ping

https://github.com/llvm/llvm-project/pull/123308
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [clang] [lldb] [llvm] [StrTable] Switch the option parser to `llvm::StringTable` (PR #123308)

[Chandler Carruth via lldb-commits]

https://github.com/chandlerc created 
https://github.com/llvm/llvm-project/pull/123308

Now that we have a dedicated abstraction for string tables, switch the option 
parser library's string table over to it rather than using a raw `const char*`. 
Also try to use the `StringTable::Offset` type rather than a raw `unsigned` 
where we can to avoid accidental increments or other issues.

This is based on review feedback for the initial switch of options to a string 
table. Happy to tweak or adjust if desired here.

>From 9a525fa4322d6a46154305097185ec017916d01f Mon Sep 17 00:00:00 2001
From: Chandler Carruth 
Date: Fri, 17 Jan 2025 08:50:44 +
Subject: [PATCH] [StrTable] Switch the option parser to `llvm::StringTable`

Now that we have a dedicated abstraction for string tables, switch the
option parser library's string table over to it rather than using a raw
`const char*`. Also try to use the `StringTable::Offset` type rather
than a raw `unsigned` where we can to avoid accidental increments or
other issues.

This is based on review feedback for the initial switch of options to
a string table. Happy to tweak or adjust if desired here.
---
 clang/lib/Frontend/CompilerInvocation.cpp |  2 +-
 .../Platform/MacOSX/PlatformDarwin.cpp|  3 +-
 llvm/include/llvm/Option/OptTable.h   | 67 ++
 llvm/lib/Option/OptTable.cpp  | 70 ++-
 llvm/tools/llvm-objdump/llvm-objdump.cpp  |  3 +-
 .../Option/OptionMarshallingTest.cpp  |  3 +-
 llvm/utils/TableGen/OptionParserEmitter.cpp   | 11 +--
 7 files changed, 88 insertions(+), 71 deletions(-)

diff --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 58658dedbaf1ee..3bf124e4827be9 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -282,7 +282,7 @@ using ArgumentConsumer = 
CompilerInvocation::ArgumentConsumer;
 #undef OPTTABLE_STR_TABLE_CODE
 
 static llvm::StringRef lookupStrInTable(unsigned Offset) {
-  return &OptionStrTable[Offset];
+  return OptionStrTable[Offset];
 }
 
 #define SIMPLE_ENUM_VALUE_TABLE
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp 
b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index 2a36f95c94d0ce..51e9a6d81b8390 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -42,6 +42,7 @@
 #include "lldb/Utility/Status.h"
 #include "lldb/Utility/Timer.h"
 #include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringTable.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Threading.h"
@@ -1083,7 +1084,7 @@ void 
PlatformDarwin::AddClangModuleCompilationOptionsForSDKType(
   if (!version.empty() && sdk_type != XcodeSDK::Type::Linux &&
   sdk_type != XcodeSDK::Type::XROS) {
 #define OPTION(PREFIX_OFFSET, NAME_OFFSET, VAR, ...)   
\
-  llvm::StringRef opt_##VAR = &OptionStrTable[NAME_OFFSET];
\
+  llvm::StringRef opt_##VAR = OptionStrTable[NAME_OFFSET]; 
\
   (void)opt_##VAR;
 #include "clang/Driver/Options.inc"
 #undef OPTION
diff --git a/llvm/include/llvm/Option/OptTable.h 
b/llvm/include/llvm/Option/OptTable.h
index 38a03fef7ae124..61a58aa304ecb4 100644
--- a/llvm/include/llvm/Option/OptTable.h
+++ b/llvm/include/llvm/Option/OptTable.h
@@ -12,6 +12,7 @@
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/StringTable.h"
 #include "llvm/Option/OptSpecifier.h"
 #include "llvm/Support/StringSaver.h"
 #include 
@@ -54,7 +55,7 @@ class OptTable {
   /// Entry for a single option instance in the option data table.
   struct Info {
 unsigned PrefixesOffset;
-unsigned PrefixedNameOffset;
+StringTable::Offset PrefixedNameOffset;
 const char *HelpText;
 // Help text for specific visibilities. A list of pairs, where each pair
 // is a list of visibilities and a specific help string for those
@@ -80,34 +81,37 @@ class OptTable {
 
 bool hasNoPrefix() const { return PrefixesOffset == 0; }
 
-unsigned getNumPrefixes(ArrayRef PrefixesTable) const {
-  return PrefixesTable[PrefixesOffset];
+unsigned getNumPrefixes(ArrayRef PrefixesTable) const 
{
+  // We embed the number of prefixes in the value of the first offset.
+  return PrefixesTable[PrefixesOffset].value();
 }
 
-ArrayRef
-getPrefixOffsets(ArrayRef PrefixesTable) const {
-  return hasNoPrefix() ? ArrayRef()
+ArrayRef
+getPrefixOffsets(ArrayRef PrefixesTable) const {
+  return hasNoPrefix() ? ArrayRef()
: PrefixesTable.slice(PrefixesOffset + 1,
  
getNumPrefixes(PrefixesTable));
 }
 
-void appendPrefixes(const char *StrTable, ArrayRef PrefixesTable,
+void appendPrefixes(const StringTable &StrTable,