public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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.


  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).