[PATCH]: Add a flag to the DWARF Compile Unit to indicate if it was compiled with ARC

Eric Christopher echristo at gmail.com
Mon May 13 14:57:37 PDT 2013


On Mon, May 13, 2013 at 2:35 PM, John McCall <rjmccall at apple.com> wrote:
> On May 13, 2013, at 1:44 PM, Eric Christopher <echristo at gmail.com> wrote:
>> On Mon, May 13, 2013 at 1:25 PM, Adrian Prantl <aprantl at apple.com> wrote:
>>>
>>> On May 13, 2013, at 11:57 AM, Eric Christopher <echristo at gmail.com> wrote:
>>>
>>>> Eh? Curious what this will be used for?
>>> This would be interesting mostly for the debugger but I guess tools like Instruments would also like to know.
>>
>> In what way? I.e. why add it?
>
> It's a language mode, Eric.  It's smaller in scope than C++ but on approximately the same scope as OpenCL.  Users have a reasonable expectation that source-aware tools like debuggers and profilers will know what language the source code is written in.
>

I'm perfectly aware of what ARC is and you'll notice I mentioned other
options earlier. One of the current accepted dwarf issues is adding
OpenCL to the language list. Whether or not this is worth adding a new
language enum entry was one thing I had specifically brought up.

> Off-hand, here are some ways that a tool might take advantage of knowing that it's analyzing an ARC program:
>   - it could enable better support for printing weak variables
>   - it could automatically use appropriate semantics for assigning into weak or strong variables with an expression
>   - it could correctly handle ARC-specific language constructs in the expression evaluator
>   - it could take it as a general license to intercept the ARC runtime calls
>   - it could monitor retain/release events and advise the user when a retain cycle was formed or broken
>

Sure. While most of this can be trivially handled by attributes on
variables and looking at the program perhaps a language enum addition
is the best way if it's such a different language. After all we have
c89 and c99 to help deal with different default semantics there, but
no C++11 because that was handled by general types and attributes. If
we want to handle a bunch of arc features I'm asking these questions
to figure out the best way to support them long term.

-eric



More information about the llvm-commits mailing list