> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > It seems to be. I will also make the copy constructor =delete() to make sure > this cannot happen again.
Just curious: if a member has a deleted copy-ctor (like std::atomic right?), isn’t the copy constructor automatically deleted? — Mehdi > > I'm still concerned that the std::atomic is unnecessary, but at that point at > least it just becomes a performance problem and not a bug. > > On Fri, Aug 26, 2016 at 1:00 PM Greg Clayton <gclay...@apple.com > <mailto:gclay...@apple.com>> wrote: > So after speaking with local experts on the subject, we do indeed have a > problem. Please convert all placed where we pass lldb_private::Address by > value to pass by "const Address &". Anyone that is modifying the address > should make a local copy and work with that. > > Is Address the only class that is causing problems? > > Greg > > > On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev > > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > > > I recently updated to Visual Studio 2015 Update 3, which has improved its > > diagnostics. As a result of this, LLDB is uncompilable due to a slew of > > errors of the following nature: > > > > D:\src\llvm\tools\lldb\include\lldb/Target/Process.h(3256): error C2719: > > 'default_stop_addr': formal parameter with requested alignment of 8 won't > > be aligned > > > > The issue comes down to the fact that lldb::Address contains a > > std::atomic<uint64_t>, and is being passed by value pervasively throughout > > the codebase. There is no way to guarantee that this value is 8 byte > > aligned. This has always been a bug, but until now the compiler just > > hasn't been reporting it. > > > > Someone correct me if I'm wrong, but I believe this is a problem on any > > 32-bit platform, and MSVC is just the only one erroring. > > > > I'm not really sure what to do about this. Passing std::atomic<uint64>'s > > by value seems wrong to me. > > > > Looking at the code, I don't even know why it needs to be atomic. It's not > > even being used safely. We'll have a single function write the value and > > later read the value, even though it could have been used in the meantime. > > Maybe what is really intended is a mutex. Or maybe it doesn't need to be > > atomic in the first place. > > > > Does anyone have a suggestion on what to do about this? I'm currently > > blocked on this as I can't compile LLDB. > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > <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
