> On Mar 30, 2018, at 4:34 PM, Duncan P. N. Exon Smith <dexonsm...@apple.com>
> wrote:
>
> +Adrian
>
> I suspect the crash reporters are giving you results based solely on the
> symbol table. The dSYM has extra information from the debug info so it can
> fill in the gaps. Perhaps the crash reporters aren't using the dSYMs, but
> Xcode is?
I'm not familiar with the crash reporters you mentioned, but what Duncan said
is accurate. Xcode, lldb, and atos will use the inlining debug information
stored in the debug info (the dSYM) to also show the inlined stack frames. The
tools you were using probably don't.
-- adrian
>
> Any ideas Adrian?
>
>> On Mar 30, 2018, at 16:28, Michael Eisel via cfe-users
>> <cfe-users@lists.llvm.org> wrote:
>>
>> Hi,
>>
>> I've been playing around with a stack trace of inlined functions, e.g.:
>>
>> void __attribute__((always_inline)) f1() {
>> f2();
>> }
>>
>> void __attribute__((noinline)) f2() {
>> f3();
>> }
>>
>> void __attribute__((always_inline)) f3() {
>> abort();
>> }
>>
>> When I use various crash reporters, like PLCrashReporter and Crashlytics, I
>> don't see f1 or f3 in the stack trace, implying that inline functions aren't
>> included. However, when I cause the crash in the Xcode debugger, I see the
>> inline functions in the stack trace. Is there additional context that Xcode
>> would have, e.g. with symbols in the binary, that the crash reporters with
>> their dSYM files don't?
>>
>> Thanks,
>> Michael
>> _______________________________________________
>> cfe-users mailing list
>> cfe-users@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
_______________________________________________
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
