On Wed, 2023-01-25 at 22:52 +0000, Alan Maguire wrote:
[...]
>
> Thanks for this - I tried it, and we spot the optimization once we update
> die__create_new_parameter() as follows:
>
> diff --git a/dwarf_loader.c b/dwarf_loader.c
> index f96b6ff..605ad45 100644
> --- a/dwarf_loader.c
> +++ b/dwarf_loader.c
> @@ -1529,6 +1530,8 @@ static struct tag *die__create_new_parameter(Dwarf_Die *di
>
> if (ftype != NULL) {
> ftype__add_parameter(ftype, parm);
> + if (parm->optimized)
> + ftype->optimized_parms = 1;
> if (param_idx >= 0) {
> if (add_child_llvm_annotations(die, param_idx, conf, &(t
> return NULL;
>
Great, looks good.
> With that change, I see:
>
> $ pahole --verbose --btf_encode_detached=test.btf test.o
> btf_encoder__new: 'test.o' doesn't have '.data..percpu' section
> Found 0 per-CPU variables!
> Found 2 functions!
> File test.o:
> [1] INT int size=4 nr_bits=32 encoding=SIGNED
> [2] PTR (anon) type_id=3
> [3] PTR (anon) type_id=4
> [4] INT char size=1 nr_bits=8 encoding=SIGNED
> [5] FUNC_PROTO (anon) return=1 args=(1 argc, 2 argv)
> [6] FUNC main type_id=5
> added local function 'f', optimized-out params
> skipping addition of 'f' due to optimized-out parameters
Sorry, I have one more silly program.
I talked to Yonghong today and we discussed if compiler can change a
type of a function parameter as a result of some optimization.
Consider the following example:
$ cat test.c
struct st {
int a;
int b;
};
__attribute__((noinline))
static int f(struct st *s) {
return s->a + s->b;
}
int main(int argc, char *argv[]) {
struct st s = {
.a = (long)argv[0],
.b = (long)argv[1]
};
return f(&s);
}
When compiled by `clang` with -O3 the prototype of `f` is changed from
`int f(struct *st)` to `int f(int, int)`:
$ clang -O3 -g -c test.c -o test.o && llvm-objdump -d test.o
...
0000000000000000 <main>:
0: 8b 3e movl (%rsi), %edi
2: 8b 76 08 movl 0x8(%rsi), %esi
5: eb 09 jmp 0x10 <f>
7: 66 0f 1f 84 00 00 00 00 00 nopw (%rax,%rax)
0000000000000010 <f>:
10: 8d 04 37 leal (%rdi,%rsi), %eax
13: c3 retq
But generated DWARF hides this information:
$ llvm-dwarfdump test.o
...
0x0000005c: DW_TAG_subprogram
DW_AT_low_pc (0x0000000000000010)
DW_AT_high_pc (0x0000000000000014)
DW_AT_frame_base (DW_OP_reg7 RSP)
DW_AT_call_all_calls (true)
DW_AT_name ("f")
DW_AT_decl_file ("/home/eddy/work/tmp/test.c")
DW_AT_decl_line (7)
DW_AT_prototyped (true)
DW_AT_type (0x00000074 "int")
0x0000006b: DW_TAG_formal_parameter
DW_AT_name ("s")
DW_AT_decl_file ("/home/eddy/work/tmp/test.c")
DW_AT_decl_line (7)
DW_AT_type (0x0000009e "st *")
0x00000073: NULL
...
Is this important?
(gcc does not do this for the particular example, but I don't know if
it could be tricked to under some conditions).
Thanks,
Eduard
[...]
