On Feb 25, 2013, at 5:37 PM, Eric Christopher <[email protected]> wrote:
> On Mon, Feb 25, 2013 at 5:34 PM, John McCall <[email protected]> wrote:
> On Feb 25, 2013, at 5:14 PM, Eric Christopher <[email protected]> wrote:
>> On Mon, Feb 25, 2013 at 5:02 PM, John McCall <[email protected]> wrote:
>> On Feb 25, 2013, at 4:55 PM, Adrian Prantl <[email protected]> wrote:
>> > here’s another patch for review:
>> >
>> > Allocate stack storage for .block_descriptor and captured self.
>> > This way the register allocator will not optimize away the the
>> > debug info for captured variables.
>>
>> Allocating stack storage is not the right way to fix this problem.
>> The frontend is emitting the right intrinsics to say that the argument
>> is being kept in an LLVM value, not in memory. If that's not working,
>> then basically all optimized debug info is useless.
>>
>>
>> That's pretty accurate. The backend in a lot of places is depending upon an
>> alloca existing in order to get a location for a variable. To make optimized
>> debug info work we're going to need to fix that assumption.
>
> When did this become true? I know that at least *some* debugging used
> to work in blocks, and we haven't been making allocas for them in a while.
> Maybe it was a really brittle, but some things used to survive at least to the
> point that GDB could consume them.
>
>
> Nothing has changed as far as debug info, it was just always pretty brittle.
>
> If we *must* do this as a temporary debug info workaround, then the
> appropriate solution for things like the block descriptor is to make the
> alloca, slam a value into it, and use that for the debug info intrinsic, but
> not otherwise change IR-generation for the function.
>
> Agreed, though there's something to be said for not changing it and fixing
> the underlying problems in the backend.
Right; the problems in the backend definitely need to be fixed. I am just
skeptical that anybody working on the backend cares enough to fix them.
If we can avoid this workaround, we should.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
