Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
When you add to them you are often adding some larger feature which would have
required a rebuild anyway, and they go long times with no change... I have
never found the rebuild required when these files are touched to be a drag on
my productivity. And I really appreciate their convenience.
But thanks for your friendly advice.
Jim
> On May 15, 2019, at 3:30 PM, Eric Christopher wrote:
>
> The dependency edges caused by the file means that any time anyone
> touches that file everything that depends on it is rebuilt. The way
> it's included basically means you're doing a full build any time you
> touch it. It's who is depending on this file or any file this file
> includes, not the other way around.
>
> If no one is expected to touch it then it's probably ok. It looks like
> each of the files (lldb/include/lldb/lldb-*.h) is touched ~ once every
> few weeks. Mostly I was looking at the edit-compile-debug cycle of the
> person working on the patch. Means about once a month someone working
> on a patch has to do a much more significant set of rebuilds than
> they'd already have to do because of their patch rather than a much
> more minimal set of rebuilds.
>
> As far as having a convenient place to put public headers I do agree,
> but I'd probably prefer to see that via autogenerated documentation
> rather than a set of forward declarations in a single header.
>
> Anyhow, your mileage may vary. Just giving the thoughts around the
> rest of the llvm project :)
>
> -eric
>
> On Wed, May 15, 2019 at 3:13 PM Jim Ingham wrote:
>>
>> This is a common header file that specifies either common enums & #defines
>> in lldb, or forward declarations of the common classes in lldb. They don't
>> depend on any other header files in the system, they just establish the
>> common names you should use. So the dependency analysis introduced by these
>> files should be trivial - they really don't depend on anything else. And
>> the only time you change them is when you add a new public type or define to
>> lldb, which doesn't happen very often.
>>
>> But it is very convenient to have a common global set of names for the
>> public entities in lldb, that can be looked up in one place, etc. You can't
>> actually USE any of the classes from these header files, so they don't
>> obscure what other source files actually use - one problem with the big
>> mongo "Cocoa.h" header file pattern. If you want to get the class
>> definition of anything, you have to include the specific .h file for that
>> thing. This is just a list of forward declarations. Switching to
>>
>> I haven't done your experiment, but if "I depend on a header that either
>> includes no other files or straight includes another file" really is a
>> significant burden on the dependency analysis, then I'm not sure this
>> pattern is actually the problem.
>>
>> Jim
>>
>>> On May 15, 2019, at 1:55 PM, Eric Christopher wrote:
>>>
>>> A couple of perspectives FWIW:
>>>
>>> a) Header file includes increase overall dependencies which affects
>>> incremental rebuild time whenever you touch something. Especially more
>>> when that header is included into multiple headers that are then
>>> included into an array of translation units
>>> b) Having each file contain the forward declarations it needs from the
>>> project and no more also will help both compile time and understanding
>>> what's used in any particular header.
>>>
>>> As a related exercise:
>>>
>>> https://twitter.com/echristo/status/1116609586004316160
>>>
>>> basically has removing a couple of transitive dependencies saving in
>>> excess of 70% of the incremental rebuild time after touching a file.
>>> This seems significant. :)
>>>
>>> -eric
>>>
>>> On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
>>> wrote:
This commit makes things look a little cleaner, but do we need any of
these forward declarations at all?
Most of these files either directly include lldb-forward.h or get it from
lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a
general practice we've been getting all the lldb_private type forward
declarations this way rather than cluttering up the .h files with
individual forward declarations. If we are going to keep doing it that
way - which I can't see any reason not to do, then we should just delete
all these forward defines, right?
Jim
> On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits
> wrote:
>
> Author: maskray
> Date: Wed May 15 02:15:13 2019
> New Revision: 360757
>
> URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
> Log:
> Group forward declarations in one namespace lldb_private {}
>
> Modified:
> lldb/trunk/include/lldb/Core/Address.h
> lldb/trunk/include/lldb/Core/AddressRange.h
> lldb/trunk/include/lldb/Core/AddressResolver.h
>
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
The dependency edges caused by the file means that any time anyone
touches that file everything that depends on it is rebuilt. The way
it's included basically means you're doing a full build any time you
touch it. It's who is depending on this file or any file this file
includes, not the other way around.
If no one is expected to touch it then it's probably ok. It looks like
each of the files (lldb/include/lldb/lldb-*.h) is touched ~ once every
few weeks. Mostly I was looking at the edit-compile-debug cycle of the
person working on the patch. Means about once a month someone working
on a patch has to do a much more significant set of rebuilds than
they'd already have to do because of their patch rather than a much
more minimal set of rebuilds.
As far as having a convenient place to put public headers I do agree,
but I'd probably prefer to see that via autogenerated documentation
rather than a set of forward declarations in a single header.
Anyhow, your mileage may vary. Just giving the thoughts around the
rest of the llvm project :)
-eric
On Wed, May 15, 2019 at 3:13 PM Jim Ingham wrote:
>
> This is a common header file that specifies either common enums & #defines in
> lldb, or forward declarations of the common classes in lldb. They don't
> depend on any other header files in the system, they just establish the
> common names you should use. So the dependency analysis introduced by these
> files should be trivial - they really don't depend on anything else. And the
> only time you change them is when you add a new public type or define to
> lldb, which doesn't happen very often.
>
> But it is very convenient to have a common global set of names for the public
> entities in lldb, that can be looked up in one place, etc. You can't
> actually USE any of the classes from these header files, so they don't
> obscure what other source files actually use - one problem with the big mongo
> "Cocoa.h" header file pattern. If you want to get the class definition of
> anything, you have to include the specific .h file for that thing. This is
> just a list of forward declarations. Switching to
>
> I haven't done your experiment, but if "I depend on a header that either
> includes no other files or straight includes another file" really is a
> significant burden on the dependency analysis, then I'm not sure this pattern
> is actually the problem.
>
> Jim
>
> > On May 15, 2019, at 1:55 PM, Eric Christopher wrote:
> >
> > A couple of perspectives FWIW:
> >
> > a) Header file includes increase overall dependencies which affects
> > incremental rebuild time whenever you touch something. Especially more
> > when that header is included into multiple headers that are then
> > included into an array of translation units
> > b) Having each file contain the forward declarations it needs from the
> > project and no more also will help both compile time and understanding
> > what's used in any particular header.
> >
> > As a related exercise:
> >
> > https://twitter.com/echristo/status/1116609586004316160
> >
> > basically has removing a couple of transitive dependencies saving in
> > excess of 70% of the incremental rebuild time after touching a file.
> > This seems significant. :)
> >
> > -eric
> >
> > On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
> > wrote:
> >>
> >> This commit makes things look a little cleaner, but do we need any of
> >> these forward declarations at all?
> >>
> >> Most of these files either directly include lldb-forward.h or get it from
> >> lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a
> >> general practice we've been getting all the lldb_private type forward
> >> declarations this way rather than cluttering up the .h files with
> >> individual forward declarations. If we are going to keep doing it that
> >> way - which I can't see any reason not to do, then we should just delete
> >> all these forward defines, right?
> >>
> >> Jim
> >>
> >>
> >>> On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits
> >>> wrote:
> >>>
> >>> Author: maskray
> >>> Date: Wed May 15 02:15:13 2019
> >>> New Revision: 360757
> >>>
> >>> URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
> >>> Log:
> >>> Group forward declarations in one namespace lldb_private {}
> >>>
> >>> Modified:
> >>> lldb/trunk/include/lldb/Core/Address.h
> >>> lldb/trunk/include/lldb/Core/AddressRange.h
> >>> lldb/trunk/include/lldb/Core/AddressResolver.h
> >>> lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
> >>> lldb/trunk/include/lldb/Core/AddressResolverName.h
> >>> lldb/trunk/include/lldb/Core/Communication.h
> >>> lldb/trunk/include/lldb/Core/Debugger.h
> >>> lldb/trunk/include/lldb/Core/Disassembler.h
> >>> lldb/trunk/include/lldb/Core/EmulateInstruction.h
> >>> lldb/trunk/include/lldb/Core/FileLineResolver.h
> >>> lldb/trunk/include/lldb/Core/FileSpecList.h
> >>> lldb/trunk/include/lldb/Core/FormatEntity.h
> >>>
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
> On May 15, 2019, at 3:13 PM, Jim Ingham wrote:
>
> This is a common header file that specifies either common enums & #defines in
> lldb, or forward declarations of the common classes in lldb. They don't
> depend on any other header files in the system, they just establish the
> common names you should use. So the dependency analysis introduced by these
> files should be trivial - they really don't depend on anything else. And the
> only time you change them is when you add a new public type or define to
> lldb, which doesn't happen very often.
>
> But it is very convenient to have a common global set of names for the public
> entities in lldb, that can be looked up in one place, etc. You can't
> actually USE any of the classes from these header files, so they don't
> obscure what other source files actually use - one problem with the big mongo
> "Cocoa.h" header file pattern. If you want to get the class definition of
> anything, you have to include the specific .h file for that thing. This is
> just a list of forward declarations. Switching to
individual forward declares uglifies the code - as these examples show.
>
> I haven't done your experiment, but if "I depend on a header that either
> includes no other files or straight includes another file" really is a
> significant burden on the dependency analysis, then I'm not sure this pattern
> is actually the problem.
>
> Jim
>
>> On May 15, 2019, at 1:55 PM, Eric Christopher wrote:
>>
>> A couple of perspectives FWIW:
>>
>> a) Header file includes increase overall dependencies which affects
>> incremental rebuild time whenever you touch something. Especially more
>> when that header is included into multiple headers that are then
>> included into an array of translation units
>> b) Having each file contain the forward declarations it needs from the
>> project and no more also will help both compile time and understanding
>> what's used in any particular header.
>>
>> As a related exercise:
>>
>> https://twitter.com/echristo/status/1116609586004316160
>>
>> basically has removing a couple of transitive dependencies saving in
>> excess of 70% of the incremental rebuild time after touching a file.
>> This seems significant. :)
>>
>> -eric
>>
>> On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
>> wrote:
>>>
>>> This commit makes things look a little cleaner, but do we need any of these
>>> forward declarations at all?
>>>
>>> Most of these files either directly include lldb-forward.h or get it from
>>> lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a general
>>> practice we've been getting all the lldb_private type forward declarations
>>> this way rather than cluttering up the .h files with individual forward
>>> declarations. If we are going to keep doing it that way - which I can't
>>> see any reason not to do, then we should just delete all these forward
>>> defines, right?
>>>
>>> Jim
>>>
>>>
On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits
wrote:
Author: maskray
Date: Wed May 15 02:15:13 2019
New Revision: 360757
URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
Log:
Group forward declarations in one namespace lldb_private {}
Modified:
lldb/trunk/include/lldb/Core/Address.h
lldb/trunk/include/lldb/Core/AddressRange.h
lldb/trunk/include/lldb/Core/AddressResolver.h
lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
lldb/trunk/include/lldb/Core/AddressResolverName.h
lldb/trunk/include/lldb/Core/Communication.h
lldb/trunk/include/lldb/Core/Debugger.h
lldb/trunk/include/lldb/Core/Disassembler.h
lldb/trunk/include/lldb/Core/EmulateInstruction.h
lldb/trunk/include/lldb/Core/FileLineResolver.h
lldb/trunk/include/lldb/Core/FileSpecList.h
lldb/trunk/include/lldb/Core/FormatEntity.h
lldb/trunk/include/lldb/Core/Module.h
lldb/trunk/include/lldb/Core/ModuleList.h
lldb/trunk/include/lldb/Core/Opcode.h
lldb/trunk/include/lldb/Core/PluginManager.h
lldb/trunk/include/lldb/Core/SearchFilter.h
lldb/trunk/include/lldb/Core/Section.h
lldb/trunk/include/lldb/Core/SourceManager.h
lldb/trunk/include/lldb/Core/StreamAsynchronousIO.h
lldb/trunk/include/lldb/Core/UserSettingsController.h
lldb/trunk/include/lldb/Core/Value.h
lldb/trunk/include/lldb/Core/ValueObject.h
lldb/trunk/include/lldb/Core/ValueObjectCast.h
lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
lldb/trunk/include/lldb/Core/ValueObjectDynamicValue.h
lldb/trunk/include/lldb/Core/ValueObjectList.h
lldb/trunk/include/lldb/Core/ValueObjectMemory.h
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
This is a common header file that specifies either common enums & #defines in
lldb, or forward declarations of the common classes in lldb. They don't depend
on any other header files in the system, they just establish the common names
you should use. So the dependency analysis introduced by these files should be
trivial - they really don't depend on anything else. And the only time you
change them is when you add a new public type or define to lldb, which doesn't
happen very often.
But it is very convenient to have a common global set of names for the public
entities in lldb, that can be looked up in one place, etc. You can't actually
USE any of the classes from these header files, so they don't obscure what
other source files actually use - one problem with the big mongo "Cocoa.h"
header file pattern. If you want to get the class definition of anything, you
have to include the specific .h file for that thing. This is just a list of
forward declarations. Switching to
I haven't done your experiment, but if "I depend on a header that either
includes no other files or straight includes another file" really is a
significant burden on the dependency analysis, then I'm not sure this pattern
is actually the problem.
Jim
> On May 15, 2019, at 1:55 PM, Eric Christopher wrote:
>
> A couple of perspectives FWIW:
>
> a) Header file includes increase overall dependencies which affects
> incremental rebuild time whenever you touch something. Especially more
> when that header is included into multiple headers that are then
> included into an array of translation units
> b) Having each file contain the forward declarations it needs from the
> project and no more also will help both compile time and understanding
> what's used in any particular header.
>
> As a related exercise:
>
> https://twitter.com/echristo/status/1116609586004316160
>
> basically has removing a couple of transitive dependencies saving in
> excess of 70% of the incremental rebuild time after touching a file.
> This seems significant. :)
>
> -eric
>
> On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
> wrote:
>>
>> This commit makes things look a little cleaner, but do we need any of these
>> forward declarations at all?
>>
>> Most of these files either directly include lldb-forward.h or get it from
>> lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a general
>> practice we've been getting all the lldb_private type forward declarations
>> this way rather than cluttering up the .h files with individual forward
>> declarations. If we are going to keep doing it that way - which I can't see
>> any reason not to do, then we should just delete all these forward defines,
>> right?
>>
>> Jim
>>
>>
>>> On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits
>>> wrote:
>>>
>>> Author: maskray
>>> Date: Wed May 15 02:15:13 2019
>>> New Revision: 360757
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
>>> Log:
>>> Group forward declarations in one namespace lldb_private {}
>>>
>>> Modified:
>>> lldb/trunk/include/lldb/Core/Address.h
>>> lldb/trunk/include/lldb/Core/AddressRange.h
>>> lldb/trunk/include/lldb/Core/AddressResolver.h
>>> lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
>>> lldb/trunk/include/lldb/Core/AddressResolverName.h
>>> lldb/trunk/include/lldb/Core/Communication.h
>>> lldb/trunk/include/lldb/Core/Debugger.h
>>> lldb/trunk/include/lldb/Core/Disassembler.h
>>> lldb/trunk/include/lldb/Core/EmulateInstruction.h
>>> lldb/trunk/include/lldb/Core/FileLineResolver.h
>>> lldb/trunk/include/lldb/Core/FileSpecList.h
>>> lldb/trunk/include/lldb/Core/FormatEntity.h
>>> lldb/trunk/include/lldb/Core/Module.h
>>> lldb/trunk/include/lldb/Core/ModuleList.h
>>> lldb/trunk/include/lldb/Core/Opcode.h
>>> lldb/trunk/include/lldb/Core/PluginManager.h
>>> lldb/trunk/include/lldb/Core/SearchFilter.h
>>> lldb/trunk/include/lldb/Core/Section.h
>>> lldb/trunk/include/lldb/Core/SourceManager.h
>>> lldb/trunk/include/lldb/Core/StreamAsynchronousIO.h
>>> lldb/trunk/include/lldb/Core/UserSettingsController.h
>>> lldb/trunk/include/lldb/Core/Value.h
>>> lldb/trunk/include/lldb/Core/ValueObject.h
>>> lldb/trunk/include/lldb/Core/ValueObjectCast.h
>>> lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
>>> lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
>>> lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
>>> lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
>>> lldb/trunk/include/lldb/Core/ValueObjectDynamicValue.h
>>> lldb/trunk/include/lldb/Core/ValueObjectList.h
>>> lldb/trunk/include/lldb/Core/ValueObjectMemory.h
>>> lldb/trunk/include/lldb/Core/ValueObjectRegister.h
>>> lldb/trunk/include/lldb/Core/ValueObjectSyntheticFilter.h
>>> lldb/trunk/include/lldb/Core/ValueObjectVariable.h
>>> lldb/trunk/include/lldb/Target/DynamicLoader.h
>>>
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
A couple of perspectives FWIW:
a) Header file includes increase overall dependencies which affects
incremental rebuild time whenever you touch something. Especially more
when that header is included into multiple headers that are then
included into an array of translation units
b) Having each file contain the forward declarations it needs from the
project and no more also will help both compile time and understanding
what's used in any particular header.
As a related exercise:
https://twitter.com/echristo/status/1116609586004316160
basically has removing a couple of transitive dependencies saving in
excess of 70% of the incremental rebuild time after touching a file.
This seems significant. :)
-eric
On Wed, May 15, 2019 at 10:49 AM Jim Ingham via lldb-dev
wrote:
>
> This commit makes things look a little cleaner, but do we need any of these
> forward declarations at all?
>
> Most of these files either directly include lldb-forward.h or get it from
> lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a general
> practice we've been getting all the lldb_private type forward declarations
> this way rather than cluttering up the .h files with individual forward
> declarations. If we are going to keep doing it that way - which I can't see
> any reason not to do, then we should just delete all these forward defines,
> right?
>
> Jim
>
>
> > On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits
> > wrote:
> >
> > Author: maskray
> > Date: Wed May 15 02:15:13 2019
> > New Revision: 360757
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
> > Log:
> > Group forward declarations in one namespace lldb_private {}
> >
> > Modified:
> >lldb/trunk/include/lldb/Core/Address.h
> >lldb/trunk/include/lldb/Core/AddressRange.h
> >lldb/trunk/include/lldb/Core/AddressResolver.h
> >lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
> >lldb/trunk/include/lldb/Core/AddressResolverName.h
> >lldb/trunk/include/lldb/Core/Communication.h
> >lldb/trunk/include/lldb/Core/Debugger.h
> >lldb/trunk/include/lldb/Core/Disassembler.h
> >lldb/trunk/include/lldb/Core/EmulateInstruction.h
> >lldb/trunk/include/lldb/Core/FileLineResolver.h
> >lldb/trunk/include/lldb/Core/FileSpecList.h
> >lldb/trunk/include/lldb/Core/FormatEntity.h
> >lldb/trunk/include/lldb/Core/Module.h
> >lldb/trunk/include/lldb/Core/ModuleList.h
> >lldb/trunk/include/lldb/Core/Opcode.h
> >lldb/trunk/include/lldb/Core/PluginManager.h
> >lldb/trunk/include/lldb/Core/SearchFilter.h
> >lldb/trunk/include/lldb/Core/Section.h
> >lldb/trunk/include/lldb/Core/SourceManager.h
> >lldb/trunk/include/lldb/Core/StreamAsynchronousIO.h
> >lldb/trunk/include/lldb/Core/UserSettingsController.h
> >lldb/trunk/include/lldb/Core/Value.h
> >lldb/trunk/include/lldb/Core/ValueObject.h
> >lldb/trunk/include/lldb/Core/ValueObjectCast.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
> >lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
> >lldb/trunk/include/lldb/Core/ValueObjectDynamicValue.h
> >lldb/trunk/include/lldb/Core/ValueObjectList.h
> >lldb/trunk/include/lldb/Core/ValueObjectMemory.h
> >lldb/trunk/include/lldb/Core/ValueObjectRegister.h
> >lldb/trunk/include/lldb/Core/ValueObjectSyntheticFilter.h
> >lldb/trunk/include/lldb/Core/ValueObjectVariable.h
> >lldb/trunk/include/lldb/Target/DynamicLoader.h
> >lldb/trunk/include/lldb/Utility/Broadcaster.h
> >lldb/trunk/include/lldb/Utility/Connection.h
> >lldb/trunk/include/lldb/Utility/DataExtractor.h
> >lldb/trunk/include/lldb/Utility/Event.h
> >lldb/trunk/include/lldb/Utility/JSON.h
> >lldb/trunk/include/lldb/Utility/Listener.h
> >lldb/trunk/include/lldb/Utility/StringList.h
> >lldb/trunk/include/lldb/Utility/StructuredData.h
> >lldb/trunk/include/lldb/Utility/UserID.h
> >
> > Modified: lldb/trunk/include/lldb/Core/Address.h
> > URL:
> > http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Address.h?rev=360757=360756=360757=diff
> > ==
> > --- lldb/trunk/include/lldb/Core/Address.h (original)
> > +++ lldb/trunk/include/lldb/Core/Address.h Wed May 15 02:15:13 2019
> > @@ -19,36 +19,15 @@
> >
> > namespace lldb_private {
> > class Block;
> > -}
> > -namespace lldb_private {
> > class CompileUnit;
> > -}
> > -namespace lldb_private {
> > class ExecutionContextScope;
> > -}
> > -namespace lldb_private {
> > class Function;
> > -}
> > -namespace lldb_private {
> > class SectionList;
> > -}
> > -namespace lldb_private {
> > class Stream;
> > -}
> > -namespace lldb_private {
> > class Symbol;
> > -}
> > -namespace lldb_private {
> > class SymbolContext;
> > -}
> > -namespace lldb_private {
> > class
Re: [lldb-dev] [Lldb-commits] [lldb] r360757 - Group forward declarations in one namespace lldb_private {}
This commit makes things look a little cleaner, but do we need any of these
forward declarations at all?
Most of these files either directly include lldb-forward.h or get it from
lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a general
practice we've been getting all the lldb_private type forward declarations this
way rather than cluttering up the .h files with individual forward
declarations. If we are going to keep doing it that way - which I can't see
any reason not to do, then we should just delete all these forward defines,
right?
Jim
> On May 15, 2019, at 2:15 AM, Fangrui Song via lldb-commits
> wrote:
>
> Author: maskray
> Date: Wed May 15 02:15:13 2019
> New Revision: 360757
>
> URL: http://llvm.org/viewvc/llvm-project?rev=360757=rev
> Log:
> Group forward declarations in one namespace lldb_private {}
>
> Modified:
>lldb/trunk/include/lldb/Core/Address.h
>lldb/trunk/include/lldb/Core/AddressRange.h
>lldb/trunk/include/lldb/Core/AddressResolver.h
>lldb/trunk/include/lldb/Core/AddressResolverFileLine.h
>lldb/trunk/include/lldb/Core/AddressResolverName.h
>lldb/trunk/include/lldb/Core/Communication.h
>lldb/trunk/include/lldb/Core/Debugger.h
>lldb/trunk/include/lldb/Core/Disassembler.h
>lldb/trunk/include/lldb/Core/EmulateInstruction.h
>lldb/trunk/include/lldb/Core/FileLineResolver.h
>lldb/trunk/include/lldb/Core/FileSpecList.h
>lldb/trunk/include/lldb/Core/FormatEntity.h
>lldb/trunk/include/lldb/Core/Module.h
>lldb/trunk/include/lldb/Core/ModuleList.h
>lldb/trunk/include/lldb/Core/Opcode.h
>lldb/trunk/include/lldb/Core/PluginManager.h
>lldb/trunk/include/lldb/Core/SearchFilter.h
>lldb/trunk/include/lldb/Core/Section.h
>lldb/trunk/include/lldb/Core/SourceManager.h
>lldb/trunk/include/lldb/Core/StreamAsynchronousIO.h
>lldb/trunk/include/lldb/Core/UserSettingsController.h
>lldb/trunk/include/lldb/Core/Value.h
>lldb/trunk/include/lldb/Core/ValueObject.h
>lldb/trunk/include/lldb/Core/ValueObjectCast.h
>lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
>lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
>lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
>lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
>lldb/trunk/include/lldb/Core/ValueObjectDynamicValue.h
>lldb/trunk/include/lldb/Core/ValueObjectList.h
>lldb/trunk/include/lldb/Core/ValueObjectMemory.h
>lldb/trunk/include/lldb/Core/ValueObjectRegister.h
>lldb/trunk/include/lldb/Core/ValueObjectSyntheticFilter.h
>lldb/trunk/include/lldb/Core/ValueObjectVariable.h
>lldb/trunk/include/lldb/Target/DynamicLoader.h
>lldb/trunk/include/lldb/Utility/Broadcaster.h
>lldb/trunk/include/lldb/Utility/Connection.h
>lldb/trunk/include/lldb/Utility/DataExtractor.h
>lldb/trunk/include/lldb/Utility/Event.h
>lldb/trunk/include/lldb/Utility/JSON.h
>lldb/trunk/include/lldb/Utility/Listener.h
>lldb/trunk/include/lldb/Utility/StringList.h
>lldb/trunk/include/lldb/Utility/StructuredData.h
>lldb/trunk/include/lldb/Utility/UserID.h
>
> Modified: lldb/trunk/include/lldb/Core/Address.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Address.h?rev=360757=360756=360757=diff
> ==
> --- lldb/trunk/include/lldb/Core/Address.h (original)
> +++ lldb/trunk/include/lldb/Core/Address.h Wed May 15 02:15:13 2019
> @@ -19,36 +19,15 @@
>
> namespace lldb_private {
> class Block;
> -}
> -namespace lldb_private {
> class CompileUnit;
> -}
> -namespace lldb_private {
> class ExecutionContextScope;
> -}
> -namespace lldb_private {
> class Function;
> -}
> -namespace lldb_private {
> class SectionList;
> -}
> -namespace lldb_private {
> class Stream;
> -}
> -namespace lldb_private {
> class Symbol;
> -}
> -namespace lldb_private {
> class SymbolContext;
> -}
> -namespace lldb_private {
> class Target;
> -}
> -namespace lldb_private {
> struct LineEntry;
> -}
> -
> -namespace lldb_private {
>
> /// \class Address Address.h "lldb/Core/Address.h"
> /// A section + offset based address class.
>
> Modified: lldb/trunk/include/lldb/Core/AddressRange.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/AddressRange.h?rev=360757=360756=360757=diff
> ==
> --- lldb/trunk/include/lldb/Core/AddressRange.h (original)
> +++ lldb/trunk/include/lldb/Core/AddressRange.h Wed May 15 02:15:13 2019
> @@ -17,15 +17,8 @@
>
> namespace lldb_private {
> class SectionList;
> -}
> -namespace lldb_private {
> class Stream;
> -}
> -namespace lldb_private {
> class Target;
> -}
> -
> -namespace lldb_private {
>
> /// \class AddressRange AddressRange.h "lldb/Core/AddressRange.h"
> /// A section + offset based address range class.
>
> Modified:
Re: [lldb-dev] Access to TLS variables on GNU/Linux
On Tue, 14 May 2019 13:38:57 +0200, Florian Weimer via lldb-dev wrote:
> The target process has loaded libpthread.so.0, so it's not the usual
> problem of libthread_db not working without libpthread.
>
> On the other hand, I realize now that the lldb command cannot access TLS
> variables, either. Is this expected to work at all?
TLS is implemented only for FreeBSD as there is
FreeBSDThread::GetThreadPointer() but on Linux it falls back to unimplemented:
lldb::addr_t Thread::GetThreadPointer() { return LLDB_INVALID_ADDRESS; }
On Linux it uses DynamicLoaderPOSIXDYLD::GetThreadLocalData() which may work
without libthread_db as it is reading "_thread_db_*" symbols in
DYLDRendezvous::GetThreadInfo(). But it needs that GetThreadPointer() which
could get implemented (for x86_64) by reading %fs_base. LLDB currently does
not know anything about %fs_base+%gs_base.
Is it a good idea to implement %fs_base+%gs_base to make TLS working on Linux?
Jan
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
