All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: openrisc@lists.librecores.org
Subject: [OpenRISC] [PATCH 0/4] OpenRISC binutils updates and new relocs
Date: Fri, 28 Sep 2018 16:39:03 +0100	[thread overview]
Message-ID: <271e3bfa-4958-0387-9a82-ecfdb58f1e26@redhat.com> (raw)
In-Reply-To: <20180927060756.GB3318@lianli.shorne-pla.net>

Hi Stafford,

> To produce these errors I need to change the code, Using abort we see:
> 
>    /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-elf/9.0.0/../../../../or1k-elf/bin/ld: \
>       BFD (GNU Binutils) 2.31.51.20180927 internal error, \
>       aborting at ../../binutils-gdb/bfd/elf32-or1k.c:1152 in or1k_final_link_relocate

> There is no segmentation fault.

Sorry, you are right - the abort does not trigger a segmentation fault.



> I agree, it is more nice to create a message
> inform which error triggered the issue.
> 
> Is something like this ok?
> 
>     default:
>       _bfd_error_handler
> 	(_("%pB: Unknown complain on overflow value on howto specified %d"),
> 	 input_bfd, (int) howto->complain_on_overflow);
>       abort();
> 
> i.e. _bfd_error_handler() followed by abort().  I couldn't really see a way to
> _bfd_error_handler() to actually cause the program to exit.

Depending upon where you are in your code, if you have access to the link_info
structure you can use its einfo() routine instead of bfd_error_handler.  This
has the advantage that it allows a %X formatting directive, which causes the 
program to terminate with an error exit code.

But otherwise, if there is no reasonable way to return to the caller, then
caryr on using abort.  Adding the error messages still helps though.

Cheers
  Nick



  reply	other threads:[~2018-09-28 15:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-21 14:38 [OpenRISC] [PATCH 0/4] OpenRISC binutils updates and new relocs Stafford Horne
2018-08-21 14:38 ` [OpenRISC] [PATCH 1/4] or1k: Add relocations for high-signed and low-stores Stafford Horne
2018-08-21 14:38 ` [OpenRISC] [PATCH 2/4] or1k: Fix messages for relocations in shared libraries Stafford Horne
2018-08-21 14:38 ` [OpenRISC] [PATCH 3/4] or1k: Add the l.adrp insn and supporting relocations Stafford Horne
2018-08-21 14:38 ` [OpenRISC] [PATCH 4/4] or1k: Add the l.muld, l.muldu, l.macu, l.msbu insns Stafford Horne
2018-09-08 21:35 ` [OpenRISC] [PATCH 0/4] OpenRISC binutils updates and new relocs Stafford Horne
2018-09-17 15:07   ` Nick Clifton
2018-09-17 16:29     ` Richard Henderson
2018-09-18  9:52     ` Stafford Horne
2018-09-18 11:55       ` Nick Clifton
2018-09-18 12:07         ` Joel Sherrill
2018-09-21 12:40           ` Stafford Horne
2018-09-19 13:23         ` Stafford Horne
2018-09-27  6:07         ` Stafford Horne
2018-09-28 15:39           ` Nick Clifton [this message]
2018-10-01  7:08             ` Stafford Horne

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=271e3bfa-4958-0387-9a82-ecfdb58f1e26@redhat.com \
    --to=nickc@redhat.com \
    --cc=openrisc@lists.librecores.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.