[PATCH] scripts/gdb: fix debugging modules on s390

[PATCH] scripts/gdb: fix debugging modules on s390

[Ilya Leoshkevich]

Currently lx-symbols assumes that module text is always located at
module->core_layout->base, but s390 uses the following layout:

+------+  <- module->core_layout->base
| GOT  |
+------+  <- module->core_layout->base + module->arch->plt_offset
| PLT  |
+------+  <- module->core_layout->base + module->arch->plt_offset +
| TEXT |     module->arch->plt_size
+------+

Therefore, when trying to debug modules on s390, all the symbol
addresses are skewed by plt_offset + plt_size.

Fix by adding plt_offset + plt_size to module_addr in
load_module_symbols().

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
 scripts/gdb/linux/symbols.py | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
index f0d8f2ecfde7..41c6d1a55b03 100644
--- a/scripts/gdb/linux/symbols.py
+++ b/scripts/gdb/linux/symbols.py
@@ -15,7 +15,7 @@ import gdb
 import os
 import re
 
-from linux import modules
+from linux import modules, utils
 
 
 if hasattr(gdb, 'Breakpoint'):
@@ -113,6 +113,12 @@ lx-symbols command."""
         if module_file:
             gdb.write("loading @{addr}: {filename}\n".format(
                 addr=module_addr, filename=module_file))
+            if utils.is_target_arch('s390'):
+                # Module text is preceded by PLT stubs on s390.
+                module_arch = module['arch']
+                plt_offset = int(module_arch['plt_offset'])
+                plt_size = int(module_arch['plt_size'])
+                module_addr = hex(int(module_addr, 0) + plt_offset + plt_size)
             cmdline = "add-symbol-file {filename} {addr}{sections}".format(
                 filename=module_file,
                 addr=module_addr,
-- 
2.23.0

Re: [PATCH] scripts/gdb: fix debugging modules on s390

[Jan Kiszka]

On 15.10.19 12:53, Ilya Leoshkevich wrote:
> Currently lx-symbols assumes that module text is always located at
> module->core_layout->base, but s390 uses the following layout:
> 
> +------+  <- module->core_layout->base
> | GOT  |
> +------+  <- module->core_layout->base + module->arch->plt_offset
> | PLT  |
> +------+  <- module->core_layout->base + module->arch->plt_offset +
> | TEXT |     module->arch->plt_size
> +------+
> 
> Therefore, when trying to debug modules on s390, all the symbol
> addresses are skewed by plt_offset + plt_size.
> 
> Fix by adding plt_offset + plt_size to module_addr in
> load_module_symbols().
> 
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
> ---
>  scripts/gdb/linux/symbols.py | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/gdb/linux/symbols.py b/scripts/gdb/linux/symbols.py
> index f0d8f2ecfde7..41c6d1a55b03 100644
> --- a/scripts/gdb/linux/symbols.py
> +++ b/scripts/gdb/linux/symbols.py
> @@ -15,7 +15,7 @@ import gdb
>  import os
>  import re
>  
> -from linux import modules
> +from linux import modules, utils
>  
>  
>  if hasattr(gdb, 'Breakpoint'):
> @@ -113,6 +113,12 @@ lx-symbols command."""
>          if module_file:
>              gdb.write("loading @{addr}: {filename}\n".format(
>                  addr=module_addr, filename=module_file))
> +            if utils.is_target_arch('s390'):
> +                # Module text is preceded by PLT stubs on s390.
> +                module_arch = module['arch']
> +                plt_offset = int(module_arch['plt_offset'])
> +                plt_size = int(module_arch['plt_size'])
> +                module_addr = hex(int(module_addr, 0) + plt_offset + plt_size)

Shouldn't we report the actual address above, ie. reorder this tuning
with the gdb.write?

>              cmdline = "add-symbol-file {filename} {addr}{sections}".format(
>                  filename=module_file,
>                  addr=module_addr,
> 

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH] scripts/gdb: fix debugging modules on s390

[Ilya Leoshkevich]

> Am 15.10.2019 um 17:21 schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> 
>> @@ -113,6 +113,12 @@ lx-symbols command."""
>>         if module_file:
>>             gdb.write("loading @{addr}: {filename}\n".format(
>>                 addr=module_addr, filename=module_file))
>> +            if utils.is_target_arch('s390'):
>> +                # Module text is preceded by PLT stubs on s390.
>> +                module_arch = module['arch']
>> +                plt_offset = int(module_arch['plt_offset'])
>> +                plt_size = int(module_arch['plt_size'])
>> +                module_addr = hex(int(module_addr, 0) + plt_offset + plt_size)
> 
> Shouldn't we report the actual address above, ie. reorder this tuning
> with the gdb.write?

That's a tough question. I thought about this, and the argument for
showing the fixed up address is that if someone does the math with
symbol offsets from e.g. objdump, the result will be consistent with
what gdb shows.

On the other hand side, why would anyone do this? that's exactly what
this gdb script is for. So showing the actual address at which the
memory was allocated gives the user some additional information, and is
also consistent with what cat /proc/modules would show.

At the end of the day, I don't have a strong opinion on this, so if you
think it's better to show the fixed up address, I'll send a v2.

Best regards,
Ilya

Re: [PATCH] scripts/gdb: fix debugging modules on s390

[Jan Kiszka]

On 15.10.19 17:43, Ilya Leoshkevich wrote:
>> Am 15.10.2019 um 17:21 schrieb Jan Kiszka <jan.kiszka@siemens.com>:
>>
>>> @@ -113,6 +113,12 @@ lx-symbols command."""
>>>         if module_file:
>>>             gdb.write("loading @{addr}: {filename}\n".format(
>>>                 addr=module_addr, filename=module_file))
>>> +            if utils.is_target_arch('s390'):
>>> +                # Module text is preceded by PLT stubs on s390.
>>> +                module_arch = module['arch']
>>> +                plt_offset = int(module_arch['plt_offset'])
>>> +                plt_size = int(module_arch['plt_size'])
>>> +                module_addr = hex(int(module_addr, 0) + plt_offset + plt_size)
>>
>> Shouldn't we report the actual address above, ie. reorder this tuning
>> with the gdb.write?
> 
> That's a tough question. I thought about this, and the argument for
> showing the fixed up address is that if someone does the math with
> symbol offsets from e.g. objdump, the result will be consistent with
> what gdb shows.
> 
> On the other hand side, why would anyone do this? that's exactly what
> this gdb script is for. So showing the actual address at which the
> memory was allocated gives the user some additional information, and is
> also consistent with what cat /proc/modules would show.
> 
> At the end of the day, I don't have a strong opinion on this, so if you
> think it's better to show the fixed up address, I'll send a v2.

One of the original ideas of the printout was to provide the information
needed to reproduce potential issues manually. From that perspective,
the fixed-up address would the the thing to print.

If you think the vanilla address has some value as well, we could make
an s390-specifi printout of both values.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux