This is the mail archive of the
mailing list for the binutils project.
Re: [2/16][binutils][AARCH64]Add relocation support for large memory model. [LD]Add BFD_RELOC_AARCH64_LD64_GOTOFF_LO15 Support.
- From: Nick Clifton <nickc at redhat dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: Renlin Li <renlin dot li at arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Jiong Wang <jiong dot wang at arm dot com>
- Date: Wed, 9 Sep 2015 08:51:15 +0100
- Subject: Re: [2/16][binutils][AARCH64]Add relocation support for large memory model. [LD]Add BFD_RELOC_AARCH64_LD64_GOTOFF_LO15 Support.
- Authentication-results: sourceware.org; auth=none
- References: <55EF0938 dot 9060404 at arm dot com> <55EF0D86 dot 6030904 at redhat dot com> <CAFqB+Pwb0SQ4b=jJpdBX_YECkPVdQ25jGc_TXDecAa6B6cbmQg at mail dot gmail dot com>
+ /* For local symbol, we have done absolute relocation in
+ linking stage. While for share library, we need to
+ the content of GOT entry according to the share objects
+ loading base address. So we need to generate a
+ R_AARCH64_RELATIVE reloc for dynamic linker. */
+ s = globals->root.srelgot;
+ if (s == NULL)
+ abort ();
This is checking internal consistency, the existing practice both here
and in _bfd_final_link_relocate which it wraps is to handle internal
inconsistency with an abort(), so this part of the proposed patch
seems to me to be consistent with existing practice.
The reason for avoiding calls to abort() inside library functions is
that the library does not know what the user is trying to do. For
example they may be trying out various different ways of linking
together some object files to find one that works. A failure to link in
this case is not a problem for the user - they just go on to try the
next alternative - but if the library function aborts then they are stuck.
The other problem with calling abort() is that it does not require an
explanatory message. Sometime the programmer will have put a helpful
comment in the code, but not always. Plus when the user encounters the
abort they are given no clue as to what is wrong. They just have to
report the bug to us and hope that we will fix it.
Still, having said all of that, I do agree that with internal errors,
sometimes an abort is that best choice. I would just like to encourage
contributors to avoid using abort unless there really is no, sensible,