[PATCH v3 5/5] objdump: Add test on option --map-global-vars display global variable information

[Jan Beulich]

On 01.09.2025 19:50, Guillaume VACHERIAS wrote:
> --- a/binutils/testsuite/binutils-all/objdump.exp
> +++ b/binutils/testsuite/binutils-all/objdump.exp
> @@ -959,6 +959,45 @@ proc test_objdump_S { } {
>  
>  test_objdump_S
>  
> +# Test objdump --map-global-vars on file containing dwarf-2 encoding information.
> +
> +proc test_objdump_map_global_vars { } {
> +    global srcdir
> +    global subdir
> +    global OBJDUMP
> +    global OBJDUMPFLAGS
> +    global exe
> +
> +    set test "objdump --map-global-vars"
> +
> +    if { [target_compile $srcdir/$subdir/objdump-map-global-vars.c tmpdir/objdump-map-global-vars${exe} executable debug] != "" } {
> +      unsupported "$test (build)"
> +      return
> +    }
> +
> +    if [is_remote host] {
> +      set testfile [remote_download host tmpdir/objdump-map-global-vars${exe}]
> +    } else {
> +      set testfile tmpdir/objdump-map-global-vars${exe}
> +    }
> +
> +    set got [remote_exec host "$OBJDUMP $OBJDUMPFLAGS --map-global-vars $testfile" "" "/dev/null" "tmpdir/objdump.out"]
> +
> +    if { [lindex $got 0] != 0 || ![string match "" [lindex $got 1]] } then {
> +       fail "objdump --map-global-vars (reason: unexpected output)"
> +       send_log $got
> +       send_log "\n"
> +    }
> +
> +    if { [regexp_diff tmpdir/objdump.out $srcdir/$subdir/objdump.map-global-vars] } then {
> +      fail "objdump --map-global-vars"
> +    } else {
> +      pass "objdump --map-global-vars"
> +    }
> +}

This looks like open-coding to me, but I'm not familiar enough with expect
to make any concrete suggestion towards possible improvements.

> --- /dev/null
> +++ b/binutils/testsuite/binutils-all/objdump.map-global-vars
> @@ -0,0 +1,86 @@
> +.*objdump-map-global-vars:     file format .*
> +
> +a @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: char, size: 0x1
> +
> +b @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: int, size: 0x(2|4|8)
> +
> +c @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: long .*, size: 0x(4|8)
> +
> +d @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: ptr, size: 0x(4|8)
> +
> +e @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: volatile
> +  type: int, size: 0x(2|4|8)
> +
> +f @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: const
> +  type: int, size: 0x(2|4|8)
> +
> +g @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: enum _enum, size: 0x(2|4)
> + {
> +  value: E1 = 0
> +  value: E2 = 1
> +  value: E3 = 2
> + }
> +
> +h @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: struct _struct, size: 0x(4|8)
> + {
> +   member: m1, offset: 0x0
> +    type: char, size: 0x1
> +   member: m2, offset: 0x(4|8)
> +    type: enum _enum, size: 0x(2|4)
> +    {
> +     value: E1 = 0
> +     value: E2 = 1
> +     value: E3 = 2
> +    }
> + }
> +
> +i @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: union _union, size: 0x(2|4|8)
> + {
> +   member: u1, offset: 0x0
> +    type: char, size: 0x1
> +   member: u2, offset: 0x0
> +    type: ptr, size: 0x(2|4|8)
> +     type: const
> +      type: char, size: 0x1
> + }
> +
> +j @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: typedef node
> + {
> +  type: struct _node, size: 0x(4|8|10)
> +  {
> +    member: value, offset: 0x0
> +     type: int, size: 0x(2|4|8)
> +    member: next, offset: 0x(4|8)
> +     type: ptr, size: 0x(2|4|8)
> +      nested: struct _node
> +  }
> + }
> +
> +k @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: array\[4\]\[2\]
> +  type: typedef node
> +  {
> +   type: struct _node, size: 0x(4|8|10)
> +   {
> +     member: value, offset: 0x0
> +      type: int, size: 0x(2|4|8)
> +     member: next, offset: 0x8
> +      type: ptr, size: 0x(2|4|8)
> +       nested: struct _node
> +   }
> +  }
> +
> +l @ 0x([0-9a-fA-F]{8}) 0x([0-9a-fA-F]{8})
> + type: array\[2\]
> +  type: ptr, size: 0x(2|4|8)
> +   type: char, size: 0x1

What guarantees that these variables will appear in this order in the
output?

Jan