From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Thu, 04 Nov 2010 11:54:32 +0100 Subject: [U-Boot] [PATCH v2 1/2] arm920t/at91/reset.c: fix weak reset_board() In-Reply-To: References: <1288826483-58527-1-git-send-email-andreas.devel@googlemail.com> Message-ID: <4CD290E8.4010303@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Sebastien Carlier, Am 04.11.2010 04:27, schrieb Sebastien Carlier: > These weakly defined empty functions prevent the strong definition > from being linked in. > > For example, libarm.a contains a weak symbol 'red_LED_on', which is > expected to be defined (strongly) in the board library. Because > archive libraries are being used, this fails (testing with binutils > 2.20.1), and only the empty __red_LED_on stub is linked in; the > red_LED_on definition in the board library is throw away. I have detected this issue yesterday evening too. > This behavior is documented and it is the intended one; from > http://www.sco.com/developers/gabi/latest/ch4.symtab.html: > >> When the link editor searches archive libraries [see ``Archive >> File'' in Chapter 7], it extracts archive members that contain >> definitions of undefined global symbols. >> The member's definition may be either a global or a weak symbol. >> The link editor does not extract archive members to resolve >> undefined weak symbols. Unresolved weak symbols have a zero value. > > Empty weak definitions would have to be supplied to the linker only > _after_ the strong definitions have been provided. So it would be a work around to change Makefile from: ---8<--- __LIBS := $(subst $(obj),,$(LIBS)) $(subst $(obj),,$(LIBBOARD)) --->8--- to: --->8--- __LIBS := $(subst $(obj),,$(LIBBOARD)) $(subst $(obj),,$(LIBS)) ---8<--- This could work cause in most cases the strong definitions are in $(LIBBOARD) and overload the weak functions in $(LIBS). But this is just a work around and will not fit any use-case of weak functions. The root cause seems to be a linker problem. But I dunno whether it is a mis-usage or a bug. Any gcc-guys here to comment? > Leaving undefined weak symbols and testing for NULL-ity at call sites > seems to be a more robust approach. > > Note that with some ld versions (at least with 2.20.1), ld creates PLT > entries for undefined weak symbols and crashes when the PLT-related > sections (.plt, .got.plt, and .rel.plt) are discarded... This seems to be the main issue here ... but how to get it solved? regards Andreas Bie?mann