* Building cross-toolchain for microblaze
@ 2016-11-04 2:48 Joseph Myers
2016-11-04 12:12 ` Adhemerval Zanella
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2016-11-04 2:48 UTC (permalink / raw)
To: libc-alpha, david
Continuing the issues shown up by writing a script to build glibc for all
ABIs, I find that MicroBlaze glibc does not build using the final compiler
because MicroBlaze GCC always uses SJLJ exceptions (see
gcc/common/config/microblaze/microblaze-common.c defining
TARGET_EXCEPT_UNWIND_INFO to sjlj_except_unwind_info), which is not
supported in glibc, resulting in undefined references to _Unwind_SjLj_*
(glibc deliberately links with libgcc.a and *not* libgcc_eh.a and gets EH
functionality via loading libgcc_s as needed, which is not implemented for
the SJLJ case; in the static-only case there isn't a separate libgcc_eh so
a build with the initial static-only compiler works accidentally).
How is building MicroBlaze glibc meant to work? Is there some GCC patch
missing upstream to use DWARF2 exceptions?
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building cross-toolchain for microblaze
2016-11-04 2:48 Building cross-toolchain for microblaze Joseph Myers
@ 2016-11-04 12:12 ` Adhemerval Zanella
2016-11-04 13:08 ` Joseph Myers
0 siblings, 1 reply; 6+ messages in thread
From: Adhemerval Zanella @ 2016-11-04 12:12 UTC (permalink / raw)
To: libc-alpha
On 04/11/2016 00:48, Joseph Myers wrote:
> Continuing the issues shown up by writing a script to build glibc for all
> ABIs, I find that MicroBlaze glibc does not build using the final compiler
> because MicroBlaze GCC always uses SJLJ exceptions (see
> gcc/common/config/microblaze/microblaze-common.c defining
> TARGET_EXCEPT_UNWIND_INFO to sjlj_except_unwind_info), which is not
> supported in glibc, resulting in undefined references to _Unwind_SjLj_*
> (glibc deliberately links with libgcc.a and *not* libgcc_eh.a and gets EH
> functionality via loading libgcc_s as needed, which is not implemented for
> the SJLJ case; in the static-only case there isn't a separate libgcc_eh so
> a build with the initial static-only compiler works accidentally).
>
> How is building MicroBlaze glibc meant to work? Is there some GCC patch
> missing upstream to use DWARF2 exceptions?
>
I could build a workable toolchain, at least for glibc building, by
configuring GCC with both '--disable-sjlj-exceptions' and
'--disable-shared'. I did not dig into the issue, but it was already
reported on maillist this same issue.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building cross-toolchain for microblaze
2016-11-04 12:12 ` Adhemerval Zanella
@ 2016-11-04 13:08 ` Joseph Myers
2016-11-04 13:44 ` Adhemerval Zanella
2016-11-06 2:05 ` Waldemar Brodkorb
0 siblings, 2 replies; 6+ messages in thread
From: Joseph Myers @ 2016-11-04 13:08 UTC (permalink / raw)
To: Adhemerval Zanella; +Cc: libc-alpha
On Fri, 4 Nov 2016, Adhemerval Zanella wrote:
> I could build a workable toolchain, at least for glibc building, by
> configuring GCC with both '--disable-sjlj-exceptions' and
> '--disable-shared'. I did not dig into the issue, but it was already
> reported on maillist this same issue.
The *first* GCC works to build glibc. The problem is with the second one,
with shared libraries and C++ support (and separate libgcc_eh, which is
what actually results in the undefined references), since you want to
rebuild with such a second compiler before running the testsuite (the
expectation is that a bootstrap compiler will produce a correct glibc, but
not a build tree suitable for testing in).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building cross-toolchain for microblaze
2016-11-04 13:08 ` Joseph Myers
@ 2016-11-04 13:44 ` Adhemerval Zanella
2016-11-06 2:05 ` Waldemar Brodkorb
1 sibling, 0 replies; 6+ messages in thread
From: Adhemerval Zanella @ 2016-11-04 13:44 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
On 04/11/2016 11:08, Joseph Myers wrote:
> On Fri, 4 Nov 2016, Adhemerval Zanella wrote:
>
>> I could build a workable toolchain, at least for glibc building, by
>> configuring GCC with both '--disable-sjlj-exceptions' and
>> '--disable-shared'. I did not dig into the issue, but it was already
>> reported on maillist this same issue.
>
> The *first* GCC works to build glibc. The problem is with the second one,
> with shared libraries and C++ support (and separate libgcc_eh, which is
> what actually results in the undefined references), since you want to
> rebuild with such a second compiler before running the testsuite (the
> expectation is that a bootstrap compiler will produce a correct glibc, but
> not a build tree suitable for testing in).
Indeed and I could not get so far as well on this specific target.
For microblaze I basically do sanity glibc build checkswith first GCC.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building cross-toolchain for microblaze
2016-11-04 13:08 ` Joseph Myers
2016-11-04 13:44 ` Adhemerval Zanella
@ 2016-11-06 2:05 ` Waldemar Brodkorb
2016-11-07 15:46 ` Joseph Myers
1 sibling, 1 reply; 6+ messages in thread
From: Waldemar Brodkorb @ 2016-11-06 2:05 UTC (permalink / raw)
To: Joseph Myers; +Cc: Adhemerval Zanella, libc-alpha
Hi,
Joseph Myers wrote,
> On Fri, 4 Nov 2016, Adhemerval Zanella wrote:
>
> > I could build a workable toolchain, at least for glibc building, by
> > configuring GCC with both '--disable-sjlj-exceptions' and
> > '--disable-shared'. I did not dig into the issue, but it was already
> > reported on maillist this same issue.
>
> The *first* GCC works to build glibc. The problem is with the second one,
> with shared libraries and C++ support (and separate libgcc_eh, which is
> what actually results in the undefined references), since you want to
> rebuild with such a second compiler before running the testsuite (the
> expectation is that a bootstrap compiler will produce a correct glibc, but
> not a build tree suitable for testing in).
Some projects as Buldroot using some gcc patches which are not in
upstream gcc to provide Dwarf:
https://git.busybox.net/buildroot/tree/package/gcc/5.4.0/840-microblaze-enable-dwarf-eh-support.patch
This allows to build a microblaze toolchain.
best regards
Waldemar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Building cross-toolchain for microblaze
2016-11-06 2:05 ` Waldemar Brodkorb
@ 2016-11-07 15:46 ` Joseph Myers
0 siblings, 0 replies; 6+ messages in thread
From: Joseph Myers @ 2016-11-07 15:46 UTC (permalink / raw)
To: Waldemar Brodkorb; +Cc: Adhemerval Zanella, libc-alpha, david, eager
On Sun, 6 Nov 2016, Waldemar Brodkorb wrote:
> Hi,
> Joseph Myers wrote,
>
> > On Fri, 4 Nov 2016, Adhemerval Zanella wrote:
> >
> > > I could build a workable toolchain, at least for glibc building, by
> > > configuring GCC with both '--disable-sjlj-exceptions' and
> > > '--disable-shared'. I did not dig into the issue, but it was already
> > > reported on maillist this same issue.
> >
> > The *first* GCC works to build glibc. The problem is with the second one,
> > with shared libraries and C++ support (and separate libgcc_eh, which is
> > what actually results in the undefined references), since you want to
> > rebuild with such a second compiler before running the testsuite (the
> > expectation is that a bootstrap compiler will produce a correct glibc, but
> > not a build tree suitable for testing in).
>
> Some projects as Buldroot using some gcc patches which are not in
> upstream gcc to provide Dwarf:
>
> https://git.busybox.net/buildroot/tree/package/gcc/5.4.0/840-microblaze-enable-dwarf-eh-support.patch
>
> This allows to build a microblaze toolchain.
David, can you get this patch (or equivalent) upstream so that we can have
a clean baseline for all-ABI glibc builds and compile-only tests given
recent-enough GCC? When people / bots are running builds of over 60
different glibc variants to watch for regressions, requiring
architecture-specific non-upstream patches complicates things
unnecessarily.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-11-07 15:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-04 2:48 Building cross-toolchain for microblaze Joseph Myers
2016-11-04 12:12 ` Adhemerval Zanella
2016-11-04 13:08 ` Joseph Myers
2016-11-04 13:44 ` Adhemerval Zanella
2016-11-06 2:05 ` Waldemar Brodkorb
2016-11-07 15:46 ` Joseph Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).