linux-kernel - Re: [PATCH 1/2] kbuild: consolidate redundant sed script ASM offset generation

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]

Date:   Tue, 18 Apr 2017 19:20:09 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     David Howells <dhowells@...hat.com>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Michael Davidson <md@...gle.com>,
        Michal Marek <mmarek@...e.com>,
        Jan Beulich <JBeulich@...ell.com>,
        Alexander van Heukelum <heukelum@...tmail.fm>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] kbuild: consolidate redundant sed script ASM offset generation

Hi David,


2017-04-18 18:57 GMT+09:00 David Howells <dhowells@...hat.com>:
> Masahiro Yamada <yamada.masahiro@...ionext.com> wrote:
>
>> This part ended up in redundant code after touched by multiple
>> people.
>>
>> [1] Commit 3234282f33b2 ("x86, asm: Fix CFI macro invocations to
>> deal with shortcomings in gas") added parentheses for defined
>> expressions to support old gas for x86.
>>
>> [2] Commit a22dcdb0032c ("x86, asm: Fix ancient-GAS workaround")
>> split the pattern into two to avoid parentheses for non-numeric
>> expressions.
>>
>> [3] Commit 95a2f6f72d37 ("Partially revert patch that encloses
>> asm-offset.h numbers in brackets") removed parentheses from numeric
>> expressions as well because parentheses in MN10300 assembly have a
>> special meaning (pointer access).
>>
>> Apparently, there is a conflict between [1] and [3].  After all,
>> [3] took precedence, and a long time has passed since then.
>
> There's a conflict between [1] and various assembly code formats.  Some
> formats define, say,
>
>         mov     4,r1
>
> to move the number 4 into register r1, and:
>
>         mov     (4),r1
>
> to move the contents of the memory at address 4 into r1.  Therefore, you
> cannot simply wrap numeric operands in brackets.  What might work is adding a
> '+' on the front, e.g.:
>
>         mov     +(4),r1
>
> David


OK, thanks for this info.

But, nobody has raised a flag about the reverted [1].
(perhaps, nobody cares about the old gas any more?)
So, I think this patch will be OK.


BTW, do you still maintain mn10300?

(Before, I worked for Panasonic, i.e. former Matsushita)



-- 
Best Regards
Masahiro Yamada