Re: FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180)

2018-10-15 Thread Mark Millard via freebsd-toolchain 
[I've found the problem at the low level for
my context of using WITH_LIBCPLUSPLUS= with
the likes of devel/powerpc64-gcc but I do
not have a solution for WITH_LIBCPLUSPLUS=
so far. I give details of what I found.]

On 2018-Oct-14, at 12:40 AM, Mark Millard  wrote:

> On 2018-Oct-12, at 1:59 PM, Mark Millard  wrote:
> 
>> I built a powerpc64 head -r339076 via devel/powerpc64-gcc
>> and the like that built clang as cc as well (and
>> WITHOUT_LIB32). This included use of base/binutils to
>> the the powerpc64 set up. The system and kernel are
>> non-debug builds (but with symbols). [system-clang is not
>> used for buildworld buildkernel because of known
>> issues (last I tried).]
>> 
>> booting, buildworld, buildkernel, poudriere building
>> what totaled to be somewhat under 400 ports all seem
>> to work. But . . .
>> 
>> It been a long time since I've done something analogous
>> and a significant item in the result is different than in
>> the past once I started testing the throwing of C++
>> exceptions in code produced by system-clang or by
>> devel/powerpc64-gcc :
>> 
>> Such code ends up stuck using around 100% of a CPU.
>> An example is the program:
>> 
>> # more exception_test.cpp
>> #include 
>> 
>> int main(void)
>> {
>>   try { throw std::exception(); }
>>   catch (std::exception& e) {}
>>   return 0;
>> }
>> 
>> For system-clang it ended up with:
>> 
>> # ldd a.out
>> a.out:
>>  libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
>>  libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
>>  libm.so.5 => /lib/libm.so.5 (0x8101ab000)
>>  libc.so.7 => /lib/libc.so.7 (0x8101eb000)
>>  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810554000)
>> 
>> That program goes into an possibly unbounded execution.
>> (Historically when this program had problems it would
>> stop and produce a core file.)
>> 
>> When compiled by devel/powerpc64-gcc the a.out that results
>> does the same thing. ( /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ 
>> as the compiler path ) So this is not really clang specific
>> in any way. This ended up with:
>> 
>> # ldd a.out
>> a.out:
>>  libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
>>  libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
>>  libm.so.5 => /lib/libm.so.5 (0x8101ab000)
>>  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8101eb000)
>>  libc.so.7 => /lib/libc.so.7 (0x810211000)
>> 
>> (That should not have involved clang or llvm at all.)
>> 
>> But compiled by lang/gcc8's g++8 the a.out that results works
>> fine. This ends up with:
>> 
>> # ldd a.out
>> a.out:
>>  libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81006e000)
>>  libm.so.5 => /lib/libm.so.5 (0x8102c7000)
>>  libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810307000)
>>  libc.so.7 => /lib/libc.so.7 (0x81032d000)
>> 
>> It is not clear if using base/gcc as system cc
>> would do any better than using system-clang does
>> or than devel/powerpc64-gcc does: it is sort of
>> a variant of devel/powerpc64-gcc .
>> 
>> It will probably be some time before I figure out
>> much about what is going on.
>> 
>> Two things common to the problem cases are:
>> 
>> libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
>> libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
>> 
>> lang/gcc8 avoids those being involved.
>> 
>> 
>> Notes:
>> 
>> . . .
>> 
>> WITHOUT_LIB32= is because, for every post-gcc 4.2.1
>> that I've tried, the lib32 produced misuses R30 in
>> crtbeginS code (vs. the ABI for FreeBSD) and 32-bit
>> code just produces core files from the bad so-called
>> address dereference that results.
>> 
>> I'd rather have throwing C++ exceptions working and
>> lack of lib32 than have lib32 but not have throwing
>> C++ exceptions working. But at the moment how to have
>> such is not obvious when fairly modern compilers
>> and toolchains are involved. 
> 
> Here is what I've found so far.
> 
> The code is looping in the following routine.
> (I've inserted 2 NOTE: lines for what the
> sustained looping is like.)
> 
. . . (the routine was _Unwind_RaiseException) . . .


So far I've found that the following in
_Unwind_RaiseException stays invariant once
initialized --despite the uw_frame_state_for
and uw_update_context calls in
_Unwind_RaiseException 's loop that normally
update fs:


(gdb) print fs
$15 = {regs = {reg = {{loc = {reg = 0, offset = 0, exp = 0x0}, how = 
REG_UNSAVED} , {loc = {reg = 18446744073709551608, offset = 
-8, 
  exp = 0xfff8 }, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp = 
0x0}, how = REG_UNSAVED} , {
loc = {reg = 16, offset = 16, exp = 0x10 }, how = REG_SAVED_OFFSET}, {loc = {reg = 0, offset = 0, exp = 
0x0}, how = REG_UNSAVED} }, 
prev = 0x0}, cfa_offset = 0, cfa_reg = 1, cfa_exp = 0x0, cfa_how = 
CFA_REG_OFFSET, pc = 0x8101999f8, personality = 0, data_align = -8, code_align 
= 4, retaddr_column = 65, 
  fde_encoding = 27 '\033', lsda_encoding = 255 '?', saw_z = 1 '\001', 
signal_frame = 0 '\0', eh_ptr = 0x0}

It turns out

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

2018-10-15 Thread John Baldwin 
On 10/15/18 11:55 AM, Warner Losh wrote:
> 
> 
> On Mon, Oct 15, 2018 at 12:25 PM John Baldwin  > wrote:
> 
> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Baldwin    >> wrote:
> >
> >     On 10/12/18 6:51 AM, Mark Millard wrote:
> >     > The following is from attempting to build devel/powerpc-gcc
> >     > via poudriere-devel on the powerpc64 system after having
> >     > bootstrapped via (in part) base/binutils and the .txz
> >     > produced on the host (amd64).
> >     >
> >     > Looks like having both:
> >     >
> >     > /usr/bin/powerpc64-unknown-freebsd12.0-*
> >     > and:
> >     > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >     >
> >     > in a powerpc64 environment confuses "phase: build-depends"
> >     > in poudriere for the devel/powerpc64-gcc build:
> >
> >     Ah, I could see that.  I had kept the longer binary names with the 
> full tuple
> >     since the original base/binutils had them, but I've considered 
> stripping them
> >     as we only really need /usr/bin/as, etc. for the base system.  I 
> hadn't gotten
> >     to the point of trying to build any ports with base/* as I'm still 
> trying to
> >     just do a buildworld (and running poudriere in a qemu image of 
> mips64 would
> >     be very unpleasant).  I think probably base/binutils just needs to 
> drop the
> >     names with a full tuple if possible.
> >
> >
> > Having symlinks to the long names plays nicer with autoconf, of at 
> least has in the past. Our build system doesn't care, though...
> 
> I think it only plays nicer for the port.  We've never had 
> /usr/bin/x86_64-freebsd-ld
> linked to /usr/bin/ld in base, and base/binutils' role is to provide 
> /usr/bin/as,
> /usr/bin/ld, etc.
> 
> 
> The tools built by xdev did, though not that specific link... I do agree that 
> if we do this, it's only of marginal benefit.

The xdev tools are probably more inline with the devel/-binutils and
devel/-gcc ports which do install those links to be cross-build friendly.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

2018-10-15 Thread Warner Losh 
On Mon, Oct 15, 2018 at 12:25 PM John Baldwin  wrote:

> On 10/15/18 11:06 AM, Warner Losh wrote:
> >
> >
> > On Mon, Oct 15, 2018, 10:20 AM John Baldwin  j...@freebsd.org>> wrote:
> >
> > On 10/12/18 6:51 AM, Mark Millard wrote:
> > > The following is from attempting to build devel/powerpc-gcc
> > > via poudriere-devel on the powerpc64 system after having
> > > bootstrapped via (in part) base/binutils and the .txz
> > > produced on the host (amd64).
> > >
> > > Looks like having both:
> > >
> > > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > > and:
> > > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> > >
> > > in a powerpc64 environment confuses "phase: build-depends"
> > > in poudriere for the devel/powerpc64-gcc build:
> >
> > Ah, I could see that.  I had kept the longer binary names with the
> full tuple
> > since the original base/binutils had them, but I've considered
> stripping them
> > as we only really need /usr/bin/as, etc. for the base system.  I
> hadn't gotten
> > to the point of trying to build any ports with base/* as I'm still
> trying to
> > just do a buildworld (and running poudriere in a qemu image of
> mips64 would
> > be very unpleasant).  I think probably base/binutils just needs to
> drop the
> > names with a full tuple if possible.
> >
> >
> > Having symlinks to the long names plays nicer with autoconf, of at least
> has in the past. Our build system doesn't care, though...
>
> I think it only plays nicer for the port.  We've never had
> /usr/bin/x86_64-freebsd-ld
> linked to /usr/bin/ld in base, and base/binutils' role is to provide
> /usr/bin/as,
> /usr/bin/ld, etc.
>

The tools built by xdev did, though not that specific link... I do agree
that if we do this, it's only of marginal benefit.

Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

2018-10-15 Thread John Baldwin 
On 10/15/18 11:06 AM, Warner Losh wrote:
> 
> 
> On Mon, Oct 15, 2018, 10:20 AM John Baldwin  > wrote:
> 
> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via poudriere-devel on the powerpc64 system after having
> > bootstrapped via (in part) base/binutils and the .txz
> > produced on the host (amd64).
> >
> > Looks like having both:
> >
> > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > and:
> > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >
> > in a powerpc64 environment confuses "phase: build-depends"
> > in poudriere for the devel/powerpc64-gcc build:
> 
> Ah, I could see that.  I had kept the longer binary names with the full 
> tuple
> since the original base/binutils had them, but I've considered stripping 
> them
> as we only really need /usr/bin/as, etc. for the base system.  I hadn't 
> gotten
> to the point of trying to build any ports with base/* as I'm still trying 
> to
> just do a buildworld (and running poudriere in a qemu image of mips64 
> would
> be very unpleasant).  I think probably base/binutils just needs to drop 
> the
> names with a full tuple if possible.
> 
> 
> Having symlinks to the long names plays nicer with autoconf, of at least has 
> in the past. Our build system doesn't care, though...

I think it only plays nicer for the port.  We've never had 
/usr/bin/x86_64-freebsd-ld
linked to /usr/bin/ld in base, and base/binutils' role is to provide 
/usr/bin/as,
/usr/bin/ld, etc.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

2018-10-15 Thread Warner Losh 
On Mon, Oct 15, 2018, 10:20 AM John Baldwin  wrote:

> On 10/12/18 6:51 AM, Mark Millard wrote:
> > The following is from attempting to build devel/powerpc-gcc
> > via poudriere-devel on the powerpc64 system after having
> > bootstrapped via (in part) base/binutils and the .txz
> > produced on the host (amd64).
> >
> > Looks like having both:
> >
> > /usr/bin/powerpc64-unknown-freebsd12.0-*
> > and:
> > /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> >
> > in a powerpc64 environment confuses "phase: build-depends"
> > in poudriere for the devel/powerpc64-gcc build:
>
> Ah, I could see that.  I had kept the longer binary names with the full
> tuple
> since the original base/binutils had them, but I've considered stripping
> them
> as we only really need /usr/bin/as, etc. for the base system.  I hadn't
> gotten
> to the point of trying to build any ports with base/* as I'm still trying
> to
> just do a buildworld (and running poudriere in a qemu image of mips64 would
> be very unpleasant).  I think probably base/binutils just needs to drop the
> names with a full tuple if possible.
>

Having symlinks to the long names plays nicer with autoconf, of at least
has in the past. Our build system doesn't care, though...

Warner

-- 
> John Baldwin
>
>
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "
> freebsd-toolchain-unsubscr...@freebsd.org"
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build

2018-10-15 Thread John Baldwin 
On 10/12/18 6:51 AM, Mark Millard wrote:
> The following is from attempting to build devel/powerpc-gcc
> via poudriere-devel on the powerpc64 system after having
> bootstrapped via (in part) base/binutils and the .txz
> produced on the host (amd64).
> 
> Looks like having both:
> 
> /usr/bin/powerpc64-unknown-freebsd12.0-*
> and:
> /usr/local/bin/powerpc64-unknown-freebsd12.0-*
> 
> in a powerpc64 environment confuses "phase: build-depends"
> in poudriere for the devel/powerpc64-gcc build:

Ah, I could see that.  I had kept the longer binary names with the full tuple
since the original base/binutils had them, but I've considered stripping them
as we only really need /usr/bin/as, etc. for the base system.  I hadn't gotten
to the point of trying to build any ports with base/* as I'm still trying to
just do a buildworld (and running poudriere in a qemu image of mips64 would
be very unpleasant).  I think probably base/binutils just needs to drop the
names with a full tuple if possible.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: "base/binutils should not be pulling in any other ports at all"? (That confuses me.)

2018-10-15 Thread John Baldwin 
On 10/12/18 5:48 PM, Mark Millard wrote:
> On 2018-Oct-10, at 3:13 PM, John Baldwin  wrote:
> 
>> On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote:
>>> [Actually devel/gettext-tools is a build time dependency: it should not be 
>>> using
>>> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=. 
>>> . .
>>> It looks like the /usr/local/lib references are correct but the wrong 
>>> linker was
>>> being used. About 5 other ports have a similar status for making 
>>> base/binutils
>>> as a cross build.]
>>
>> base/binutils should not be pulling in any other ports at all.
> 
> That last quote confuses me still. May be it means
> it is all to be manually managed instead of automatic?

No, it means it doesn't work as you ran into. :)

> (The actual build using things link devel/bison on
> the host if base/binutils is to build at all.)
> 
> All versions of binutils have direct build dependencies on:
> 
> math/gmp
> math/mpfr
> devel/bison
> devel/gmake
> 
> as far as I know. Some of those in turn have more
> build dependencies. Some of all that have Runtime
> dependencies and/or library dependencies as well.
> (Host context of usage.)

For the purposes of the instructions we only need to provide the top-level
"leaf" packages as a list of things to install before trying to build.

-- 
John Baldwin


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"