public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Andreas Bießmann" <andreas.devel@googlemail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 1/2] arm920t/at91/reset.c: fix weak reset_board()
Date: Thu, 04 Nov 2010 11:54:32 +0100	[thread overview]
Message-ID: <4CD290E8.4010303@gmail.com> (raw)
In-Reply-To: <AANLkTinOcrTts+7O=SQrH8aEVNWa8QipL9x2zuPhtvec@mail.gmail.com>

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

  reply	other threads:[~2010-11-04 10:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-31  7:11 [U-Boot] ARM: problems with elf relocation on arm920t / maybe toolchain related Andreas Bießmann
2010-10-31  7:25 ` [U-Boot] [PATCH RFC] arm920t: implement elf relocation Andreas Bießmann
2010-10-31  7:28   ` Albert ARIBAUD
2010-10-31  7:39     ` Andreas Bießmann
2010-10-31  7:49       ` Albert ARIBAUD
2010-11-03 23:21 ` [U-Boot] [PATCH v2 1/2] arm920t/at91/reset.c: fix weak reset_board() Andreas Bießmann
2010-11-04  1:00   ` Joakim Tjernlund
2010-11-04  1:13     ` Graeme Russ
2010-11-04  1:23       ` Joakim Tjernlund
2010-11-04  3:27         ` Sebastien Carlier
2010-11-04 10:54           ` Andreas Bießmann [this message]
2010-11-04 11:12             ` Sebastien Carlier
2010-11-04 10:41         ` Andreas Bießmann
2010-11-03 23:21 ` [U-Boot] [PATCH v2 2/2] arm920t: implement elf relocation Andreas Bießmann
2010-11-03 23:29   ` [U-Boot] [PATCH v3] " Andreas Bießmann
2010-11-04  6:14     ` Albert ARIBAUD
2010-11-04 10:15       ` Andreas Bießmann
2010-11-04 12:37         ` Albert ARIBAUD
     [not found]   ` <sebastien.carlier@2d91f447722561d137e769820c0e333bcce282ff>
2010-11-20 11:48     ` [U-Boot] [PATCH v2 2/2] " Andreas Bießmann

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=4CD290E8.4010303@gmail.com \
    --to=andreas.devel@googlemail.com \
    --cc=u-boot@lists.denx.de \
    /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