Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

[Reid Kleckner via lldb-dev]

On Tue, Oct 5, 2021 at 9:48 AM Renato Golin via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Tue, 5 Oct 2021 at 17:06, Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> - Any other information that you think will help the Board of Directors
>> make the best decision.
>
> - Foundation Board will have 30 days to make a final decision about using
>> GitHub Pull Requests and then communicate a migration plan to the community.
>
>
> Hi Tom,
>
> Please help me here, I think I'm severely misunderstanding what this
> means...
>
> I'm reading it that the "Board of Directors" will make a decision and
> communicate to the community, apparently through some undisclosed internal
> process.
> ...
>

I want to take the other side here, and say that I appreciate that the
board is trying to provide more structure for this decision making process.
I don't think the board is trying to step in and take ownership of the
decision, they are trying to solicit input and reflect it back to LLVM
developers in an efficient way. It has long been clear that LLVM needs a
more effective process for building consensus and making decisions, and in
the absence of that, the board came up with this ad hoc process. That seems
very reasonable to me.

For everyone else who has suggestions on how we could run our infra better,
my understanding is that you can get involved in the infrastructure working
group by emailing i...@llvm.org.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bot failure with new "in tree compiler" changes (r316728) in llvm.org bot

[Reid Kleckner via lldb-dev]

In general, please try to structure changes so that CMake cache clobbers
aren't necessary. If you introduce changes that require clobbers by
accident, consider adding some temporary CMake logic to help buildbots
recover on their own. Some temporary CMake hacks can save a lot of time
across all the folks that have to discover and debug this problem.

On Tue, Nov 7, 2017 at 10:28 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> You probably just need to nuke the build folder.
>
> The reason for that is that before the patch the LLDB_TEST_C_COMPILER
> variable was used for a different purpose (and usually empty), where
> as now it's set by default to the in-tree clang. However, cmake will
> not overwrite the cached value by design. (I could have worked around
> that in cmake, but I only noticed that issue after landing the
> change.)
>
> Erasing the build folder should let the new and correct default kick
> in. If you run the check-lldb target then it will now use the in-tree
> clang instead of the system compiler for using tests.
>
> sorry about the trouble,
> pl
>
>
>
> On 7 November 2017 at 18:21, Jim Ingham via lldb-dev
>  wrote:
> > The lldb_cmake GreenDragon bot is now failing, e.g.:
> >
> > http://lab.llvm.org:8080/green/view/LLDB/job/lldb_
> cmake/1703/consoleFull#589016626e9a0fee5-ebcc-4238-a641-c5aa112c323e
> >
> > This looks related to Pavel's change:
> >
> >> r316728 | labath | 2017-10-26 19:24:04 -0700 (Thu, 26 Oct 2017) | 18
> lines
> >>
> >> Default to using in-tree clang for building test executables
> >>
> >> Summary:
> >> Using the in-tree clang should be the default test configuration as that
> >> is the one compiler that we can be sure everyone has (better
> >> reproducibility of test results). Also, it should hopefully reduce the
> >> impact of pr35040.
> >>
> >> This also reduces the number of settings which control the compiler
> >> used. LLDB_TEST_C_COMPILER is used for C files and
> >> LLDB_TEST_CXX_COMPILER for C++ files. Both of the settings default to
> >> the in-tree clang.
> >>
> >> Reviewers: zturner
> >>
> >> Subscribers: mgorny, davide, lldb-commits
> >>
> >> Differential Revision: https://reviews.llvm.org/D39215
> >>
> >
> > The error is:
> >
> > CMake Error at tools/lldb/CMakeLists.txt:78 (message):
> >
> >   LLDB test compilers not specified.  Tests will not run
> >
> >
> > Does the bot need to be reconfigured for these changes?
> >
> > Jim
> >
> > ___
> > 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] Running lit (googletest) tests remotely

[Reid Kleckner via lldb-dev]

You might want to look at the compiler-rt tests, which have support for
remote runs. Search for the '%run' substitution. It's probably not directly
applicable to gtest tests, though.

On Fri, May 26, 2017 at 8:17 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello all,
>
> we are trying to convert some of the lldb tests to lit (for these
> specific tests we are using the googletest format). One of our
> requirements is that we are able to run these tests remotely, so that
> we are able to verify that we can debug e.g. android arm binaries even
> though our development environment runs x86 linux).
>
> As far as I am aware, right now there is no support for that in lit:
> running check-lldb-unit target in a cross-compile situation will
> attempt to run the run the test binaries as if they were native and
> fail horribly.
>
> Based on a not-too-detailed examination of the lit codebase, it does
> not seem that it would be too difficult to add this capability: During
> test discovery phase, we could copy the required files to the remote
> host. Then, when we run the test, we could just prefix the run command
> similarly to how it is done for running the tests under valgrind. It
> would be up to the user to provide a suitable command for copying and
> running files on the remote host (using rsync, ssh, telnet or any
> other transport he chooses).
>
> What do you think? Would something like that be a welcome addition to
> the llvm testing infrastructure? Has anyone tried to do something like
> that and hit major road blocks I did not anticipate?
>
> Or, if you have any suggestions on how to run tests in cross-compile
> setting differently, I'd love to hear about them.
>
> regards,
> pavel
> ___
> 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] About lldbHost

[Reid Kleckner via lldb-dev]

On Wed, Feb 15, 2017 at 10:35 AM, Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
> I am fine with switching mmap over to llvm if it works. One important
> thing to LLDB is we have a "mmap if not on remote file system" that must
> continue to work. If you mmap something from a network drive and then it
> gets disconnected, you can crash LLDB. So we have a function we used that
> implements mmap if local, read all contents if remote, that must work to
> avoid crashes.
>

LLVM's MemoryBuffer API already serves too many different use cases.
Initially it was designed to be a utility for efficiently reading source
file inputs. It has a bunch of functionality around ensuring that the
buffer is null terminated, and a boolean to avoid using mmap when the user
might modify the file concurrently. It's too complicated. I wouldn't
recommend using it without a good reason beyond just reusing a platform
abstraction. mmap and MapViewOfFile are not that complicated. LLDB is
probably better off doing its own thing unless it needs to pass mapped file
contents to other parts of LLVM, like maybe clang's VFS.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Reid Kleckner via lldb-dev]

These issues should be resolved by r295013 and r295014.

On Thu, Feb 9, 2017 at 1:55 PM, Hans Wennborg  wrote:

> I'm happy as long as it builds :-)
>
> On Wed, Feb 8, 2017 at 2:26 PM, Zachary Turner  wrote:
> > Should we do that now, as a way to fix this issue, or should we try to
> get
> > another fix in first so we have more time to think about using std
> > call_once?
> >
> > On Wed, Feb 8, 2017 at 2:19 PM Reid Kleckner  wrote:
> >>
> >> I think we can. MSVC's std::once_flag default constructor is constexpr
> >> now. It still generates dynamic initialization code if you use it as a
> >> static local, but MSVC defaults to using thread safe static
> initialization,
> >> so that isn't a problem unless you disable it, which we don't. We
> disable it
> >> in compiler-rt (/Zc:threadSafeInit-), but that doesn't use this code.
> >>
> >> On Wed, Feb 8, 2017 at 1:18 PM, Zachary Turner 
> wrote:
> >>>
> >>> Is this the right review?  https://reviews.llvm.org/D5922
> >>>
> >>> Being that this was over 2 years ago, I suspect it was when we were
> >>> supporting MSVC2012 and 2013.  Now that we're requiring MSVC2015, is
> it time
> >>> to reconsider? I don't see any links to an MS Connect issue, so I
> don't know
> >>> what the original bug was to know if it has been fixed.
> >>>
> >>>
> >>> On Wed, Feb 8, 2017 at 1:03 PM Reid Kleckner  wrote:
> 
>  It's a sad story. Read the comments and the review threads. It's
>  hilarious.
> 
>  On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev
>   wrote:
> >
> > Why doesn't llvm::call_once() just use std::call_once on Windows?
> >
> > On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg 
> > wrote:
> >>
> >> The Win64 lldb build seems broken (at 294367).
> >>
> >> I ran into this when trying to build the weekly snapshot
> >> (http://www.llvm.org/builds/) which includes LLDB these days.
> >>
> >> I suspect this might be related to Kamil's changes a few days ago. I
> >> see Pavel committed something to fix Darwin afterwards.
> >>
> >> Zach, do you know what's going on here? Do we have any buildbot
> >> coverage for this?
> >>
> >>Creating library lib\liblldb.lib and object lib\liblldb.exp
> >> lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
> >> external symbo
> >> l "void __cdecl llvm::sys::_mm_mfence(void)"
> >> (?_mm_mfence@sys@llvm@@YAXXZ) refer
> >> enced in function "void __cdecl llvm::call_once >>  >> 713e15728a6adc> >(struct llvm::once_flag &,class
> >>  >> 5728a6adc> &&)"
> >> (??$call_once@V@@$$V@ll
> >>
> >> vm@@YAXAEAUonce_flag@0@$$QEAV dc>@@@Z)
> >> bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
> >> LINK failed. with 1120
> >
> >
> > ___
> > 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] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Reid Kleckner via lldb-dev]

I think we can. MSVC's std::once_flag default constructor is constexpr now.
It still generates dynamic initialization code if you use it as a static
local, but MSVC defaults to using thread safe static initialization, so
that isn't a problem unless you disable it, which we don't. We disable it
in compiler-rt (/Zc:threadSafeInit-), but that doesn't use this code.

On Wed, Feb 8, 2017 at 1:18 PM, Zachary Turner  wrote:

> Is this the right review?  https://reviews.llvm.org/D5922
>
> Being that this was over 2 years ago, I suspect it was when we were
> supporting MSVC2012 and 2013.  Now that we're requiring MSVC2015, is it
> time to reconsider? I don't see any links to an MS Connect issue, so I
> don't know what the original bug was to know if it has been fixed.
>
>
> On Wed, Feb 8, 2017 at 1:03 PM Reid Kleckner  wrote:
>
>> It's a sad story. Read the comments and the review threads. It's
>> hilarious.
>>
>> On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Why doesn't llvm::call_once() just use std::call_once on Windows?
>>
>> On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg  wrote:
>>
>> The Win64 lldb build seems broken (at 294367).
>>
>> I ran into this when trying to build the weekly snapshot
>> (http://www.llvm.org/builds/) which includes LLDB these days.
>>
>> I suspect this might be related to Kamil's changes a few days ago. I
>> see Pavel committed something to fix Darwin afterwards.
>>
>> Zach, do you know what's going on here? Do we have any buildbot
>> coverage for this?
>>
>>Creating library lib\liblldb.lib and object lib\liblldb.exp
>> lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
>> external symbo
>> l "void __cdecl llvm::sys::_mm_mfence(void)" (?_mm_mfence@sys@llvm@@YAXXZ)
>> refer
>> enced in function "void __cdecl llvm::call_once> > 713e15728a6adc> >(struct llvm::once_flag &,class > e212a11f7f891e804e713e1
>> 5728a6adc> &&)" (??$call_once@V> dc>@@$$V@ll
>> vm@@YAXAEAUonce_flag@0@$$QEAV> dc>@@@Z)
>> bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
>> LINK failed. with 1120
>>
>>
>> ___
>> 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] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Reid Kleckner via lldb-dev]

It's a sad story. Read the comments and the review threads. It's hilarious.

On Wed, Feb 8, 2017 at 1:00 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Why doesn't llvm::call_once() just use std::call_once on Windows?
>
> On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg  wrote:
>
>> The Win64 lldb build seems broken (at 294367).
>>
>> I ran into this when trying to build the weekly snapshot
>> (http://www.llvm.org/builds/) which includes LLDB these days.
>>
>> I suspect this might be related to Kamil's changes a few days ago. I
>> see Pavel committed something to fix Darwin afterwards.
>>
>> Zach, do you know what's going on here? Do we have any buildbot
>> coverage for this?
>>
>>Creating library lib\liblldb.lib and object lib\liblldb.exp
>> lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
>> external symbo
>> l "void __cdecl llvm::sys::_mm_mfence(void)" (?_mm_mfence@sys@llvm@@YAXXZ)
>> refer
>> enced in function "void __cdecl llvm::call_once> > 713e15728a6adc> >(struct llvm::once_flag &,class > e212a11f7f891e804e713e1
>> 5728a6adc> &&)" (??$call_once@V> dc>@@$$V@ll
>> vm@@YAXAEAUonce_flag@0@$$QEAV> dc>@@@Z)
>> bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
>> LINK failed. with 1120
>>
>
> ___
> 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] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Reid Kleckner via lldb-dev]

Windows.h appears to `#define MemoryFence _mm_fence`. We should probably
undef MemoryFence in llvm/Support/Atomic.h.

On Wed, Feb 8, 2017 at 12:40 PM, Hans Wennborg via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> The Win64 lldb build seems broken (at 294367).
>
> I ran into this when trying to build the weekly snapshot
> (http://www.llvm.org/builds/) which includes LLDB these days.
>
> I suspect this might be related to Kamil's changes a few days ago. I
> see Pavel committed something to fix Darwin afterwards.
>
> Zach, do you know what's going on here? Do we have any buildbot
> coverage for this?
>
>Creating library lib\liblldb.lib and object lib\liblldb.exp
> lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
> external symbo
> l "void __cdecl llvm::sys::_mm_mfence(void)" (?_mm_mfence@sys@llvm@@YAXXZ)
> refer
> enced in function "void __cdecl llvm::call_once  713e15728a6adc> >(struct llvm::once_flag &,class  e212a11f7f891e804e713e1
> 5728a6adc> &&)" (??$call_once@V dc>@@$$V@ll
> vm@@YAXAEAUonce_flag@0@$$QEAV dc>@@@Z)
> bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
> LINK failed. with 1120
> ___
> 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] Prebuilt binary for Windows

[Reid Kleckner via lldb-dev]

On Thu, Jan 12, 2017 at 10:18 AM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I was referring to this: https://support.microsoft.com/en-us/help/
> 2999226/update-for-universal-c-runtime-in-windows.   Granted, it was
> probably marked as non-critical, so some users may have skipped it.
>
> >  One of the redist options is to include an MSU in your installer that
> tells Windows Update to add UCRT to the list of components it updates
>
> We should figure out how to do that.
>
> But meanwhile, do people here agree that LLVM should be built with the /MD
> flag?
>

We should do whatever makes it really simple to add clang to path and run
it without any DLL conflicts. If it's easy to copy the vc runtime DLLs into
our package in a compatible way, great, so long as users can unzip the
package and run it from whereever it is without installing any
dependencies. Static linking just happens to be the easiest way to achieve
that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Reid Kleckner via lldb-dev]

The purpose of linking the CRT statically was to ensure that clang can run
on systems that don't have the CRT already installed from some other app or
by VS itself. As long as that is preserved, feel free to do whatever you
need.

I think we still want to link vcruntime140 statically and the C++ runtime
statically, for example.

On Wed, Jan 11, 2017 at 10:45 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Is static CRT even still supported / recommended when using the new
> Universal CRT?  My understanding is the new UCRT is considered a core
> windows component, so we don't ahve to distribute redistributables
> anymore.  Maybe I'm wrong about this.
>
> That said, I think we want dynamic regardless, otherwise we're back in the
> same boat of user having to compile Python, which is the exact thing 3.5+
> is supposed to solve.  We should just always use dynamic so the user
> doesn't have to do anything and it just works.
>
> On Wed, Jan 11, 2017 at 10:41 AM Vadim Chugunov  wrote:
>
>> Sorry, just found another problem: the installed lldb crashes when given
>> a script via the command line.  For example, `lldb -O "p 42"` dies with
>> exception 0xC409.
>>
>> It didn't happen with the one I've build locally, so I started digging...
>> The difference seems to be that build_llvm_build_package.bat links CRT
>> statically (-DLLVM_USE_CRT_RELEASE=MT), whereas default is the dynamic CRT.
>>
>> The crash kinda makes sense, because python35.dll links CRT dynamically,
>> so LLDB ends up with two copies of it in the process, which is known to
>> cause all sorts of trouble.
>>
>> Not sure what to do about this one, - you probably wanted static CRT to
>> avoid having to install MSVC redistributable?
>>
>>
>> On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov 
>> wrote:
>>
>> Yes, the new build works!
>>
>> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> wrote:
>> >> > This appears to be a SWIG bug: https://github.com/swig/swig/
>> issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner <
>> ztur...@google.com>
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov > >
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov <
>> vadi...@gmail.com>
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> 

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Reid Kleckner via lldb-dev]

I imagine that Hans doesn't have Python 3 installed on his system, so LLDB
didn't autoconfigure with Python support.

On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> > Does the 4.0 binary not work for you? It is the first release that contains
> prebuilt lldb binary.
>
> Looks like the Python API is not included though.   Do you know why it was
> left out?
>
>
> ___
> 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] compile failure with VS 2015 Update 3

[Reid Kleckner via lldb-dev]

Right, the x86_32 calling convention that MSVC uses fails to align such
objects, and this is the error you get if you try. VS 2015 update 3
probably added __declspec(align(8)) to std::atomic<__int64>, triggering
this error if you pass one or an object that contains one by value.

On Thu, Jun 30, 2016 at 3:16 PM, Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I left out some words.  I meant:
>
> The answers on that StackOverflow question claim that 32-bit MSVC never
> does more than 32-byte alignment *for parameters*.
>
> On Thu, Jun 30, 2016 at 3:12 PM, Adrian McCarthy 
> wrote:
>
>> `default_stop_addr` is an `Address` which contains a
>> `std::atomic`.  The `addr_t` is a 64-bit value, so I assume
>> it needs 64-bit alignment.  The answers on that StackOverflow question
>> claim that 32-bit MSVC never does more than 32-byte alignment. So my guess
>> is that this has always been a problem, and the newer compiler is just
>> better at reporting it.
>>
>> On Thu, Jun 30, 2016 at 2:56 PM, Philippe Lavoie <
>> philippe.lav...@octasic.com> wrote:
>>
>>> 32-bit.
>>> --
>>> *From:* Adrian McCarthy [amcca...@google.com]
>>> *Sent:* Thursday, June 30, 2016 5:36 PM
>>> *To:* Philippe Lavoie
>>> *Cc:* lldb-dev@lists.llvm.org
>>> *Subject:* Re: [lldb-dev] compile failure with VS 2015 Update 3
>>>
>>> Compiling for 32-bit or 64-bit?
>>>
>>> This question looks relevant:
>>> http://stackoverflow.com/questions/21743144/using-stdatomic-with-aligned-classes
>>>
>>> On Thu, Jun 30, 2016 at 1:19 PM, Philippe Lavoie via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Hello,

 has anyone tried to compile LLDB with Visual Studio 2015 Update 3 ?

 It compiles fine with Update 2, but with Update 3 we get error messages
 like:

 D:\dev\llvm\tools\lldb\include\lldb/Target/Process.h(3194): error
 C2719:
 'default_stop_addr': formal parameter with requested alignment of 8
 won't be aligned
 (compiling source file
 D:\dev\llvm\tools\lldb\source\Expression\FunctionCaller.cpp)

 although there is no __declspec(align) on that parameter.
 We reported the issue to Microsoft here:

 https://connect.microsoft.com/VisualStudio/feedback/details/2870567/lldb-no-longer-compiles

 -Philippe

 ___
 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] [llvm-dev] Sequential ID Git hook

[Reid Kleckner via lldb-dev]

On Thu, Jun 30, 2016 at 9:16 AM, James Y Knight via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I don't think we should do any of that. It's too complicated -- and I
> don't see the reason to even do it.
>
> There's a need for the "llvm-project" repository -- that's been discussed
> plenty -- but where does the need for a separate "id" that must be pushed
> into all of the sub-projects come from? This is the first I've heard of
> that as a thing that needs to be done.
>
> There was a previous discussion about putting an sequential ID in the
> "llvm-project" repo commit messages (although, even that I'd say is
> unnecessary), but not anywhere else.
>

Agreed, the llvm-project repository can completely take on the role of the
SQL database in Renato's proposal.

Chromium created a "git-number" extension that assigns sequential ids to
commits in the obvious way, and that provided some continuity with the
"git-svn-id:" footers in commit messages. I'm not sure their extension is
particularly reusable, though:
https://chromium.googlesource.com/chromium/tools/depot_tools.git/+/master/git_number.py

I think for LLVM, whatever process updates the umbrella repo should add the
sequential IDs to the commit message, and that will help provide continuity
across the git/svn bridge.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] GitHub anyone?

[Reid Kleckner via lldb-dev]

I'm in favor of both going to git as the source of truth, and then
switching the hosting to github.

Echoing everyone else, this unlocks a lot of good stuff that I won't
repeat, and most of it can be handled independently from the VCS move.

The major blocker I see for the move is figuring out how we want to
coordinate versions between the related LLVM projects. I hear *terrible*
things about submodules, so I'd prefer a different sync mechanism, even if
it is a bad reimplementation of repo, gclient, submodules, and all the
other multi-repo sync tools.

On Tue, May 31, 2016 at 12:31 PM, Renato Golin via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Folks,
>
> There has been some discussion on IRC about SVN hosting and the perils
> of doing it ourselves. The consensus on the current discussion was
> that moving to a Git-only solution would have some disvantages, but
> many advantages. Furthermore, not hosting our own repos would save us
> a lot of headaches, admin costs and timed out connections.
>
> TL;DR: GitHub + git submodules [1] could replace all the functionality
> we have currently with SVN.
>
> (also GitLab, BitBucketc, etc).
>
> Here are some of the arguments made on IRC...
>
> 1. Due to SVN, we can't re-write history. If we use some GitHub
> properties [2], we could have the same effect.
>
> 2. Due to SVN, we have a mandatory time sequence, so commits go first
> in LLVM, then Clang (for example), and buildbots don't get lost. If we
> use submodules [1], we can have a similar relationship, but in a more
> explicit way, and the problem could be solved elegantly.
>
> 3. Some people still can only use SVN. For that, GitHub has an SVN
> interface [3] to the repositories.
>
> 4. We currently host our own SVN/Git, ViewVC and Klaus, Phabricator,
> etc. Not only this incurs in additional admin cost, but it also gets
> outdated, locally modified, and it needs to be backed up, etc. GitHub
> gives all that for us for free.
>
> 5. We can still use Bugzilla (and lock GitHub's own bug system), but
> we can also use GitHub's system to manage releases (it's actually
> quite good for that).
>
> 6. GitHub has automated testing of merge requests, meaning we can have
> pre-commit tests enabled on a set of fast bots, triggered by GitHub's
> own validation hooks. Even though that wouldn't cover everything,
> having a few pre-commit bots would considerably reduce the need to
> revert patches [citation needed].
>
> 7. With git submodules, we'd probably want to follow the same style we
> have today (llvm-projects/) instead of modelling how they look in
> tree (llvm/tools/clang still as a symlink).
>
> 8. Once we're solo Git, we can shop around *much* more easily. By
> using SVN, we're basically forced to host, or choose Source Forge.
> Using just Git, we can choose GitLab, BitBucket and many others, if
> GitHub is not appealing enough. Essentially, it doesn't matter where
> you are, the tools are good, there and largely replaceable [citation
> needed].
>
> What do people think? Any issue not covered that we should? How would
> that disrupt downstream users? Would it be a temporary disruption, but
> with long lasting benefits? Or will it just break everything for you?
>
> cheers,
> --renato
>
>
> [1] https://git-scm.com/book/en/v2/Git-Tools-Submodules
> [2]
> https://help.github.com/articles/defining-the-mergeability-of-pull-requests/
> [3] https://help.github.com/articles/support-for-subversion-clients/
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Redundant six.py copy

[Reid Kleckner via lldb-dev]

On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> It has been noted that LLDB installs its own copy of six.py
> (third_party/Python/module/six/six.py) that conflicts with a standalone
> one lang/py-six (path in pkgsrc).
>
> Could we reuse an external version shipped with a system? Alternatively
> are there plans to migrate to Python 3 and remove need for it?
>
> How to address this conflict cleanly?
>

LLDB should continue to ship its own copy of six.py. It's a single 900 line
source file. Avoiding this duplication is not worth the headache of asking
users to install dependencies. I can't imagine a world where checking in
your own copy *wasn't* the intended distribution model for six.py.

I'm sure LLDB would take patches to mitigate the namespace conflict. For
example, LLDB could do something like "from lldbutils import six" instead
of "import six", or we could avoid putting it on sys.path if we notice a
system installation of six.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB windows build and /bigobj

[Reid Kleckner via lldb-dev]

Which object file has crossed the limit? When this has happened before,
this has usually highlighted over use of templates, which is worth fixing
because it speeds up builds on other platforms as well. If MSVC 2015
instead just happens to generate say one extra section per function, then
we should probably use bigobj.

On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi all,
>
> I pulled in recent changes to upstream llvm, clang and lldb and it seems
> to have tipped my windows build over the edge, and its complaining that
> my object files have exceeded the section limit.
> This error is raised while building the clang libraries.  Has anyone
> else seen this problem while doing an x64 build with with Visual Studio
> 2015?
>
> This problem can be fixed however by specifying /bigobj as a compiler
> flag.  The problem is however that this needs to be given to clang,
> which in turn inherits most of its cmake from llvm.
>
> I have attached my prospective patch for this issue, but wanted to check
> in with the lldb folk first to see if anyone has hit this issue, and if
> they would have any feedback before I submit it to llvm.
>
> Thanks,
> Aidan
>
> --
> Aidan Dodds
> staff software engineer, Debuggers
> Codeplay Software Ltd
> Level C, Argyle House, 3 Lady Lawson St.
> Edinbrgh, EH3 9DR
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
>
> This email and any attachments may contain confidential and /or privileged
> information and is for use by the addressee only. If you are not the
> intended recipient, please notify Codeplay Software Ltd immediately and
> delete the message from your computer. You may not copy or forward it,or
> use or disclose its contents to any other person. Any views or other
> information in this message which do not relate to our business are not
> authorized by Codeplay software Ltd, nor does this message form part of any
> contract unless so stated.
> As internet communications are capable of data corruption Codeplay
> Software Ltd does not accept any responsibility for any changes made to
> this message after it was sent. Please note that Codeplay Software Ltd does
> not accept any liability or responsibility for viruses and it is your
> responsibility to scan any attachments.
> Company registered in England and Wales, number: 04567874
> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>
>
>
>
>
>
>
>
> ___
> 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] LLDB windows build and /bigobj

[Reid Kleckner via lldb-dev]

OK, we've had to change that several times now. At this point I think we
should just enable bigobj on that specific file. I'll try to prepare a
patch.

On Tue, Feb 9, 2016 at 9:52 AM, Aidan Dodds  wrote:

> Hi Reid,
> Thanks for taking a look at this.
> Here was the full error:
>
> llvm\tools\clang\lib\ASTMatchers\Dynamic\Registry.cpp : fatal error C1128: 
> number of sections exceeded object file format limit: compile with /bigobj
>
> That file seems to have quite a bit of macro magic going on, so I'll try
> to dig deeper into this when I'm back in the office tomorrow.
>
>
> On 09/02/2016 17:11, Reid Kleckner wrote:
>
> Which object file has crossed the limit? When this has happened before,
> this has usually highlighted over use of templates, which is worth fixing
> because it speeds up builds on other platforms as well. If MSVC 2015
> instead just happens to generate say one extra section per function, then
> we should probably use bigobj.
>
> On Tue, Feb 9, 2016 at 3:55 AM, Aidan Dodds via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi all,
>>
>> I pulled in recent changes to upstream llvm, clang and lldb and it seems
>> to have tipped my windows build over the edge, and its complaining that
>> my object files have exceeded the section limit.
>> This error is raised while building the clang libraries.  Has anyone
>> else seen this problem while doing an x64 build with with Visual Studio
>> 2015?
>>
>> This problem can be fixed however by specifying /bigobj as a compiler
>> flag.  The problem is however that this needs to be given to clang,
>> which in turn inherits most of its cmake from llvm.
>>
>> I have attached my prospective patch for this issue, but wanted to check
>> in with the lldb folk first to see if anyone has hit this issue, and if
>> they would have any feedback before I submit it to llvm.
>>
>> Thanks,
>> Aidan
>>
>> --
>> Aidan Dodds
>> staff software engineer, Debuggers
>> Codeplay Software Ltd
>> Level C, Argyle House, 3 Lady Lawson St.
>> Edinbrgh, EH3 9DR
>> Tel: 0131 466 0503
>> Fax: 0131 557 6600
>> Website: http://www.codeplay.com
>> Twitter: https://twitter.com/codeplaysoft
>>
>> This email and any attachments may contain confidential and /or
>> privileged information and is for use by the addressee only. If you are not
>> the intended recipient, please notify Codeplay Software Ltd immediately and
>> delete the message from your computer. You may not copy or forward it,or
>> use or disclose its contents to any other person. Any views or other
>> information in this message which do not relate to our business are not
>> authorized by Codeplay software Ltd, nor does this message form part of any
>> contract unless so stated.
>> As internet communications are capable of data corruption Codeplay
>> Software Ltd does not accept any responsibility for any changes made to
>> this message after it was sent. Please note that Codeplay Software Ltd does
>> not accept any liability or responsibility for viruses and it is your
>> responsibility to scan any attachments.
>> Company registered in England and Wales, number: 04567874
>> Registered office: 81 Linkfield Street, Redhill RH1 6BY
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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