On 06/04/10 05:12, Curtis Faith wrote:> I concur. I've run into this exact assert at least 10 different times in the last two weeks since I started with LLVM as I'm learning the particulars of the typing system for function calls in particular. > > It would be nice if it would tell you what expected signature was, what the value of i was so you know which parameter went wrong, and what the actual type passed in was, as well as what was expected. You can get this information yourself but it is a real pain. >Jeffrey Yasskin had a tip some time ago about this particular assertion: "In general, when I hit one of those assertions, I gdb to it, use "p f->dump()" to see the types of the function's arguments, and use "p Params[i]->dump()" to see the parameter with the bad type." HTH, Paul
Thanks for forwarding Jeffrey's tip Paul. Unfortunately, coming mostly from the application programming side, I haven't seriously used a command line debugger since the Apple IIe days in the early 80s (geez, i guess that makes me kinda old as far as programmers go). So I'm not familiar with gdb even at an intermediate level. Not that gdb isn't ubiquitous for tools development or any sort of development on Linux/Unix. For application development, however, most people use an IDE. I've been doing mostly application development for the last 30 years. I'm currently using Xcode, which is both fortunately and unfortunately a gdb-based debugger, so I can use your suggestion. I'm just returning to Mac development from a long and painful journey to the hell and back that is windows MFC which stands for Most F&$*'d-Up Class Library, so I'm not yet even a seasoned Xcoder. Still, as many of the people approaching LLVM will be considering it for embedding functionality within an application environment, I suspect that a considerable number of them will be IDE-saavy like me more than command-line tool saavy. This will be especially true of anyone coming from Windows as the Visual C++ IDE is actually an excellent product where you don't need to use the command line to do anything (Did I just complement a Microsoft product? I must be ill.) Since this is an open-source project, I'll take a stab at improving the diagnostics messages for the gdb ignorant (or lazy like me) among us and submit the patch. LLVM is so great in many ways, I want to do my part to help make sure that others get a favorable first impression when they try to implement a proof of concept design as part of their evaluation of the suitability of LLVM for their project. - Curtis On Jun 5, 2010, at 3:27 AM, Paul Melis wrote:> On 06/04/10 05:12, Curtis Faith wrote: >> I concur. I've run into this exact assert at least 10 different times in the last two weeks since I started with LLVM as I'm learning the particulars of the typing system for function calls in particular. >> >> It would be nice if it would tell you what expected signature was, what the value of i was so you know which parameter went wrong, and what the actual type passed in was, as well as what was expected. You can get this information yourself but it is a real pain. >> > Jeffrey Yasskin had a tip some time ago about this particular assertion: > > "In general, when I hit one of those assertions, I gdb to it, use "p > f->dump()" to see the types of the function's arguments, and use "p > Params[i]->dump()" to see the parameter with the bad type." > > HTH, > Paul > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Jeffrey Yasskin
2010-Jun-05 19:41 UTC
[LLVMdev] Why asserts don't provide much information?
Don't all IDEs have a debugger that can set a breakpoint and call
functions from the program to see what they print? If you can't set
breakpoints or call dump() on an LLVM value, you're going to have more
problems than just this assertion.
I don't think it's worth annotating all assertions with extra
information, but this one probably happens often enough to deserve it.
If anyone wants to beef it up, you can follow the example in ~Value:
#ifndef NDEBUG // Only in -g mode...
// Check to make sure that there are no uses of this value that are still
// around when the value is destroyed. If there are, then we have a dangling
// reference and something is wrong. This code is here to print out what is
// still being referenced. The value in question should be printed as
// a <badref>
//
if (!use_empty()) {
dbgs() << "While deleting: " << *VTy << "
%" << getNameStr() << "\n";
for (use_iterator I = use_begin(), E = use_end(); I != E; ++I)
dbgs() << "Use still stuck around after Def is destroyed:"
<< **I << "\n";
}
#endif
assert(use_empty() && "Uses remain when a value is
destroyed!");
On Sat, Jun 5, 2010 at 6:24 AM, Curtis Faith <curtis_faith at yahoo.com>
wrote:> Thanks for forwarding Jeffrey's tip Paul.
>
> Unfortunately, coming mostly from the application programming side, I
haven't seriously used a command line debugger since the Apple IIe days in
the early 80s (geez, i guess that makes me kinda old as far as programmers go).
So I'm not familiar with gdb even at an intermediate level.
>
> Not that gdb isn't ubiquitous for tools development or any sort of
development on Linux/Unix. For application development, however, most people use
an IDE. I've been doing mostly application development for the last 30
years. I'm currently using Xcode, which is both fortunately and
unfortunately a gdb-based debugger, so I can use your suggestion. I'm just
returning to Mac development from a long and painful journey to the hell and
back that is windows MFC which stands for Most F&$*'d-Up Class Library,
so I'm not yet even a seasoned Xcoder.
>
> Still, as many of the people approaching LLVM will be considering it for
embedding functionality within an application environment, I suspect that a
considerable number of them will be IDE-saavy like me more than command-line
tool saavy. This will be especially true of anyone coming from Windows as the
Visual C++ IDE is actually an excellent product where you don't need to use
the command line to do anything (Did I just complement a Microsoft product? I
must be ill.)
>
> Since this is an open-source project, I'll take a stab at improving the
diagnostics messages for the gdb ignorant (or lazy like me) among us and submit
the patch.
>
> LLVM is so great in many ways, I want to do my part to help make sure that
others get a favorable first impression when they try to implement a proof of
concept design as part of their evaluation of the suitability of LLVM for their
project.
>
> - Curtis
>
>
>
> On Jun 5, 2010, at 3:27 AM, Paul Melis wrote:
>
>> On 06/04/10 05:12, Curtis Faith wrote:
>>> I concur. I've run into this exact assert at least 10 different
times in the last two weeks since I started with LLVM as I'm learning the
particulars of the typing system for function calls in particular.
>>>
>>> It would be nice if it would tell you what expected signature was,
what the value of i was so you know which parameter went wrong, and what the
actual type passed in was, as well as what was expected. You can get this
information yourself but it is a real pain.
>>>
>> Jeffrey Yasskin had a tip some time ago about this particular
assertion:
>>
>> "In general, when I hit one of those assertions, I gdb to it, use
"p
>> f->dump()" to see the types of the function's arguments,
and use "p
>> Params[i]->dump()" to see the parameter with the bad
type."
>>
>> HTH,
>> Paul
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>