On Thu, Aug 11, 2016 at 9:28 AM, Pavel Labath wrote:
> On 10 August 2016 at 22:34, Dangling Pointer
> wrote:
>> Thanks Pavel! I see the changes made in master branch.
>>
>>
>> By any change can these be back-ported to release38 and 39 branches? Since
>> llvm38 is the one aports is offering.
>>
>
ary Turner via lldb-dev
> mailto:lldb-dev@lists.llvm.org> > wrote:
>
> On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner <mailto:clatt...@apple.com> > wrote:
>
>> On Aug 9, 2016, at 3:01 PM, Zachary Turner via lldb-dev
>> mailto:lldb-dev@lists.llvm.org&g
t; - Will we stop using _sp and _up on the end of shared and unique
> pointers?
>
> --
> 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-d
lldb
> coding conventions doc.
>
> Jim
>
> > On Aug 11, 2016, at 11:20 AM, Zachary Turner via lldb-dev
> > mailto:lldb-dev@lists.llvm.org>> wrote:
> >
> > On Wed, Aug 10, 2016 at 10:37 PM Chris Lattner > <mailto:clatt...@apple.com>>
> On Aug 11, 2016, at 12:19 PM, Ted Woodward via lldb-dev
> wrote:
>
> I don’t think we can completely get rid of the lldb coding conventions doc;
> we’ll need this type of thing as long as we use swig:
>
> · enumerations that might end up being in the lldb S
On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton wrote:
>
> > - Will we stop putting m_ at the front of class ivars and g_ at
> the front of globals?
>
> I believe these make things much clearer and I would love to see llvm and
> clang adopt some way to identify member variables. "m_" might
> On Aug 11, 2016, at 3:40 PM, Zachary Turner wrote:
>
>
> On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton wrote:
>
> > - Will we stop putting m_ at the front of class ivars and g_ at
> > the front of globals?
>
> I believe these make things much clearer and I would love to see llvm a
On Thu, Aug 11, 2016 at 4:05 PM Greg Clayton wrote:
>
> If we go camel case then debugger_sp would become DebuggerSP.
>
The problem is that's already the name of the typedef in lldb-forward.h :(
Unless we get rid of all those (also not entirely opposed to that TBH).
> On Aug 11, 2016, at 3:40 PM, Zachary Turner via lldb-dev
> wrote:
>
>
> On Thu, Aug 11, 2016 at 3:28 PM Greg Clayton <mailto:gclay...@apple.com>> wrote:
>
> > - Will we stop putting m_ at the front of class ivars and g_ at
> > the fron
Hi,
I do run a basic set of tests (compile+run test suite) on linux from
time to time, but unfortunately I don't have time to be more active in
this. I have just completed the test on the release branch with these
changes cherry-picked and it seems to working fine. But I certainly
agree that the r
On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
wrote:
> I recommend approaching this in three steps:
>
> 1) get the less-controversial changes done that Greg was outlining.
> 2) start a discussion in the llvm community about the concept of a
> member/global prefix.
>
> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev
> wrote:
>
> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
> wrote:
>> I recommend approaching this in three steps:
>>
>> 1) get the less-controversial changes done that Greg was outlining.
>
I've merged r277997, r277999 and r278001 to 3.9 in r278540.
Cheers,
Hans
On Fri, Aug 12, 2016 at 1:02 AM, Pavel Labath wrote:
> Hi,
>
> I do run a basic set of tests (compile+run test suite) on linux from
> time to time, but unfortunately I don't have time to be more active in
> this. I have jus
On Linux, given a core dump file, an executable and its symbols, is it possible
to do the following in LLDB (maybe with a LLDB extension)?
1. Get the list of all C++ virtual types (classes with virtual function table)
2. Search the whole address space to find all instances of such objects? (false
> On Aug 12, 2016, at 4:55 PM, Lei Kong via lldb-dev
> wrote:
>
> On Linux, given a core dump file, an executable and its symbols, is it
> possible to do the following in LLDB (maybe with a LLDB extension)?
>
> 1. Get the list of all C++ virtual types (classes
erent files, but it should be manageable.
pl
On 12 August 2016 at 18:13, Jim Ingham wrote:
>
>> On Aug 12, 2016, at 5:23 AM, Pavel Labath via lldb-dev
>> wrote:
>>
>> On 12 August 2016 at 00:54, Chris Lattner via lldb-dev
>> wrote:
>>> I recommend appr
On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I've sampled the python code from the llvm repository, and it seems to
> be using a mixture of 4-, 2-, and even 8- character indent, with 4
> being the most prevalent. So, I thin
lvm.org>
Subject: Re: [lldb-dev] Search C++ "virtual" objects
> On Aug 12, 2016, at 4:55 PM, Lei Kong via lldb-dev
> wrote:
>
> On Linux, given a core dump file, an executable and its symbols, is it
> possible to do the following in LLDB (maybe with a LLDB ext
Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then
lldb::SBModule::GetSymbolAtIndex() to go through all symbols?
Thanks.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Lei Kong via lldb-dev<mailto:lldb-dev@lists.llvm.
> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev
> wrote:
>
> On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev
> mailto:lldb-dev@lists.llvm.org>> wrote:
> I've sampled the python code from the llvm repository, and it seems to
> be using
Hello,
I was trying to get Code Coverage for LLDB with GCOV on Linux by
adding the corresponding flags in the CMake files, but I am facing problem
with lldb-server, which does not give seem to generate the gcda files. The
host side does generate the gcov files although. The lldb-server does
I recently started using lldb to write a basic instrumentation tool for
tracking the values of variables at various code-points in a program. I've
been working with lldb for less than two weeks, so I am pretty new. Though,
I have used and written llvm passes in the past, so I'm familiar with the
cl
text-switches
and packet traffic while you were running in the hot parts of your code. This
is a decent chunk of work, however.
Jim
> On Aug 16, 2016, at 9:57 AM, Benjamin Dicken via lldb-dev
> wrote:
>
> I recently started using lldb to write a basic instrumentation tool for
, you may want to double-check that the gcda files are being written to the
right directory.
best,
vedant
> On Aug 16, 2016, at 7:58 AM, Ravitheja Addepally via lldb-dev
> wrote:
>
> Hello,
>I was trying to get Code Coverage for LLDB with GCOV on Linux by
> adding the
r. This would eliminate some of
> the context-switches and packet traffic while you were running in the hot
> parts of your code. This is a decent chunk of work, however.
>
> Jim
>
>
> > On Aug 16, 2016, at 9:57 AM, Benjamin Dicken via lldb-dev <
> lldb-dev@lists.llv
g like the gdb
> "tracepoints" were you can upload instructions to perform "experiments" when
> a breakpoint is hit to the lldb-server instance. The work to perform the
> experiment and the results would all be kept in the lldb-server instance till
> a real breakpoi
> On Aug 15, 2016, at 4:59 PM, Lei Kong wrote:
>
> Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then
> lldb::SBModule::GetSymbolAtIndex() to go through all symbols?
> Thanks.
This is the only way right now as we don't have a SBModule::FindSymbols that
takes a regular
tion we've toyed with on and off is something like the gdb
> "tracepoints" were you can upload instructions to perform "experiments"
> when a breakpoint is hit to the lldb-server instance. The work to perform
> the experiment and the results would all be kept in t
m>
Cc: Lei Kong via lldb-dev<mailto:lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] Search C++ "virtual" objects
> On Aug 15, 2016, at 4:59 PM, Lei Kong wrote:
>
> Should I use lldb::SBTarget::GetModuleAtIndex() to get all modules and then
> lldb::SBModule
16 August 2016 at 21:43, Benjamin Dicken via lldb-dev
wrote:
>
>
> On Tue, Aug 16, 2016 at 11:06 AM, Jim Ingham wrote:
>>
>>
>> > On Aug 16, 2016, at 10:42 AM, Benjamin Dicken
>> > wrote:
>> >
>> > Thanks for the quick reply.
>> >
xt and
> cmake/modules/HandleLLVMOptions.cmake).
>
> Also, you may want to double-check that the gcda files are being written
> to the
> right directory.
>
> best,
> vedant
>
>
> > On Aug 16, 2016, at 7:58 AM, Ravitheja Addepally via lldb-dev <
> lldb-dev@lists.ll
Hi everyone,
I am currently implementing the support for the Intel MPX registers in LLDB.
This register set includes 2 registers, BNDSTATUS and BNDCFGU, which store
information about the status and configuration of the MPX feature in several
fields.
I think that it would be useful for the user
w the LLVM_BUILD_INSTRUMENTED cmake option is implemented to
> double-check that you've got something reasonable (see: llvm/CMakeLists.txt
> and
> cmake/modules/HandleLLVMOptions.cmake).
>
> Also, you may want to double-check that the gcda files are being written to
> the
> rig
terValues really want to be scalars, so they don't provide a natural way
to do this. You would probably have to convert "register read" over to use the
ValueObject for this project to be worth doing.
Jim
> On Aug 17, 2016, at 8:17 AM, Giusti, Valentina via lldb-dev
> wrote:
nt: Tuesday, August 16, 2016 11:42 AM
> To: Lei Kong
> Cc: Lei Kong via lldb-dev
> Subject: Re: [lldb-dev] Search C++ "virtual" objects
>
>
> > On Aug 15, 2016, at 4:59 PM, Lei Kong wrote:
> >
> > Should I use lldb::SBTarget::GetModuleAtIndex() to ge
> On Aug 17, 2016, at 8:17 AM, Giusti, Valentina via lldb-dev
> wrote:
>
> Hi everyone,
>
> I am currently implementing the support for the Intel MPX registers in LLDB.
> This register set includes 2 registers, BNDSTATUS and BNDCFGU, which store
> informat
Thanks for your replies!
@Greg, I think I will start by trying your approach and then I will get back to
you with some feedback in a couple of days.
Cheers,
- Valentina
> -Original Message-
> > I am currently implementing the support for the Intel MPX registers in LLDB.
> This register
veryone who has chimed in with suggestions, and with contributions
to ensure that include ordering doesn’t become an issue on other platforms.
Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
Xcode Low Level Tools
> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev
> wro
> On Aug 18, 2016, at 2:37 AM, via lldb-dev wrote:
>
> Hi All,
>
> I am trying to remote debug. My code is on 10.11 and my test machine is
> 10.12, Sierra. I am using Xcode 5 on both machines. I am following below
> steps for remote debugging:
> Test mach
Dear testers,
3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
This is a release candidate in the very real sense that if nothing new
comes up, this is be what the final release looks like. There are
currently no open release blockers, and no patches in my merge-queue.
Please build, tes
s.
>
> Kate Stone k8st...@apple.com
> Xcode Low Level Tools
>
> On Aug 15, 2016, at 8:50 AM, David Jones via lldb-dev
> wrote:
>
> On Mon, Aug 15, 2016 at 2:36 AM, Pavel Labath via lldb-dev
> wrote:
>>
>> I've sampled the python code from the llvm rep
swift-lldb repository on GitHub.
Any concerns?
Kate Stone k8st...@apple.com <mailto:k8st...@apple.com>
Xcode Low Level Tools
> On Aug 18, 2016, at 11:15 AM, Kate Stone via lldb-dev
> wrote:
>
> If there’s consensus on a reasonable automated formatting solution for Python
&g
On 19 August 2016 at 02:51, Hans Wennborg via Release-testers
wrote:
> This is a release candidate in the very real sense that if nothing new
> comes up, this is be what the final release looks like. There are
> currently no open release blockers, and no patches in my merge-queue.
ARM binaries go
Hi,
built successfully and passed initial tests on OpenMandriva x86_64,
aarch64, i586 and armv7hnl.
ttyl
bero
On 19 August 2016 at 03:51, Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:
> Dear testers,
>
> 3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
>
> T
On 19 Aug 2016, at 03:51, Hans Wennborg via Release-testers
wrote:
>
> 3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
>
> This is a release candidate in the very real sense that if nothing new
> comes up, this is be what the final release looks like. There are
> currently no open rel
Le 19/08/2016 à 03:51, Hans Wennborg via Release-testers a écrit :
Dear testers,
3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
This is a release candidate in the very real sense that if nothing new
comes up, this is be what the final release looks like. There are
currently no open r
On 19 August 2016 at 22:10, Kate Stone via lldb-dev
wrote:
> Following up from yesterday, everything now builds and runs cleanly with the
> configuration described below on macOS. I did have to make one set of minor
> changes to preserve #include ordering, but that’s already committed
I've been trying to understand why some Linux core files fail to load in
lldb.
The problem seems to be that in the ELF header Linux uses the
ELFOSABI_NONE (0x0) value rather than ELFOSABIT_LINUX (0x3).If I either
change the e_ident[EI_OSABI] byte to 0x3 in the header or the code in
ArchSpec.cp
> On Aug 22, 2016, at 6:00 AM, Howard Hellyer via lldb-dev
> wrote:
>
> I've been trying to understand why some Linux core files fail to load in
> lldb.
>
> The problem seems to be that in the ELF header Linux uses the ELFOSABI_NONE
> (0x0) value rather th
On Sat, Aug 20, 2016 at 2:45 PM, Sylvestre Ledru wrote:
> Le 19/08/2016 à 03:51, Hans Wennborg via Release-testers a écrit :
>>
>> Dear testers,
>>
>> 3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
>>
>> This is a release candidate in the very real sense that if nothing new
>> comes up,
We're getting close to the final release. I know the schedule on the
web page says 'final' should be tagged today, but I still think it
should be possible to get there this week.
Source and binaries for LLVM-3.9.0-rc2 are now available at
http://llvm.org/pre-releases/3.9.0/#rc2
Please try it out
n Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
Clayton via lldb-dev
Sent: Monday, August 22, 2016 11:00 AM
To: Howard
Hello everybody,
Just want to let you know that the first LLVM Social in Berlin will happen this
Thursday, 19:00 CET.
The place is a nice co-working space/cafe called Betahaus:
https://www.google.com/maps?f=q&hl=en&q=Prinzessinnenstrasse+19-20+10969,+,+Berlin,+de
Looking forward to meet you all
Hi Hans,
I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the
wrong one?
Cheers,
Renato
On 22 Aug 2016 7:55 p.m., "Hans Wennborg via Release-testers" <
release-test...@lists.llvm.org> wrote:
> We're getting close to the final release. I know the schedule on the
> web page s
I replied on the "has been tagged" thread; I couldn't find the binary
on the sftp. Maybe you uploaded the wrong version, or in some other
folder?
On Mon, Aug 22, 2016 at 4:01 PM, Renato Golin wrote:
> Hi Hans,
>
> I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the
> wrong o
On 22 August 2016 at 16:03, Ted Woodward via lldb-dev
wrote:
>
> We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is historically
> ELFOSABI_SYSV, and used by a lot of things. So not all core files identified
> as ELFOSABI_NONE are Linux.
Indeed, and that's
On 19 August 2016 at 17:10, Kate Stone via lldb-dev
wrote:
>
> Sept 5th Trunk closes for commits while reformatting takes place and is
> validated before re-opening trunk.
This is fine with me.
As for validation, from my perspective I want to make sure the FreeBSD
build-only buildbot
> I would change it so that the "os" doesn't get set to anything when
> it detects this in the core file. When an OS is not specified, the
> llvm::Triple will return OSUnknown as the enumeration value for the
> OS _and_ the llvm::StringRef value will return an empty string. This
> is known in LL
"Ted Woodward" wrote on 22/08/2016 21:03:02:
> We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is
> historically ELFOSABI_SYSV, and used by a lot of things. So not all
> core files identified as ELFOSABI_NONE are Linux.
I agree that other OS's may use it or have used it in the p
Should we consider adding git hyper-blame to llvm and recommending its
usage?
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
On Tue, Aug 23, 2016 at 6:44 AM Ed Maste via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> On 19 Augus
On 23 August 2016 at 11:55, Zachary Turner wrote:
>
> Should we consider adding git hyper-blame to llvm and recommending its usage?
Nifty, I hadn't encountered git hyper-blame before. Thanks Zach.
If I understand correctly all we need to do is add a
`.git-blame-ignore-revs` file to the lldb root
Pretty much, yea.
On Tue, Aug 23, 2016 at 12:24 PM Ed Maste wrote:
> On 23 August 2016 at 11:55, Zachary Turner wrote:
> >
> > Should we consider adding git hyper-blame to llvm and recommending its
> usage?
>
> Nifty, I hadn't encountered git hyper-blame before. Thanks Zach.
>
> If I understand
2016 at 20:34, Zachary Turner via lldb-dev
wrote:
> Pretty much, yea.
>
> On Tue, Aug 23, 2016 at 12:24 PM Ed Maste wrote:
>>
>> On 23 August 2016 at 11:55, Zachary Turner wrote:
>> >
>> > Should we consider adding git hyper-blame to llvm and recomm
Dear testers,
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 - [lld] Add a note that 3.9 is a major milestone for us
r279468, r279474 - Fix gather-root.ll SLP vectorizer
On Thursday, August 25, 2016 11:42 AM, Hans Wennborg via Release-testers
wrote:
Dear testers,
3.9.0-rc3 was just tagged from the branch at r279704.
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.
Ubun
On 25 August 2016 at 04:42, Hans Wennborg via Release-testers
wrote:
> Dear testers,
>
> 3.9.0-rc3 was just tagged from the branch at r279704.
ARM and AArch64 seem fine, binaries uploaded:
ARM sha1sum: d1bc90d475f8d764f1ff7524ba2f3e26acb8a463
AArch64 sha1sum: 5e4e3bdf747aa2ac50c588cea5d67f896376
eral times.
On Tue, Aug 23, 2016 at 6:49 AM, Howard Hellyer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> "Ted Woodward" wrote on 22/08/2016 21:03:02:
>
> > We don't want to make ELFOSABI_NONE mean Linux. ELFOSABI_NONE is
> > historically ELFOSABI_SYSV,
On Mon, Aug 8, 2016 at 2:57 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
>
>
> On Mon, Aug 8, 2016 at 2:40 PM Kate Stone via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> LLDB has come a long way since the project was first announced. As
t one implementation of that, but you could design one that has build
commands, c++ source, and Python all in one file, or even intermingled like
in an lldbinline test
On Thu, Aug 25, 2016 at 12:54 PM Todd Fiala wrote:
> On Mon, Aug 8, 2016 at 2:57 PM, Zachary Turner via lldb-dev <
> lldb-dev@
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 - [lld] Add a note that 3.9 is a major
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 more time looking into
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 th
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
Li
> On Aug 26, 2016, at 7:25 AM, Christian Convey via lldb-dev
> wrote:
>
> 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; // &
There shouldn't be a problem figuring this out right?
Greg
> On Aug 26, 2016, at 8:17 AM, Ted Woodward via lldb-dev
> wrote:
>
> 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
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 awa
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 your code and it
>> will force
ble file from the target
and also check the target's architecture or the main executable's architecture.
There shouldn't be a problem figuring this out right?
Greg
> On Aug 26, 2016, at 8:17 AM, Ted Woodward via lldb-dev
> wrote:
>
> That works fine for host debug,
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 req
> 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. As a result of this, LLDB is uncompilable due to a slew of
> errors of the following nature:
>
> D:\src
> 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. As
tee
that a function parameter is 8-byte aligned without allocating from the
heap, which is obviously impossible for a stack variable.
On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton wrote:
>
> > On Aug 26, 2016, at 11:24 AM, Greg Clayton via lldb-dev <
> lldb-dev@lists.llvm.org> wr
> 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 believ
ess the data through
accessors.
On Fri, Aug 26, 2016 at 11:36 AM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> 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
> 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 write to
nction signature, so they can both figure out where the actual struct
> lives in the argument slot based on the alignment of the stack slot.
>
> Jim
>
>
> >
> > On Fri, Aug 26, 2016 at 11:29 AM Greg Clayton
> wrote:
> >
> > > On Aug 26, 2016, at 11:24 AM,
r wrote:
>
> 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
urora Forum, a Linux
Foundation Collaborative Project
-Original Message-
From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Jim Ingham
via lldb-dev
Sent: Friday, August 26, 2016 2:32 PM
To: Zachary Turner
Cc: LLDB
Subject: 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
the only class that is causing problems?
Greg
> 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. As a result of this, LLDB is uncompilable due to a slew of
> errors
h 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> wrote:
> >
> > I recently updated to Visual Studio 2015 Update 3, which has improved
> it
> 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 c
oblem.
On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini wrote:
> 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.
>
>
>
the problem.
>
> On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini wrote:
>
>> 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
mp; rhs) :
> m_section_wp (rhs.m_section_wp),
> m_offset(rhs.m_offset.load()) // this is the std::atomic<>
> {
> }
>
> circumventing the problem.
>
> On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini <mailto:mehdi.am...@apple.com>> wrote:
>
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 LLVM-3.9.0-rc3-win32.exe
e840f6b729d
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 a
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 (openmp-...@lists.llvm.org)
> Cc: Re
> 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 Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini wrote:
>>
t;>
> > {
> > }
> >
> > circumventing the problem.
> >
> > On Fri, Aug 26, 2016 at 1:11 PM Mehdi Amini
> wrote:
> >> On Aug 26, 2016, at 1:02 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >&g
3601 - 3700 of 9283 matches
Mail list logo
