[llvm] r235955 - DebugInfo: Support up to 2^16 arguments in a subprogram

Duncan P. N. Exon Smith dexonsmith at apple.com
Tue Jun 2 10:33:11 PDT 2015


> On 2015-Apr-28, at 09:24, David Blaikie <dblaikie at gmail.com> wrote:
> 
> On Tue, Apr 28, 2015 at 2:32 AM, Joerg Sonnenberger
> <joerg at britannica.bec.de> wrote:
>> On Tue, Apr 28, 2015 at 01:07:34AM -0000, Duncan P. N. Exon Smith wrote:
>>> Author: dexonsmith
>>> Date: Mon Apr 27 20:07:33 2015
>>> New Revision: 235955
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=235955&view=rev
>>> Log:
>>> DebugInfo: Support up to 2^16 arguments in a subprogram
>>> 
>>> Support up to 2^16 arguments to a function.  If we do hit the limit,
>>> assert out rather than restarting at 0 as we've done historically.
>> 
>> Given that this can be triggered easily by user input, should this
>> really be an assert?
> 
> Probably not - ideally it'd fail in the verifier, I'd imagine. But I'm
> not too fussed personally.

Somehow I missed this review until now :/.  Sorry Joerg.

I think the assertion in LLVM is correct: the LLVM libraries don't
support 2^16 arguments, so we should assert out if a frontend tries
to create debug info for a subprogram with that many.  Since we can
catch this at creation time, there's no need to delay until a
Verifier check.  (Although an extra check there might not hurt?
I'm indifferent there.)

Previously, we would have died somewhere strange in the backend;
the only real change here is that we die at debug info creation
time.  This makes it easier for frontend authors to figure out what
they've done wrong.

However, clang (and other frontends!) shouldn't die at all, as you
point out.  They should have logic to detect when there are more
arguments than LLVM supports, and avoid creating debug info for
those.  This isn't a priority for me, but it's probably not hard to
do if you feel like tackling it.



More information about the llvm-commits mailing list