Re: [lldb-dev] Symbol Server for everyone.

By platform agnostic i mean having a single symbol server that works across multiple platforms is very nice. It sounds like in addition to being a symbol server this can also serve source code, and should work with embedded debug info, split dwo, or even pdb? On Fri, Aug 26, 2016 at 9:54 PM Taras

Re: [lldb-dev] Symbol Server for everyone.

Making the SymbolVendor dependent on Python is probably a non starter, and it would also make debugging more difficult. We have network code for various platforms in Host already. It would be nice to have a symbol server format that is platform agnostic. On the other hand, Microsoft tools

Re: [lldb-dev] [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries available

Hans, Are these new RC3 Windows binaries now with asserts disabled? Kind Regards Dan From: Hans Wennborg via cfe-dev Sent: 26 August 2016 22:30 To: llvm-dev; cfe-dev; LLDB

Re: [lldb-dev] [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries available

Many thanks, I will be giving these a thorough test. From: Hans Wennborg Sent: 26 August 2016 23:28 To: Dan Walmsley Cc: Hans Wennborg via cfe-dev; llvm-dev; LLDB

Re: [lldb-dev] LLDB Evolution

Yea, all I did was copy the code and reduce the indent level. There are other issues with the code that are non-conformant for LLVM style, but clang-format can catch all of those. It can't early indent your code for you :) On Fri, Aug 26, 2016 at 6:17 PM Mehdi Amini

Re: [lldb-dev] LLDB Evolution

> On Aug 26, 2016, at 6:12 PM, Zachary Turner via lldb-dev > wrote: > > Back to the formatting issue, there's a lot of code that's going to look bad > after the reformat, because we have some DEEPLY indented code. LLVM has > adopted the early return model for this

Re: [lldb-dev] LLDB Evolution

Back to the formatting issue, there's a lot of code that's going to look bad after the reformat, because we have some DEEPLY indented code. LLVM has adopted the early return model for this reason. A huge amount of our deeply nested code could be solved by using early returns. For example,

Re: [lldb-dev] Passing std::atomics by value

How would you enforce that, other than to ask people to try to remember not to do it? It seems to me like std::atomic not being copy-constructible is telling you that, well, you shouldn't be copying it. BTW, nobody has commented on my original concern that the atomic may not even be necessary in

Re: [lldb-dev] Passing std::atomics by value

There is no need to delete the lldb_private::Address copy constructor. Just stop functions from passing it by value. > On Aug 26, 2016, at 1:13 PM, Zachary Turner wrote: > > IOW, marking it =delete() is no different than deleting the copy constructor > above, but at least

Re: [lldb-dev] [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries available

On Fri, Aug 26, 2016 at 3:23 PM, Dan Walmsley via cfe-dev wrote: >Are these new RC3 Windows binaries now with asserts disabled? Yes. Thanks, Hans > From: Hans Wennborg via cfe-dev > Sent: 26 August 2016 22:30 > To: llvm-dev; cfe-dev; LLDB Dev; openmp-dev

[lldb-dev] [3.9 Release] Release Candidate 3 source and binaries available

We're very very close to the final release. Source and binaries for LLVM-3.9.0-rc3 are available at http://llvm.org/pre-releases/3.9.0/#rc3 This release candidate is almost the same as rc2, with the following additional commits: r279224 - Minor change to OpenCL release notes r279260 - [lld] Add

Re: [lldb-dev] [3.9 Release] Release Candidate 3 has been tagged

On Wed, Aug 24, 2016 at 8:42 PM, Hans Wennborg wrote: > Please take this for a spin. If there are no hiccups, the plan is to > promote this to 'final' on Friday and ship the release early next > week. Windows is ready: 12f424c28f22b1c60f531da2f4ba86e5cdd1ca9c

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 1:13 PM, Zachary Turner wrote: > > IOW, marking it =delete() is no different than deleting the copy constructor > above, but at least if you mark it delete, maybe someone will read the > comment above it that explains why it's deleted :) Got it, make

Re: [lldb-dev] Passing std::atomics by value

IOW, marking it =delete() is no different than deleting the copy constructor above, but at least if you mark it delete, maybe someone will read the comment above it that explains why it's deleted :) On Fri, Aug 26, 2016 at 1:13 PM Zachary Turner wrote: > I think so. But in

Re: [lldb-dev] Passing std::atomics by value

I think so. But in this case lldb::Address explicitly supplied a copy constructor that looked like this: Address (const Address& rhs) : m_section_wp (rhs.m_section_wp), m_offset(rhs.m_offset.load()) // this is the std::atomic<> { } circumventing the problem. On

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev > 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

Re: [lldb-dev] Passing std::atomics by value

It seems to be. I will also make the copy constructor =delete() to make sure this cannot happen again. 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

Re: [lldb-dev] Passing std::atomics by value

Incidentally, it seems copy and assignment of std::atomics are deleted functions, so the C++ standard is telling you you're not really supposed to do this. I honestly don't believe this should be a std::atomic at all. On Fri, Aug 26, 2016 at 12:54 PM Ted Woodward via lldb-dev <

Re: [lldb-dev] Passing std::atomics by value

Would the misalignment really be a problem on x86? I thought the core handled misaligned loads and stores. Unlike, say, PPC. Either way, I'd expect the compiler to automatically align a uint64. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora

Re: [lldb-dev] Passing std::atomics by value

That seems to me a compiler bug, not: "You can't pass structures with std::atomic" elements in them by value. It would crazy to add a type to the C++ language that you couldn't use everywhere. There doesn't seem to be any official restriction. And anecdotally there's a reference to the

Re: [lldb-dev] Passing std::atomics by value

It could, in theory, it just doesn't. I compiled a quick program using i686-darwin as the target and the generated assembly makes no attempt to pad the arguments. I'll post some code later On Fri, Aug 26, 2016 at 11:42 AM Jim Ingham wrote: > > > On Aug 26, 2016, at 11:36 AM,

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 11:44 AM, Adrian McCarthy via lldb-dev > wrote: > > Methods like Address::SetOffset and Address::Slide seem to have data races > despite m_offset being atomic. Callers of those methods would have to > guarantee that nothing else is trying to

Re: [lldb-dev] Passing std::atomics by value

Methods like Address::SetOffset and Address::Slide seem to have data races despite m_offset being atomic. Callers of those methods would have to guarantee that nothing else is trying to write to m_offset. And if they're doing that, then there doesn't appear to be a need for std::atomic on that

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 11:36 AM, Zachary Turner via lldb-dev > wrote: > > The thing is, the code is already full of data races. I think the > std::atomic is actually used incorrectly and is not even doing anything. > > That said, consider darwin on 32-bit, where I

Re: [lldb-dev] Passing std::atomics by value

The thing is, the code is already full of data races. I think the std::atomic is actually used incorrectly and is not even doing anything. That said, consider darwin on 32-bit, where I believe each stack frame is 4-byte aligned. I dont' think there's any way the compiler can guarantee that a

Re: [lldb-dev] Passing std::atomics by value

> On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev > wrote: > >> >> On Aug 26, 2016, at 10:51 AM, Zachary Turner via lldb-dev >> wrote: >> >> I recently updated to Visual Studio 2015 Update 3, which has improved its >> diagnostics.

[lldb-dev] Passing std::atomics by value

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

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

After the core file is loaded in ProcessElfCore::DoLoadCore, the logic under "target create" will merge the ArchSpec of the target and the core, replacing the "unknown" OS in the core ArchSpec with "linux" from the target ArchSpec. Howard, are you loading a target executable, or just the core?

Re: [lldb-dev] Watching reads/writes on optimized variables?

Maybe the volatile keyword? volatile int x = 10; > On Aug 26, 2016, at 9:27 AM, Christian Convey > wrote: > > Hi Greg, > > >>> >>> Does anyone know of a way to minimize or eliminate this problem? >> >> Just take the address of your variable at some point in

Re: [lldb-dev] Watching reads/writes on optimized variables?

Hi Greg, >> >> Does anyone know of a way to minimize or eliminate this problem? > > Just take the address of your variable at some point in your code and it will > force it into memory. Thanks for your idea. I can see why taking the variable's address (in an expression that's not optimized

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

It is ok for a core file to not pledge allegiance to an OS, it is ok for the OS to be set to "*" or any OS. Linux core files are useless without the main executable anyway so these two things should used together to do the right thing. When creating the core files you use: lldb::ProcessSP

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

That works fine for host debug, but not so much for embedded. On Hexagon, we support 2 OS cases - standalone (which means no OS, or an OS that lldb doesn't know anything about) and Linux. Both our standalone simulator and our Linux generate core dumps using ELFOSABI_NONE. We run lldb on both x86

[lldb-dev] Watching reads/writes on optimized variables?

Hi guys, I'm trying to use watchpoints to detect user-space reads/writes of an arbitrary C/C++ program variable. For example: void foo() { int x; // <-- I'm interested in 'x' x = 10; // <-- I want to detect this for (int i = 0; i < 4; ++i) { x = i; // <-- And

Re: [lldb-dev] Linux ELF header e_ident[EI_OSABI] value

Todd Fiala wrote on 25/08/2016 20:42:31: > FWIW, I've taken a few whacks at getting Linux detected better over > the last few years, and haven't yet found a reliable way to detect > it from quite a few samples of cores from a number of different > systems. We can spend

Re: [lldb-dev] [Release-testers] [3.9 Release] Release Candidate 3 has been tagged

On 25 Aug 2016, at 05:42, Hans Wennborg via Release-testers wrote: > > 3.9.0-rc3 was just tagged from the branch at r279704. > > This one is very similar to rc2. These are the only new commits: > > r279224 - Minor change to OpenCL release notes > r279260 -