lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <EC1E8F36-C374-4130-9841-CC35F557B7CE@linux.ibm.com>
Date:   Tue, 15 Oct 2019 17:43:18 +0200
From:   Ilya Leoshkevich <iii@...ux.ibm.com>
To:     Jan Kiszka <jan.kiszka@...mens.com>
Cc:     Kieran Bingham <kbingham@...nel.org>, linux-kernel@...r.kernel.org,
        linux-s390@...r.kernel.org,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH] scripts/gdb: fix debugging modules on s390

> Am 15.10.2019 um 17:21 schrieb Jan Kiszka <jan.kiszka@...mens.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ