This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [2/16][binutils][AARCH64]Add relocation support for large memory model. [LD]Add BFD_RELOC_AARCH64_LD64_GOTOFF_LO15 Support.

Hi Marcus,

+                 /* 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, alternative.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]