All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] libaio: Fix library creation for ARC with -Os
Date: Tue, 18 Sep 2018 09:36:04 +0200	[thread overview]
Message-ID: <20180918093604.0b421d5c@windsurf> (raw)
In-Reply-To: <20180917204329.15787-1-abrodkin@synopsys.com>

Hello,

Thanks Alexey for working on this. I have a few questions below, to
better understand the problem and its solution.

On Mon, 17 Sep 2018 23:43:29 +0300, Alexey Brodkin wrote:
> On ARC if "-Os" optimization is used compiler prefers to use so-called
> millicode (basically function prologue & epilogue) implemented once and for
> all in libgcc.a.

Until this point, I follow.

> And if we don't link with libgcc.a on DSO (read libaio.so)

I don't understand "link with libgcc.A on DSO" and therefore the rest
of the explanation is a bit unclear to me.

> creation those millicode functions won't be included, instead their
> symbols will be referenced as they were in libgcc (HIDDEN).
> 
> And then when LD is about to link a final application it sees HIDDEN
> symbol in libaio.so that is supposed to come from some static
> libgcc.a... wait.. what? Shared library has unresolved symbol
> implemented in static library? No, that's not right I guess :)
> 
> So to resolve that wrong sequence we just make sure libaio.so has
> its own copy of used millicode functions implemented locally.

Why is this problem happening only with libaio, and not with other
packages ? Is this the final fix, or is this a temporary workaround ?

> BTW I guess something similar might happen for PowerPC,
> see https://git.buildroot.org/buildroot/commit/?id=ce6536ae500fc4ac0c201d5cb4edf39dd1b4d386
> --------------------------->8------------------------  
> hidden symbol `_rest32gpr_30_x' in libgcc.a(e500crtresx32gpr.o) is referenced by DSO
> --------------------------->8------------------------  

Ah, interesting. So there is really something special about libaio.so
forgetting to link with libgcc ? Should this also be changed to cover
PowerPC to remove the workaround ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-09-18  7:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-17 20:43 [Buildroot] [PATCH] libaio: Fix library creation for ARC with -Os Alexey Brodkin
2018-09-18  7:36 ` Thomas Petazzoni [this message]
2018-09-18  8:03   ` Alexey Brodkin
2018-09-18  9:15     ` Thomas Petazzoni
2018-09-18  9:17       ` Alexey Brodkin
2018-09-18  9:26         ` Thomas Petazzoni
2018-09-18  9:30           ` Alexey Brodkin
     [not found]             ` <098ECE41A0A6114BB2A07F1EC238DE89667FD144@de02wembxa.internal.synopsys.com>
2018-09-18 12:44               ` Alexey Brodkin
2018-09-18 13:58                 ` Thomas Petazzoni
2018-09-28 13:36                   ` Alexey Brodkin
2018-09-18  9:20       ` Thomas Petazzoni

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=20180918093604.0b421d5c@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /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.