From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bin Meng <bmeng.cn@gmail.com>
Date: Wed, 29 Nov 2017 20:31:32 +0800
Subject: [U-Boot] [PATCH v2] x86: lib: Implement standalone __udivdi3
 etc instead of libgcc ones
In-Reply-To: <2e007af1-5096-42f8-554e-b2844446bb10@denx.de>
References: <20171117060228.23926-1-sr@denx.de>
 <CAEUhbmW4ew1sjj4Of3zDub83K8-W6dXLkFLtnTKEbyW448jTag@mail.gmail.com>
 <18015d46-d7e8-c598-830d-2da5c748e94c@denx.de>
 <CAEUhbmXkC=peTQemwhRwVuuK0Z8UbcfkxCLrXxab2YnyUCBi-g@mail.gmail.com>
 <c08beffd-de14-0e7d-4f8b-42ceb679ab6c@denx.de>
 <CAEUhbmXesZs4kjjbqaOhu3z09aSB+NehVefFQAJJOFEmweYp-Q@mail.gmail.com>
 <243f0af6-18d4-a3c7-b672-032cd837dfbc@denx.de>
 <CAEUhbmX00O6YbqRLJmJrmTxSkGx30dqPNG5CZXor4ZAK5CVcPA@mail.gmail.com>
 <2c863983-02e2-f3b9-c795-41b2ab61a3b8@denx.de>
 <CAEUhbmVXF=-AKhpPbhJAmMtaTDjyX9uJ+QzCdbz3N9qFOTz9rA@mail.gmail.com>
 <2e007af1-5096-42f8-554e-b2844446bb10@denx.de>
Message-ID: <CAEUhbmUxZUJ_XM0OJ6DftNJREwWQ=reu7uXgHffs8UFzHdpqZg@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Stefan,

On Wed, Nov 29, 2017 at 6:01 PM, Stefan Roese <sr@denx.de> wrote:
> Hi Bin,
>
>
> On 29.11.2017 10:23, Bin Meng wrote:
>>
>> On Wed, Nov 29, 2017 at 4:42 PM, Stefan Roese <sr@denx.de> wrote:
>>>
>>> Hi Bin,
>>>
>>> On 29.11.2017 09:30, Bin Meng wrote:
>>>
>>> <snip>
>>>
>>>>>> I wrote some codes soemthing like:
>>>>>>
>>>>>> s64 a, b, c;
>>>>>> c = a/b;
>>>>>>
>>>>>> The compiler will generate codes to call __divdi3. This works before
>>>>>> your
>>>>>> patch.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes, I understand this. But right now, we don't have any code
>>>>> generating this error. And if this will happen at some time, I would
>>>>> prefer to investigate this code sequence introducing this division, to
>>>>> use the division functions / macros available in U-Boot (as mentioned
>>>>> above) and in the kernel instead.
>>>>>
>>>>> Here a short explanation, why this new version is preferred to the
>>>>> currently available functions pulled from libgcc: We are fixing an
>>>>> "ugly" Yocto build problem with this patch, related to 32bit binaries
>>>>> with 64bit toolchains (multilib) building by not relying on anything
>>>>> from libgcc. Please see this thread for some more details:
>>>>>
>>>>> https://www.mail-archive.com/yocto at yoctoproject.org/msg36721.html
>>>>>
>>>>> I hope this helps a bit to understand the motivation behind this patch.
>>>>>
>>>>
>>>> Thanks for the background. I am not familiar with yocto project, but
>>>> is the build broken due to the gcc on the build host does not ship
>>>> with multilib?
>>>
>>>
>>>
>>> Please take a look at the email thread mentioned above for a detailed
>>> explanation. Especially this post should answer your questions:
>>>
>>> https://www.mail-archive.com/yocto at yoctoproject.org/msg36748.html
>>
>>
>> Now I see. Thank you.
>>
>>>
>>>> I am using a 64-bit host with gcc multilib, and there is no such build
>>>> error observed.
>>>
>>>
>>>
>>> Right. This issue is only seen on Yocto builds (AFAIK). But again,
>>> I would really like to see U-Boot x86 being self-contained without
>>> any host libgcc dependencies as on other architectures as well.
>>
>>
>> So to completely resolve such issue to make U-Boot self-contained, we
>> should remove the reference to the host libgcc.a in
>> arch/x86/lib/Makefile, and use CONFIG_USE_PRIVATE_GCC to include the
>> build for div64.o. Thoughts?
>
>
> I was under the impression, that I already removed the host libgcc
> reference completely for x86 with my patch. But you are correct - there
> still is a reference in this Makefile which is used by the standalone
> code, AFAICT.
>
> Any quick idea on how to rid of this one as well?
>

I believe we need change

obj-y  += div64.o

to

lib-$(CONFIG_USE_PRIVATE_LIBGCC) += div64.o

To remove the libgcc dependency completely.

Regards,
Bin