Re: [PATCHv3] gdb/python: add gdb.format_address function

[Simon Marchi <simon.marchi@polymtl.ca>]

> Hi Simon,
>
> Sorry for that.  I can't reproduce these failures, but I suspect I know
> what's going on.  Could you try the patch below please and confirm that
> this fixes the issues.
>
> Many thanks,
> Andrew
>
> ---
>
> commit d6eb0c69d3919a1b3862d29c788415ca9f7bbeb4
> Author: Andrew Burgess <aburgess@redhat.com>
> Date:   Wed Mar 23 15:23:47 2022 +0000
>
>     gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp
>
>     The test gdb.python/py-format-address.exp, added in commit:
>
>       commit 25209e2c6979c3838e14e099f0333609810db280
>       Date:   Sat Oct 23 09:59:25 2021 +0100
>
>           gdb/python: add gdb.format_address function
>
>     Included 3 copy & paste errors where the wrong address was used in the
>     expected output patterns.
>
>     The test compiles two almost identical test binaries (one function
>     changes its name, that's the only difference), if the two binaries are
>     laid out the same by the compiler, and loaded at the same locations in
>     memory, then the two addresses would have been the same.  However,
>     this is not the case for everyone, and so some folk were seeing test
>     failures:
>
>       https://sourceware.org/pipermail/gdb-patches/2022-March/186911.html
>
>     This commit fixes the errors by using the correct addresses.

Hi Andrew,

I looked into this separately because I failed to see your message.  In
the end I came up with the same change, but the reason the addresses are
different is that the executables are PIE.  Inferior 1 is running, so
the function address is relocated:

 print /x &foo^M
 $2 = 0x555555555129^M

Inferior 2 is not running, so the function address is unrelocated:

 print /x &bar^M
 $3 = 0x1129^M

So, the patch LGTM, but you can clarify the commit message if you want.

Simon