assigned to @emaste

This is on FreeBSD 9.2, with libc.so built with the default system compiler GCC 4.2.1. I suspect this is an issue with the DWARF generated by that old GCC and that newer GCC or clang will not demonstrate this problem.

A related failure is that I'm seeing on my FreeBSD 9.2 test system is test/expression_command/test/TestExprs.py, also a failing printf expression:

(lldb) expr printf("\t\x68\n")
error: Execution was interrupted, reason: invalid address (fault address: 0xfffffffffffffffe).
The process has been returned to the state before expression evaluation.

The expression parser produces:

Function disassembly:
0x8007d9010: 55 pushq %rbp
0x8007d9011: 48 89 e5 movq %rsp, %rbp
0x8007d9014: 41 57 pushq %r15
0x8007d9016: 41 56 pushq %r14
0x8007d9018: 41 54 pushq %r12
0x8007d901a: 53 pushq %rbx
0x8007d901b: 48 83 ec 10 subq $0x10, %rsp
0x8007d901f: 48 89 fb movq %rdi, %rbx
0x8007d9022: 49 bf 00 90 7d 00 08 00 00 00 movabsq $0x8007d9000, %r15
0x8007d902c: 45 31 e4 xorl %r12d, %r12d
0x8007d902f: 31 c0 xorl %eax, %eax
0x8007d9031: 41 ff d7 callq *%r15
0x8007d9034: 4c 8b 33 movq (%rbx), %r14
0x8007d9037: 48 8d 7d d8 leaq -0x28(%rbp), %rdi
0x8007d903b: 31 c0 xorl %eax, %eax
0x8007d903d: 41 ff d7 callq *%r15
0x8007d9040: 48 89 5d d8 movq %rbx, -0x28(%rbp)
0x8007d9044: 45 84 e4 testb %r12b, %r12b
0x8007d9047: 75 20 jne 0x8007d9069
0x8007d9049: 49 8d 87 50 09 65 00 leaq 0x650950(%r15), %rax
0x8007d9050: 48 bf 00 80 7d 00 08 00 00 00 movabsq $0x8007d8000, %rdi
0x8007d905a: ff d0 callq *%rax
0x8007d905c: 89 c3 movl %eax, %ebx
0x8007d905e: 31 c0 xorl %eax, %eax
0x8007d9060: 4c 89 f7 movq %r14, %rdi
0x8007d9063: 41 ff d7 callq *%r15
0x8007d9066: 41 89 1e movl %ebx, (%r14)
0x8007d9069: 48 83 c4 10 addq $0x10, %rsp
0x8007d906d: 5b popq %rbx
0x8007d906e: 41 5c popq %r12
0x8007d9070: 41 5e popq %r14
0x8007d9072: 41 5f popq %r15
0x8007d9074: 5d popq %rbp
0x8007d9075: c3 retq

without detecting printf as a varargs function it can't be called correctly

Ed: I would check your DWARF for debug info for "printf". If there is a function prototype, LLDB could either be parsing it wrong, or it might be wrong in the DWARF. If you can attach the executable that contains the DWARF for "printf", I can probably tell you more.

Looks like you need to attach the ELF file for libc.so.7 that contains the DWARF debug info.

vararg test
vararg demo

It looks like there is more to this issue than I thought. Simple varargs test attached.

Building with the system compiler on my laptop, FreeBSD 11-CURRENT / clang 3.4 gives me:

joule% cc --version
FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 2014021
Target: x86_64-unknown-freebsd11.0
Thread model: posix
joule% cc -g -Wall vararg.c
joule% readelf -a a.out
...
< 1><0x00000026> DW_TAG_subprogram
DW_AT_name sum
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000004
DW_AT_prototyped yes(1)
DW_AT_type <0x0000007c>
DW_AT_external yes(1)
DW_AT_low_pc 0x004006f0
DW_AT_high_pc 0x004008ee
DW_AT_frame_base DW_OP_reg6
< 2><0x00000043> DW_TAG_formal_parameter
DW_AT_name count
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000004
DW_AT_type <0x0000007c>
DW_AT_location DW_OP_fbreg -4
< 2><0x00000051> DW_TAG_variable
DW_AT_name ap
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000006
DW_AT_type <0x000000cb>
DW_AT_location DW_OP_fbreg -32
< 2><0x0000005f> DW_TAG_variable
DW_AT_name i
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000007
DW_AT_type <0x0000007c>
DW_AT_location DW_OP_fbreg -36
< 2><0x0000006d> DW_TAG_variable
DW_AT_name sum
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000007
DW_AT_type <0x0000007c>
DW_AT_location DW_OP_fbreg -40
< 1><0x0000007c> DW_TAG_base_type
DW_AT_name int
DW_AT_encoding DW_ATE_signed
DW_AT_byte_size 0x00000004
...

(lldb) expr sum(2, 1, 1)
error: no matching function for call to 'sum'
note: candidate function not viable: requires 1 argument, but 3 were provided
error: 1 errors parsing expression

DWARF output from our old GCC is somewhat different:
joule% gcc --version
gcc (GCC) 4.2.1 20070831 patched [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

joule% gcc -g -Wall vararg.c
dwarfdump -a a.out
...
< 1><0x000001a9> DW_TAG_subprogram
DW_AT_external yes(1)
DW_AT_name sum
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000005
DW_AT_prototyped yes(1)
DW_AT_type <0x000000ae>
DW_AT_low_pc 0x004006f0
DW_AT_high_pc 0x00400845
DW_AT_frame_base <loclist with 3 entries follows>
[ 0]<lowpc=0x00000000><highpc=0x00000001>DW_OP_breg7+8
[ 1]<lowpc=0x00000001><highpc=0x00000004>DW_OP_breg7+16
[ 2]<lowpc=0x00000004><highpc=0x00000155>DW_OP_breg6+16
DW_AT_sibling <0x0000020b>
< 2><0x000001ce> DW_TAG_formal_parameter
DW_AT_name count
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000004
DW_AT_type <0x000000ae>
DW_AT_location DW_OP_fbreg -228
< 2><0x000001df> DW_TAG_unspecified_parameters
< 2><0x000001e0> DW_TAG_variable
DW_AT_name ap
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000006
DW_AT_type <0x0000019a>
DW_AT_location DW_OP_fbreg -224
< 2><0x000001ee> DW_TAG_variable
DW_AT_name i
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000007
DW_AT_type <0x000000ae>
DW_AT_location DW_OP_fbreg -200
< 2><0x000001fb> DW_TAG_variable
DW_AT_name sum
DW_AT_decl_file 0x00000001 /tank/emaste/src/snippets/vararg.c
DW_AT_decl_line 0x00000007
DW_AT_type <0x000000ae>
DW_AT_location DW_OP_fbreg -196
...

Looks like DW_TAG_unspecified_parameters should report that this is a vararg fn, but lldb reports the same error for this case.

This is a clang bug. It should be emitting a DW_TAG_unspecified_parameters tag after the DW_TAG_formal_parameter children in a DW_TAG_subprogram, DW_TAG_inlined_subroutine, or DW_TAG_subroutine_type.

There is a long standing bug tracking this in clang at apple: 13690847

If you file a bug on Bugzilla, you should reference the apple bug number.

I fixed LLDB to be ready for the clang change with:

% svn commit source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Sending source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Sending source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
Transmitting file data ..
Committed revision 202061.

So now if you file a bugzilla bug on clang, you can track when it gets fixed on the clang side. Marking as fixed because LLDB is ready for the clang changes.

Works w/ gcc after r202061 (http://llvm.org/viewvc/llvm-project?rev=202061&view=rev)

Unfortunately Clang does not (yet) emit DW_TAG_unspecified_parameters, so still fails when built w/ Clang

Clang bug: http://llvm.org/bugs/show_bug.cgi?id=18950