Hi
is this funny function AppleObjCRuntimeV1::CreateObjectChecker actually
used ?
First of all the snprintf is wrapped in an assert (!?). If the code gets
compiled with -DNDEBUG, the function would pretty much do nothing.
Second, I guess, that this is some C-code that gets compiled on the
| It's not sanely possible to enumerate all the possibilities
Not looking for that. Looking to avoid being trolled. ("Trolled" isn't the
right word here but I've lost track of what the right one is. Hopefully my
intent is clear enough.)
| I guess one could write "In addition, violations of thi
On Fri, Jul 1, 2016 at 7:27 AM, Robinson, Paul
wrote:
> | It's not sanely possible to enumerate all the possibilities
>
> Not looking for that. Looking to avoid being trolled. ("Trolled" isn't
> the right word here but I've lost track of what the right one is. Hopefully
> my intent is clear eno
On 6/30/2016 5:20 PM, Robinson, Paul via cfe-dev wrote:
> We were using tags for a while in our own SVN->git conversion internally.
> (git branch is pushed to SVN and the SVN r-number used to create a tag.)
> They are convenient for some things, but each tag adds a new (if small)
> file to .git/tag
On 6/30/2016 6:18 PM, Jim Rowan via cfe-dev wrote:
>
> On Jun 30, 2016, at 2:25 PM, Robinson, Paul via llvm-dev
> mailto:llvm-...@lists.llvm.org>> wrote:
>
> (talking about lots of tags)
>
>> I don't know that it really scales well when you
>> are talking about (long term) hundreds of thousands of
On 1 July 2016 at 08:18, Tom Honermann via lldb-dev
wrote:
> On 6/30/2016 5:20 PM, Robinson, Paul via cfe-dev wrote:
> We're using tags in this manner for our internal repos and LLVM/Clang
> mirrors and haven't experienced any problems. We're at ~50k tags for
> our most used repo, so not quite at
I'm not sure why you're stuck on thinking I want an enumeration of offenses.
What I'm looking for (and AFAICT also Rafael and maybe other people) is a
clearer statement that "offenses" outside of LLVM-defined spaces need to meet a
much higher bar to be considered problematic within the LLVM commu
Your guess about the use of the checkers is right. The code you are looking at
compiles and inserts this function in the target, then when compiling future
expressions, if we detect a reference to an ObjC object, we insert a call to
the checker into the JIT'ed code before accessing the object.
On Fri, Jul 1, 2016 at 10:05 AM, Robinson, Paul
wrote:
> I'm not sure why you're stuck on thinking I want an enumeration of
> offenses.
>
Sorry, it's because i don't see a way to give you the below without it :)
> What I'm looking for (and AFAICT also Rafael and maybe other people) is a
> clear
| I don't actually disagree with your criticism, IMHO, i just don't know of a
way to generate more clarity.
Well that's something anyway. Thanks.
--paulr
From: Daniel Berlin [mailto:dber...@dberlin.org]
Sent: Friday, July 01, 2016 10:32 AM
To: Robinson, Paul
Cc: Rafael Espíndola; LLDB; cfe-...@
I don't have access to a linux machine that can currently build LLVM, Clang and
LLDB (all are machines that are administered by others and the cmake is too old
to build top of tree). It should be trivial to get working if you can debug it.
Greg Clayton
___
So it turns out that TLS variables on linux have been broken all along. I
backed out my changes and the test still failed. The test had a decorator:
@unittest2.expectedFailure("rdar://7796742")
That was causing it to expected fail for everyone. I fixed 7796742 and took off
the decorator, b
On 1 July 2016 at 18:32, Daniel Berlin via lldb-dev
wrote:
>> The single word "rare" in the current code doesn't feel like enough.
>
> I don't actually disagree with your criticism, IMHO, i just don't know of a
> way to generate more clarity.
Paul, Rafael, Daniel,
With the intention of being pra
On 1 July 2016 at 17:32, Tim Northover wrote:
> My issue with using tags like this is that they pollute the tag
> namespace and will quickly swamp what I consider to be the important
> ones ("release-X"). OK, so we've got "git tag -l 'release*'" but
> that's pretty ugly.
What if we had a mixed mo
https://llvm.org/bugs/show_bug.cgi?id=28392
Bug ID: 28392
Summary: Thread local variables are not working on Linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
15 matches
Mail list logo
