[lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()

[Bruce Mitchener via lldb-dev]

Greg et al:

When linking (cmake on OS X), I get a lot of warnings like this:

  ld: warning: cannot export hidden symbol lldb::endian::InlHostByteOrder()
  from
lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o)

Should this function be in the public namespace?

It is an inline function which is why I think it gets flagged as hidden.

Can we move it out of the lldb namespace? Or has that ship sailed? Is there
some other way that we can suppress this warning or fix the underlying
issue? (Can we exclude a symbol from being exported somehow?)

This isn't the only symbol that is a problem, but it is the one that
generates the most output.

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

Re: [lldb-dev] Link warnings about lldb::endian::InlHostByteOrder()

[Bruce Mitchener via lldb-dev]

On Fri, Nov 6, 2015 at 1:00 AM, Greg Clayton  wrote:

>
> > On Nov 5, 2015, at 1:21 AM, Bruce Mitchener via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Greg et al:
> >
> > When linking (cmake on OS X), I get a lot of warnings like this:
> >
> >   ld: warning: cannot export hidden symbol
> lldb::endian::InlHostByteOrder()
> >   from
> lib/liblldbPluginProcessUtility.a(RegisterContextDarwin_arm64.cpp.o)
> >
> > Should this function be in the public namespace?
>
> No I don't believe it should.
>
> > It is an inline function which is why I think it gets flagged as hidden.
> >
> > Can we move it out of the lldb namespace? Or has that ship sailed? Is
> there some other way that we can suppress this warning or fix the
> underlying issue? (Can we exclude a symbol from being exported somehow?)
>
> Please feel free to move it to the lldb_private namespace. Nothing in our
> lldb/API/SB* header files should use it, so it is fine to move it. Let me
> know if you run into any troubles doing so.


Review: http://reviews.llvm.org/D14417


> > This isn't the only symbol that is a problem, but it is the one that
> generates the most output.
>
> We should have no inlined functions in our public API if we can avoid it.
> That is a sure way to have people crash if we ever change anything and they
> linked against the inline code from the header file.
>

After fixing this one, the remaining cases are:

ld: warning: cannot export hidden symbol lldb::SBListener::GetSP() from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBAttachInfo.cpp.o
ld: warning: cannot export hidden symbol lldb::SBListener::GetSP() from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBLaunchInfo.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.o
ld: warning: cannot export hidden symbol lldb::SBListener::GetSP() from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/SBTarget.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBPlatform::operator=(lldb::SBPlatform const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBPlatform::SBPlatform(lldb::SBPlatform const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBQueueItem::operator=(lldb::SBQueueItem const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBQueueItem::SBQueueItem(lldb::SBQueueItem const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBQueueItem::SBQueueItem(lldb::SBQueueItem const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBLaunchInfo::SBLaunchInfo(lldb::SBLaunchInfo const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o
ld: warning: cannot export hidden symbol
lldb::SBLaunchInfo::SBLaunchInfo(lldb::SBLaunchInfo const&) from
tools/lldb/source/API/CMakeFiles/liblldb.dir/__/__/scripts/LLDBWrapPython.cpp.o

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

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Bruce Mitchener via lldb-dev]

Stepping one step back further in the thread ...

On Wed, Nov 18, 2015 at 8:35 AM, Zachary Turner via lldb-commits <
lldb-comm...@lists.llvm.org> wrote:

> Moving this back over to the list since I'm sure others have some input
> here.  Also +lldb-dev since it has more visibility than lldb-commits.
>
>
> On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner 
> wrote:
>
>> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala  wrote:
>>
>>> Breaking out the binding generation into a separate step will also be
>>> important for a couple reasons:
>>>
>>> * (from before) I want to eliminate the requirement for the vast
>>> majority of the builds to have a swig on their system, and
>>>
>>> * (not stated before) we'd like to move away from swig for binding
>>> generation at some point.
>>>
>>
Is there any discussion or thoughts about what the options would be for
moving away from swig?

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

[lldb-dev] Announce: Rust bindings for the LLDB public API

[Bruce Mitchener via lldb-dev]

Hello all,

I've been working on Rust bindings for the LLDB API and they're coming
along pretty well. They aren't complete yet, but they're getting close:

https://github.com/endoli/lldb.rs/

The documentation for these bindings can be found at
https://endoli.github.io/lldb.rs/

I need to write more documentation, hook up more safe bindings for things
like events, values and a few other things.  Some very basic things already
work though.

These are using the C code / API that was submitted in a pull request in
April of 2015 and subsequently seems to have been abandoned.

My goal here is to have a very clean binding of the C++ API, but with some
modifications to make it more idiomatic Rust in places.  Examples of this
are returning Option types instead of requiring that the caller check
IsValid, as well as Result types when there might be an SBError.

This is being done to power some of my other projects, but I'm willing to
support this for others should the need arise and I'd love to see more
people using this than just me. I've also got a Patreon (
https://patreon.com/endoli/) if anyone feels like helping to support this
work in that way.

I'm also happy to discuss any aspects of this work here or elsewhere.

Cheers,

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

[lldb-dev] SBAttachInfo question

[Bruce Mitchener via lldb-dev]

Hello,

SBAttachInfo exposes a bunch of getters and setters for user ID, groupID,
parent process ID, effective user ID, effective group ID.

It doesn't seem like one would set these to anything prior to attaching,
but I also don't see in the code where they might get set in the event of a
successful attach (especially an async one).

Are these actually supposed to be part of the public API and be usable in a
meaningful way?

Cheers,

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

[lldb-dev] SBStructuredData inconsistencies

[Bruce Mitchener via lldb-dev]

Hello,

I was adding support for `SBStructuredData` to my Rust bindings for the
LLDB API and noticed a couple of things.

Since 5.0 isn't out yet and these are newer API additions, I was hoping
there might still be time to fix this.

`SBStructuredData::GetFloatValue` returns a `double`, but other things that
return a `double` like `SBData` use "Double" in the name of the method:
`GetDouble`.

The `StructuredDataType` enumeration uses `-1` as the value for `Invalid`,
but other enumerations typically use `0` or even the occasional `1`. I
think that this enumeration is the only one that uses a `-1` within the
LLDB public APIs.

Could we rename the method to `GetDoubleValue`? And can we re-number the
enumeration values?

If so, I would like to get this in for the 5.0 release.

I know that Vadim Macagon has been using SBStructuredData from Python and
reported that the Python / SWIG interface for GetStringValue is awkward to
use, but I haven't looked into this myself yet.

Thanks,

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

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Bruce Mitchener via lldb-dev]

I like this a lot!

I commented on the patch since I didn't see this thread at the time, but
it'd be interesting to perhaps replace Epydoc with Sphinx as well.

 - Bruce


On Fri, Dec 7, 2018 at 12:02 AM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi everyone,
>
> The current LLDB website is written in HTML which is hard to maintain. We
> have quite a bit of HTML code checked in which can make it hard to
> differentiate between documentation written by us and documentation
> generated by a tool. Furthermore I think text/RST files provide a lower
> barrier for new or casual contributors to fix or update.
>
> In line with the other LLVM projects I propose generating the
> documentation with Sphix. I created a patch (
> https://reviews.llvm.org/D55376) that adds a new target docs-lldb-html
> when -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages to
> give an idea of what this would look like in-tree. Before continuing with
> this rather tedious work I'd like to get feedback form the community.
>
> Initially I started with the theme used by Clang because it's a default
> theme and doesn't require configuration. If we want to keep the sidebar we
> could use the one used by LLD.
>
> Please let me know what you think.
>
> Thanks,
> Jonas
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Bruce Mitchener via lldb-dev]

On Fri, Dec 7, 2018 at 6:11 PM Raphael Isemann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I think if we want to actually lower the entry barrier for
> contributing/fixing things on the website, then the server should do
> this. From what I know the other LLVM projects also generate the HTML
> on the server (at least I've never seen anyone commit generated HTML
> files), so this hopefully shouldn't be too complicated.
>

Agree. Also, there's enough differences between the generated HTML for
various versions of the tools that having it happen on the server would be
good.


> I think in general this approach is really nice. Thanks a lot for the
> work @Jonas!
>

Indeed!

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

[lldb-dev] SB API questions

[Bruce Mitchener via lldb-dev]

Hello,

I've recently been working on and with my Rust bindings to the public LLDB
API after a break of a couple of years.

A couple of things that I'm noticing or re-noticing:

We need more SB API coverage of logging functionality. We can't list
channels, categories via the SB API. We also don't have a call for
disabling log output once it has been enabled. These seem fairly
straightforward to add.

While the underlying platform objects support finding processes, this isn't
exposed to the SB API, so there's no way to get a nice list of the running
processes using only the SB API. Has anyone looked at this or thought about
the API?

It would be helpful in some cases, especially with the above, to extend
SBProcessInfo to include arguments / argv, environment, and architecture.
These are already present in the underlying data, just not exposed via
SBProcessInfo.

Any thoughts or objections on the above? Would patches be welcome?

Are there others using the SB API a lot that might be willing to discuss
this sort of stuff more?

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

Re: [lldb-dev] SB API questions

[Bruce Mitchener via lldb-dev]

\On Sat, May 29, 2021 at 10:57 PM Raphael Isemann 
wrote:

> And I think the best way to propose a new API is maybe just making a
> dummy patch that adds the API + documentation (doesn't need an actual
> implementation or tests). And if everyone agrees the new API is fine
> you can add the tests and implementation. By making a patch you also
> automatically get everyone subscribed to your patch via Herald rules
> or people reading the mailing list.
>
> If you don't want to make patches, I think bug reports on
> bugs.llvm.org could also work. Most of the thing you describe sound
> like they don't need a lot of effort to implement/test, so there's a
> good chance someone will implement it for you.
>

I've just created https://reviews.llvm.org/D103375 for one of the pieces. I
used to have commit access, but the last time I used it was before the move
to GitHub, so I don't mind doing the work and landing things myself ... I
don't want to create much of a burden on others!

Thanks for your feedback!

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

[lldb-dev] DNBConfig and debugserver

[Bruce Mitchener via lldb-dev]

Hello!

This is probably for the Apple People since it relates to debugserver...

I was going to fix an issue with the cmake build on Mac OS X related to the
mig generation step and DNBConfig.h, but when I started digging into
things, I noticed that DNBConfig.h isn't needed any longer.

The only test that it performs is for whether or not 64 bit Mach exceptions
can be used.

The code that actually handled non-64 bit Mach exceptions was removed in
2011 by this commit:

commit 0e8147bd867e4cdaae9400f56d02c7aacd40a9b3
Author: Greg Clayton 
Date:   Fri Oct 28 22:59:14 2011 +

Enabled the "printf" attribute on all debugserver logging functions and
fixed
the ensuing mayhem.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143244
91177308-0d34-0410-b5e6-96231b3b80d8


So, I'm wondering what the right next step is:


   - Just fix the issue that I was going to fix in the cmake build system.
   - Remove the unused test for 64 bit Mach exception handling and that
   usage of DNBConfig.h
   - Remove DNBConfig.h entirely along with the machinery for generating it
   since nothing actually needs or uses it.
   - Something else.

I'm happy to do any of the above options.

Cheers,

 - Bruce

PS. HavAVX.s is missing an EOL at EOF, and so it generates a warning. Can I
just commit an EOL at EOF without going through Phabricator? That won't
break anything, right?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] DNBConfig and debugserver

[Bruce Mitchener via lldb-dev]

Just in case the below came out with a resolution of "Let's remove it", I
submitted this for review:

http://reviews.llvm.org/D11971

 - Bruce

On Wed, Aug 12, 2015 at 11:21 AM, Bruce Mitchener  wrote:

> Hello!
>
> This is probably for the Apple People since it relates to debugserver...
>
> I was going to fix an issue with the cmake build on Mac OS X related to
> the mig generation step and DNBConfig.h, but when I started digging into
> things, I noticed that DNBConfig.h isn't needed any longer.
>
> The only test that it performs is for whether or not 64 bit Mach
> exceptions can be used.
>
> The code that actually handled non-64 bit Mach exceptions was removed in
> 2011 by this commit:
>
> commit 0e8147bd867e4cdaae9400f56d02c7aacd40a9b3
> Author: Greg Clayton 
> Date:   Fri Oct 28 22:59:14 2011 +
>
> Enabled the "printf" attribute on all debugserver logging functions
> and fixed
> the ensuing mayhem.
>
>
>
> git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143244
> 91177308-0d34-0410-b5e6-96231b3b80d8
>
>
> So, I'm wondering what the right next step is:
>
>
>- Just fix the issue that I was going to fix in the cmake build system.
>- Remove the unused test for 64 bit Mach exception handling and that
>usage of DNBConfig.h
>- Remove DNBConfig.h entirely along with the machinery for generating
>it since nothing actually needs or uses it.
>- Something else.
>
> I'm happy to do any of the above options.
>
> Cheers,
>
>  - Bruce
>
> PS. HavAVX.s is missing an EOL at EOF, and so it generates a warning. Can
> I just commit an EOL at EOF without going through Phabricator? That won't
> break anything, right?
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Exported symbols from LLDB build products

[Bruce Mitchener via lldb-dev]

Hello,

On Mac OS X, when using the xcode projects, there is some machinery to
manage what symbols are exported from various things:


   - liblldb only exports the public API.
   - debugserver only exports _DNB* and __DNB*
   - argdumper exports nothing
   - lldb-server exports nothing

This machinery only exists within the xcode projects though and isn't used
in the cmake or autotools build systems.

I'm not interested in adding it to the autotools build system, but I would
like to get this set up in the cmake build system.

The LLVM cmake code provides a helper function for managing this already in
a cross-platform manner. The main difference is that it expects one fewer
leading underscores in the exports files and a particular naming scheme for
the files.

Managing the files and their names is pretty easy and I can handle that.

The other difference is a bit harder to manage unless we set up a script to
run in the xcode build to perform the mapping (not hard for someone that
knows xcode, I guess).

So:


   - Is this something we want on all platforms? I think the most important
   of these is limiting liblldb to only exporting the public API.
   - Should any other targets have their exported symbols similarly
   restricted? (Perhaps lldb-mi?)
   - Is someone willing to assist with a minor xcode change so that we
   don't have to have a separate copy of 2 of the files for the xcode build?


Thanks!

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

Re: [lldb-dev] Exported symbols from LLDB build products

[Bruce Mitchener via lldb-dev]

I was doing some more digging into this and experimentation and found that
the Windows build appears to handle this already, but that's because symbol
visibility is different over there.

It looks like on non-Windows, we should be using the
__attribute__((visibility("hidden"))) for pretty much all of the LLDB
classes, apart from the public API. With that set up correctly, we don't
need linker flags at all, and it gives the compiler additional information
to generate better code (which linker options / scripts won't provide).

llvm's include file llvm/Support/Compiler.h provides a preprocessor
definition LLVM_LIBRARY_VISIBILITY which can be applied to everything that
is supposed to be internal.  This is what clang and LLVM do to hide some
things, but they provide a much broader API than LLDB does.

Would you be averse to LLVM_LIBRARY_VISIBILITY being added to all of our
internal class definitions? (I don't mind doing the work.)  That seems like
the better and more correct way to handle this.

If we can do that, we'd want to include "llvm/Support/Compiler.h" in just
about everything to pick up the LLVM_LIBRARY_VISIBILITY definition. Would
we be able to put that in one of the LLDB headers that is already included
everywhere?

 - Bruce


On Fri, Aug 14, 2015 at 11:14 PM, Greg Clayton  wrote:

>
> > On Aug 13, 2015, at 6:43 PM, Bruce Mitchener via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hello,
> >
> > On Mac OS X, when using the xcode projects, there is some machinery to
> manage what symbols are exported from various things:
> >
> >   • liblldb only exports the public API.
>
> It currently exports:
>
> _ZN4lldb*
> _ZNK4lldb*
> init_lld*
>
>
> >   • debugserver only exports _DNB* and __DNB*
>
> That is due to legacy stuff and debugserver actually doesn't need to
> export anything...
>
> >   • argdumper exports nothing
> >   • lldb-server exports nothing
>
> No executable tools need to ever really export anything, so this can and
> should almost always be the rules we use in CMake to create executables,
> not shared libraries, but just executables.
>
> > This machinery only exists within the xcode projects though and isn't
> used in the cmake or autotools build systems.
>
> We should fix this.
>
> > I'm not interested in adding it to the autotools build system, but I
> would like to get this set up in the cmake build system.
> >
> > The LLVM cmake code provides a helper function for managing this already
> in a cross-platform manner. The main difference is that it expects one
> fewer leading underscores in the exports files and a particular naming
> scheme for the files.
> >
> > Managing the files and their names is pretty easy and I can handle that.
> >
> > The other difference is a bit harder to manage unless we set up a script
> to run in the xcode build to perform the mapping (not hard for someone that
> knows xcode, I guess).
>
> Why? The
> http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports
> file is so simple and it won't change. I don't see the need to do anything
> special in Xcode to convert some random file into another format.
>
> >
> > So:
> >
> >   • Is this something we want on all platforms? I think the most
> important of these is limiting liblldb to only exporting the public API.
>
> The lldb.so should limit its exports. It makes the shared library cleaner
> and easier for the dynamic loaders to deal with.
> >   • Should any other targets have their exported symbols similarly
> restricted? (Perhaps lldb-mi?)
>
> lldb-mi should export nothing just like argdumper and lldb-server.
>
> >   • Is someone willing to assist with a minor xcode change so that
> we don't have to have a separate copy of 2 of the files for the xcode build?
>
> I am not sure how this would work. I would rather not have something
> generating the
> http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports
> file as these files aren't too difficult to create, even if there are two
> copies. It currently contains:
>
> __ZN4lldb*
> __ZNK4lldb*
> _init_lld*
>
> These could easily be added to the linker flags for command line builds
> and they aren't going to be changing. So I don't see the need to jump
> through any hoops to make this happen since they won't change. Just make it
> happen in our CMake/make builds.
>
> Greg
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exported symbols from LLDB build products

[Bruce Mitchener via lldb-dev]

Hmm, while the below would help, it wouldn't prevent the llvm and clang
symbols from being re-exported from the LLDB shared library.

I still think it would be good to do, but we'd still need the linker
options (but that's easy for Darwin, a bit more involved for Linux and
FreeBSD, I think).

 - Bruce

On Sat, Aug 15, 2015 at 1:04 AM, Bruce Mitchener 
wrote:

> I was doing some more digging into this and experimentation and found that
> the Windows build appears to handle this already, but that's because symbol
> visibility is different over there.
>
> It looks like on non-Windows, we should be using the
> __attribute__((visibility("hidden"))) for pretty much all of the LLDB
> classes, apart from the public API. With that set up correctly, we don't
> need linker flags at all, and it gives the compiler additional information
> to generate better code (which linker options / scripts won't provide).
>
> llvm's include file llvm/Support/Compiler.h provides a preprocessor
> definition LLVM_LIBRARY_VISIBILITY which can be applied to everything that
> is supposed to be internal.  This is what clang and LLVM do to hide some
> things, but they provide a much broader API than LLDB does.
>
> Would you be averse to LLVM_LIBRARY_VISIBILITY being added to all of our
> internal class definitions? (I don't mind doing the work.)  That seems like
> the better and more correct way to handle this.
>
> If we can do that, we'd want to include "llvm/Support/Compiler.h" in just
> about everything to pick up the LLVM_LIBRARY_VISIBILITY definition. Would
> we be able to put that in one of the LLDB headers that is already included
> everywhere?
>
>  - Bruce
>
>
> On Fri, Aug 14, 2015 at 11:14 PM, Greg Clayton  wrote:
>
>>
>> > On Aug 13, 2015, at 6:43 PM, Bruce Mitchener via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> >
>> > Hello,
>> >
>> > On Mac OS X, when using the xcode projects, there is some machinery to
>> manage what symbols are exported from various things:
>> >
>> >   • liblldb only exports the public API.
>>
>> It currently exports:
>>
>> _ZN4lldb*
>> _ZNK4lldb*
>> init_lld*
>>
>>
>> >   • debugserver only exports _DNB* and __DNB*
>>
>> That is due to legacy stuff and debugserver actually doesn't need to
>> export anything...
>>
>> >   • argdumper exports nothing
>> >   • lldb-server exports nothing
>>
>> No executable tools need to ever really export anything, so this can and
>> should almost always be the rules we use in CMake to create executables,
>> not shared libraries, but just executables.
>>
>> > This machinery only exists within the xcode projects though and isn't
>> used in the cmake or autotools build systems.
>>
>> We should fix this.
>>
>> > I'm not interested in adding it to the autotools build system, but I
>> would like to get this set up in the cmake build system.
>> >
>> > The LLVM cmake code provides a helper function for managing this
>> already in a cross-platform manner. The main difference is that it expects
>> one fewer leading underscores in the exports files and a particular naming
>> scheme for the files.
>> >
>> > Managing the files and their names is pretty easy and I can handle that.
>> >
>> > The other difference is a bit harder to manage unless we set up a
>> script to run in the xcode build to perform the mapping (not hard for
>> someone that knows xcode, I guess).
>>
>> Why? The
>> http://llvm.org/svn/llvm-project/lldb/trunk/resources/lldb-framework-exports
>> file is so simple and it won't change. I don't see the need to do anything
>> special in Xcode to convert some random file into another format.
>>
>> >
>> > So:
>> >
>> >   • Is this something we want on all platforms? I think the most
>> important of these is limiting liblldb to only exporting the public API.
>>
>> The lldb.so should limit its exports. It makes the shared library cleaner
>> and easier for the dynamic loaders to deal with.
>> >   • Should any other targets have their exported symbols similarly
>> restricted? (Perhaps lldb-mi?)
>>
>> lldb-mi should export nothing just like argdumper and lldb-server.
>>
>> >   • Is someone willing to assist with a minor xcode change so that
>> we don't have to have a separate copy of 2 of the files for the xcode build?
>>
>> I am not sure how this would work. I would rat

[lldb-dev] cmake build broken from ExpressionParser changes

[Bruce Mitchener via lldb-dev]

The change for the ExpressionParser plugin didn't have changes in it for
the cmake or Makefile-based build systems.

I'll check in the cmake changes once my test build completes successfully.

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

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

[Bruce Mitchener via lldb-dev]

There were 2 changes made this week that broke both the cmake and one that
broke the Makefile builds.  I checked in fixes for the cmake build, but no
one has done similar for the Makefile build (as far as I've noticed).
(Notably, there's no Makefile support for
source/Plugins/ExpressionParser/Clang.)

If we're going to leave that broken, maybe we could, instead, be the
pioneers in LLVM-land and remove the Makefile-based build system instead.
It doesn't seem like any of the people doing steady work on LLDB use it.

 - Bruce


On Fri, Sep 4, 2015 at 1:34 AM, Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> We forced a clean build because it wasn’t picking up an enum change that
> affected the swig python bindings, and the objective c problem popped up.
>
>
>
> I’ve built with cmake on that machine, and it worked. I think the right
> answer is switch to cmake.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Thursday, September 03, 2015 12:42 PM
> *To:* Todd Fiala; Ted Woodward
> *Cc:* LLDB
> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure
> on Linux?
>
>
>
> Can you change it to CMake instead of configure?  I know that's not what
> you want to hear, but the configure build is on its way out, so you're
> going to have to do this at some point anyway.
>
>
>
> On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I haven't seen that one myself.  Are you still seeing it?
>
>
>
> Is it possible the buildbot's commands are possibly using older/stale
> object files?  Is distcc/ccache involved?  Does the build force a clean
> build?  If not, does the issue go away on a clean build?  Is it
> configure-based or cmake based?
>
>
>
> Just some thoughts.  Good luck resolving!
>
>
>
> -Todd
>
>
>
> On Fri, Aug 28, 2015 at 10:56 AM, Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Our Ubuntu 14.10 buildbot at
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing,
> and I’ve been tasked to fix it because I’m the LLDB guy.
>
>
>
> It fails with things like:
>
> /var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/Release+Asserts/lib/libclangCodeGen.a(BackendUtil.o):
> In function `addObjCARCOptPass(llvm::PassManagerBuilder const&,
> llvm::legacy::PassManagerBase&)':
>
> BackendUtil.cpp:(.text._ZL17addObjCARCOptPassRKN4llvm18PassManagerBuilderERNS_6legacy15PassManagerBaseE+0x21):
> undefined reference to `llvm::createObjCARCOptPass()'
>
>
>
> I get the same error when I manually build using the same steps as the
> bot, but when I use cmake it works.
>
>
>
> Has anyone seen this behavior using configure?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
>
> --
>
> -Todd
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] top-of-tree build failure when using configure on Linux?

[Bruce Mitchener via lldb-dev]

The error that Ted was seeing is now fixed on SVN HEAD.

 - Bruce


On Thu, Sep 10, 2015 at 12:51 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The community's current plan of record is still to kill the autoconf build
> but there is no definitive timeline on when it will be complete.  But to
> answer your question, yes it is across all projects.
>
> From the LLDB side, I don't know if anyone depends on having a working
> autoconf build for production reasons.  The last time I heard, it was only
> still around because some people were still running autoconf-based
> buildbots.  It's possible I'm forgetting about something or someone, but
> that was my understanding.
>
> On Wed, Sep 9, 2015 at 10:39 AM Rick Foos via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Can you change it to CMake instead of configure?  I know that's not what
>> you want to hear, but the configure build is on its way out, so you're
>> going to have to do this at some point anyway.
>>
>> Zachary, is the decision to drop autoconf across all projects or just
>> LLDB? The last time I proposed a cmake change, I was asked to add the
>> equivalent for autoconf.
>> (if autoconf is deprecated, I have some other builders starting that I
>> need to switch to cmake)
>>
>> Ted, I was going to remove the builder before I left but didn't have
>> time. The tests were not going to be fixed for autoconf builds. BTW
>> hexagon-build-03 is up to date Ubuntu 15.04 if you care about the newer gcc
>> version.
>>
>>
>> - Rick
>>
>>
>> On 09/09/2015 11:56 AM, Ted Woodward via lldb-dev wrote:
>>
>> I took a look at the buildbots; it looks like another buildbot is failing
>> with the same issue – the debian bot,
>> 
>> http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang . It fails
>> the compile at the same place as the Hexagon Ubuntu bot, and it also uses
>> configure.
>>
>>
>>
>> Google has 2 Ubuntu 14.04 bots up that are building lldb using cmake, so
>> ours will be redundant when we switch it to cmake. If there’s no objection,
>> we’ll just take it down.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org
>> ] *On Behalf Of *Ted Woodward via
>> lldb-dev
>> *Sent:* Thursday, September 03, 2015 1:34 PM
>> *To:* 'Zachary Turner'; 'Todd Fiala'
>> *Cc:* 'LLDB'
>> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure
>> on Linux?
>>
>>
>>
>> We forced a clean build because it wasn’t picking up an enum change that
>> affected the swig python bindings, and the objective c problem popped up.
>>
>>
>>
>> I’ve built with cmake on that machine, and it worked. I think the right
>> answer is switch to cmake.
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> *From:* Zachary Turner [mailto:ztur...@google.com ]
>> *Sent:* Thursday, September 03, 2015 12:42 PM
>> *To:* Todd Fiala; Ted Woodward
>> *Cc:* LLDB
>> *Subject:* Re: [lldb-dev] top-of-tree build failure when using configure
>> on Linux?
>>
>>
>>
>> Can you change it to CMake instead of configure?  I know that's not what
>> you want to hear, but the configure build is on its way out, so you're
>> going to have to do this at some point anyway.
>>
>>
>>
>> On Thu, Sep 3, 2015 at 10:25 AM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> I haven't seen that one myself.  Are you still seeing it?
>>
>>
>>
>> Is it possible the buildbot's commands are possibly using older/stale
>> object files?  Is distcc/ccache involved?  Does the build force a clean
>> build?  If not, does the issue go away on a clean build?  Is it
>> configure-based or cmake based?
>>
>>
>>
>> Just some thoughts.  Good luck resolving!
>>
>>
>>
>> -Todd
>>
>>
>>
>> On Fri, Aug 28, 2015 at 10:56 AM, Ted Woodward via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Our Ubuntu 14.10 buildbot at
>> 
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.10 is failing,
>> and I’ve been tasked to fix it because I’m the LLDB guy.
>>
>>
>>
>> It fails with things like:
>>
>> /var/lib/buildbot/slaves/hexagon-build-03/lldb-x86_64-ubuntu-14.10/llvm.obj/Release+Asserts/lib/libclangCodeGen.a(BackendUtil.o):
>> In function `addObjCARCOptPass(llvm::PassManagerBuilder const&,
>> llvm::legacy::PassManagerBase&)':
>>
>> BackendUtil.cpp:(.text._ZL17addObjCARCOptPassRKN4llvm18PassManagerBuilderERNS_6legacy15PassManagerBaseE+0x21):
>> undefined reference to `llvm::createObjCARCOptPass()'
>>
>>
>>
>> I get the same error when I manually build using the same steps as the
>> bot, but when I use cmake it works.
>>
>>
>>
>> Has anyone seen this behavior using confi

[lldb-dev] Compiler types and renamings

[Bruce Mitchener via lldb-dev]

Howdy!

I was looking at some of the CompilerType changes and had some questions
related to the recent cleanups and renamings.


   - clang_type_t is a typedef for void* and is used for the opaque qual
   type code among other things. However, the m_type on CompilerType is just a
   void*.  Should we rename clang_type_t to compiler_type_t or just do away
   with it and use void* instead?
   - SymbolFileDWARF has 2 typedefs, DIEToClangType and ClangTypeToDIE
   which are used for 2 maps, m_forward_decl_die_to_clang_type
   and m_forward_decl_clang_type_to_die. Should these be renamed to use
   Compiler instead of Clang?
   - Any use of an instance of CompilerType in general code (code not in a
   file with Clang in the name) can probably be renamed from clang_type to
   compiler_type, right? This would include the clang_type member on Type.

I'd like to do any of the above, just want to make sure that it won't clash
with pending changes like this and that people actually want this to happen.

 - Bruce
   Part time code janitor
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to debug LLDB server?

[Bruce Mitchener via lldb-dev]

In the LLDB project, you have 3 different defines:

LLDB_CONFIGURATION_DEBUG
LLDB_CONFIGURATION_RELEASE
LLDB_CONFIGURATION_BUILD_AND_INTEGRATION

I can easily set this up to be set for the various build types in cmake,
but I'd like to make sure we all agree about what should happen first:

CMAKE_BUILD_TYPE = Debug: Add LLDB_CONFIGURATION_DEBUG
CMAKE_BUILD_TYPE = RelWithDebinfo: Add LLDB_CONFIGURATION_RELEASE
CMAKE_BUILD_TYPE = Release: Add LLDB_CONFIGURATION_BUILD_AND_INTEGRATION

This seems right to me as there are some usages of
LLDB_CONFIGURATION_RELEASE that appear to be useful with debugging.

Does that seem to be correct?

 - Bruce


On Thu, Oct 8, 2015 at 2:44 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> We set this manually in the Xcode project for "Debug" and "DebugClang"
> build variants. The cmake should be able to do the same, but I am not sure
> if it is. Feel free to make it do so. I am not very good with cmake, so I
> won't be much help.
>
> Greg
>
> > On Oct 7, 2015, at 11:09 AM, Eugene Birukov 
> wrote:
> >
> > Thanks!
> >
> > A newbie question then: how to trigger LLDB_CONFIGURATION_DEBUG when I
> run cmake? I am sure that I built debug version, but packet timeout is
> still 1 to me.
> >
> > (gdb) p m_packet_timeout
> > $1 = 1
> >
> >
> > > Subject: Re: [lldb-dev] How to debug LLDB server?
> > > From: gclay...@apple.com
> > > Date: Wed, 7 Oct 2015 11:04:45 -0700
> > > CC: lldb-dev@lists.llvm.org
> > > To: eugen...@hotmail.com
> > >
> > > Most calls for lldb-server should use an instance variable
> GDBRemoteCommunication::m_packet_timeout which you could then modify. But
> this timeout you are talking about is the time that the expression can take
> when running. I would just bump these up temporarily while you are
> debugging to avoid the timeouts. Just don't check it in.
> > >
> > > So for GDB Remote packets, we already bump the timeout up in the
> GDBRemoteCommunication constructor:
> > >
> > > #ifdef LLDB_CONFIGURATION_DEBUG
> > > m_packet_timeout (1000),
> > > #else
> > > m_packet_timeout (1),
> > > #endif
> > >
> > >
> > > Anything else is probably expression timeouts and you will need to
> manually bump those up in order to debug, or you could do the same thing as
> the GDB Remote in InferiorCallPOSIX.cpp:
> > >
> > > #ifdef LLDB_CONFIGURATION_DEBUG
> > > options.SetTimeoutUsec(5000);
> > > #else
> > > options.SetTimeoutUsec(50);
> > > #endif
> > >
> > >
> > > > On Oct 7, 2015, at 10:33 AM, Eugene Birukov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > >
> > > > Hello,
> > > >
> > > > I am trying to see what is going inside LLDB server 3.7.0 but there
> are a lot of timeouts scattered everywhere. Say, InferiorCallPOSIX.cpp:74
> sets hard-coded timeout to 500,000us, etc. These timeouts fire if I spend
> any time on breakpoint inside server and make debugging experience
> miserable. Is there any way to turn them all off?
> > > >
> > > > BTW, I am using LLDB as a C++ API, not as standalone program, but I
> have debugger attached to it and can alter its memory state.
> > > >
> > > > Thanks,
> > > > Eugene
> > > >
> > > > ___
> > > > lldb-dev mailing list
> > > > lldb-dev@lists.llvm.org
> > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> > >
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev