From: Lulu Cai <cailulu@loongson.cn>
To: WANG Xuerui <i.swmail@xen0n.name>, binutils@sourceware.org
Cc: xuchenghua@loongson.cn, chenglulu@loongson.cn,
liuzhensong@loongson.cn, mengqinggang@loongson.cn,
xry111@xry111.site, maskray@google.com
Subject: Re: [PATCH] as: fixed internal error when immediate value of relocation overflow.
Date: Tue, 10 Oct 2023 17:55:53 +0800 [thread overview]
Message-ID: <f64c3efc-a530-c9e5-4ce3-5fbd30097b70@loongson.cn> (raw)
In-Reply-To: <284beedb-72a8-4333-b80e-55330dc0a25d@xen0n.name>
在 2023/10/10 上午8:25, WANG Xuerui 写道:
> Hi,
>
> On 10/9/23 10:11, Lulu Cai wrote:
>> The as reports an internal error when the relocation
>> overflow or is misaligned. Delete _bfd_error_handler
>> can avoid it and reports Reloc overflow.
>> ---
>> bfd/elfxx-loongarch.c | 8 +-------
>> gas/testsuite/gas/loongarch/imm_overflow.d | 3 +++
>> gas/testsuite/gas/loongarch/imm_overflow.l | 2 ++
>> gas/testsuite/gas/loongarch/imm_overflow.s | 4 ++++
>> gas/testsuite/gas/loongarch/imm_unalign.d | 3 +++
>> gas/testsuite/gas/loongarch/imm_unalign.l | 2 ++
>> gas/testsuite/gas/loongarch/imm_unalign.s | 6 ++++++
>> 7 files changed, 21 insertions(+), 7 deletions(-)
>> create mode 100644 gas/testsuite/gas/loongarch/imm_overflow.d
>> create mode 100644 gas/testsuite/gas/loongarch/imm_overflow.l
>> create mode 100644 gas/testsuite/gas/loongarch/imm_overflow.s
>> create mode 100644 gas/testsuite/gas/loongarch/imm_unalign.d
>> create mode 100644 gas/testsuite/gas/loongarch/imm_unalign.l
>> create mode 100644 gas/testsuite/gas/loongarch/imm_unalign.s
>>
>> diff --git a/bfd/elfxx-loongarch.c b/bfd/elfxx-loongarch.c
>> index 0a595eb87d5..c20efe82f31 100644
>> --- a/bfd/elfxx-loongarch.c
>> +++ b/bfd/elfxx-loongarch.c
>> @@ -1671,7 +1671,7 @@ reloc_bits (bfd *abfd ATTRIBUTE_UNUSED,
>> }
>> static bool
>> -reloc_sign_bits (bfd *abfd, reloc_howto_type *howto, bfd_vma *fix_val)
>> +reloc_sign_bits (bfd *abfd ATTRIBUTE_UNUSED, reloc_howto_type
>> *howto, bfd_vma *fix_val)
>> {
>> if (howto->complain_on_overflow != complain_overflow_signed)
>> return false;
>> @@ -1682,9 +1682,6 @@ reloc_sign_bits (bfd *abfd, reloc_howto_type
>> *howto, bfd_vma *fix_val)
>> if (howto->rightshift
>> && (val & ((((bfd_signed_vma) 1) << howto->rightshift) - 1)))
>> {
>> - (*_bfd_error_handler) (_("%pB: relocation %s right shift %d
>> error 0x%lx"),
>> - abfd, howto->name, howto->rightshift, (long) val);
>> - bfd_set_error (bfd_error_bad_value);
>> return false;
>> }
>> @@ -1696,9 +1693,6 @@ reloc_sign_bits (bfd *abfd, reloc_howto_type
>> *howto, bfd_vma *fix_val)
>> high part: from sign bit to highest bit. */
>> if ((val & ~mask) && ((val & ~mask) != ~mask))
>> {
>> - (*_bfd_error_handler) (_("%pB: relocation %s overflow 0x%lx"),
>> - abfd, howto->name, (long) val);
>> - bfd_set_error (bfd_error_bad_value);
>> return false;
>> }
>
> Isn't this only removing the error (downgrading it to a warning it
> seems) but not touching anything else? This will make the programmer
> errors slip through (apparently because no one reads warnings heh,
> it's especially worse for many devs not comfortable with English that
> I know of), and the problematic case you had in mind is still left
> unfixed.
>
> I think it's better to, at least, add the previously rejected code
> you're meaning to make acceptable, so the intent is clear; then we can
> figure out a better way forward than simply deleting checks.
Both the as and ld call the same function and use _bfd_error_handler to
output error messages when relocating overflow. However, as passed NULL
to the function when it was called, resulting in an internal error. ld
passes a non-null value when called and can output error messages
without internal errors.
So I consider not simply deleting this function. When as passes null,
the function is not called and reports a "Reloc overflow" error instead
of a warning. ld can call this function to output detailed information.
next prev parent reply other threads:[~2023-10-10 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 2:11 Lulu Cai
2023-10-10 0:25 ` WANG Xuerui
2023-10-10 9:55 ` Lulu Cai [this message]
2023-10-11 2:20 ` Lulu Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f64c3efc-a530-c9e5-4ce3-5fbd30097b70@loongson.cn \
--to=cailulu@loongson.cn \
--cc=binutils@sourceware.org \
--cc=chenglulu@loongson.cn \
--cc=i.swmail@xen0n.name \
--cc=liuzhensong@loongson.cn \
--cc=maskray@google.com \
--cc=mengqinggang@loongson.cn \
--cc=xry111@xry111.site \
--cc=xuchenghua@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).