[Bugzilla 225197 indirectly lead to this.
Avoiding continuing there.]
I decided to compare some alternate uses of
__attribute__((alloc_size(. . .))) compiled
and run under clang 5.0.1 and gcc7. I did not
get what I expected based on prior discussion
material.
This is an FYI since I do not know ho
[Noting a typo in the program source, and
so in the output text: the 2nd occurance of: "my_calloc_alt0
should have been: "my_calloc_alt1
. Hand edited corrections below for clarity.]
On 2018-Jan-20, at 3:27 PM, Mark Millard wrote:
> [Bugzilla 225197 indirectly lead to this.
> Avoiding continuing
[May be an __alloc_size2(n,s) should be added and used?]
On 2018-Jan-20, at 5:05 PM, Pedro Giffuni wrote:
> Very interesting , thanks for running such tests ...
>
>
> On 01/20/18 18:59, Mark Millard wrote:
>> [Noting a typo in the program source, and
>> so in the output text: the 2nd occurance
I had a panic and got a dump for amd64 head -r329465 .
I was able to use /usr/libexec/kgdb to look at the vmcore.*
file. But my prior attempt to use /usr/local/bin/kgdb failed:
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository
[I historically experiment with system clang as the
system compiler for powerpc64 and powerpc. Thus the
context here is odd.]
As part of getting ready to test base/binutils and base/gcc I
changed how I build for powerpc64 to use WITHOUT_CLANG_IS_CC= .
I expected that after installing (updating) to
# svnlite info /usr/ports/ | grep "^Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 465491
via a poudrirere-devel bulk -a run:
===> Building package for aarch64-none-elf-gcc-6.3.0_2
pkg-static: Unable to a
Willem Jan Withagen wjw at digiware.nl wrote on
Sun Apr 1 12:19:35 UTC 2018 :
> I'm trying to compile a src file with Ceph that has been upgrade to use
> more of the C++17 features, but it fails on a missing function:
>
> /home/jenkins/workspace/ceph-master/src/mds/OpenFileTable.cc:349:26:
> er
My attempted, xtoolchain-gcc based, amd64->aarch64 cross-buildworld-buildkernel
failed with:
--- libc.so.7.full ---
/usr/local/bin/aarch64-unknown-freebsd12.0-ld:
/usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:
error loading plugin: Service unavailable
collect2: error
For:
# pkg info "*binutils"
aarch64-binutils-2.30_2,1
amd64-binutils-2.30_2,1
binutils-2.30_2,1
powerpc64-binutils-2.30_2,1
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision:
On 2018-Apr-7, at 4:37 PM, Alexander Kabaev wrote:
> On Sat, 7 Apr 2018 18:43:17 -0400
> Alexander Kabaev wrote:
>
> Come to think of it, I am not sure I understand the problem.
> amd64-binutils installs "proper" x86_64-freebsd-prefixed binaries. Did
> you expect amd64-freebsd-* ?
My understan
On 2018-Apr-7, at 3:35 PM, Alexander Kabaev wrote:
> On Sat, 7 Apr 2018 15:23:50 -0700
> Mark Millard via freebsd-arm wrote:
>
>> My attempted, xtoolchain-gcc based, amd64->aarch64
>> cross-buildworld-buildkernel failed with:
>>
>> --- libc.so.7.full ---
>> /usr/local/bin/aarch64-unknown-freeb
(Context: buildworld completed before builkernel started.)
My attempt to do buildworld buildkernel via clang but using
aarch64-binutils got the following failure during buildkernel.
(Note the use of: -B/usr/local/aarch64-unknown-freebsd12.0/bin/
for clang.)
--- cloudabi32_vdso.o ---
/tmp/cloudab
[The static build of binutils is what gets the lto involved.]
On 2018-Apr-7, at 5:29 PM, Mark Millard wrote:
> On 2018-Apr-7, at 3:35 PM, Alexander Kabaev wrote:
>
>> On Sat, 7 Apr 2018 15:23:50 -0700
>> Mark Millard via freebsd-arm wrote:
>>
>>> My attempted, xtoolchain-gcc based, amd64->aa
It appears that the devel/aarch64-gcc toolchain refuses to
assemble instructions that are not available to what was
listed for -mcpu, even when a -march was also listed that
allows such. For -mcpu=cortex-a53 and a -march=armv8-a+crypto :
--- secure/lib/libcrypto__L ---
/usr/src/crypto/openssl/cry
Looks like /usr/local/bin/aarch64-unknown-freebsd12.0-gcc with
-x assembler-with-cpp can reject /usr/src/sys/arm64/arm64/locore.S
for operand naming/syntax: icc_sre_el2 is rejected twice (in my
-mcpu=cortex-a53 targeted context). The register icc_sre_el2 seems
to be a GIC-specific register.
--- lo
> Author: kan
> Date: Tue Apr 10 01:00:30 2018
> New Revision: 466933
> URL:
> https://svnweb.freebsd.org/changeset/ports/466933
>
>
> Log:
> Catch up with changed binutils prefix
>
> . . .
> -BUTARGET=x86_64-${OPSYS:tl}
> +BUTARGET=x86_64-unknown-${OPSYS:tl}${OSREL}
Should something
On 2018-Apr-13, at 8:09 PM, Mark Millard wrote:
>> Author: kan
>> Date: Tue Apr 10 01:00:30 2018
>> New Revision: 466933
>> URL:
>> https://svnweb.freebsd.org/changeset/ports/466933
>>
>>
>> Log:
>> Catch up with changed binutils prefix
>>
>> . . .
>> -BUTARGET= x86_64-${OPSYS:tl}
>> +BUTA
I tried to amd64 -> armv7 cross build head -r332861 and got an error about
-lgcc_s not being found. I backed off to -r332858 for other reasons (powerpc*
related). Retrying the armv7 build then worked.
I had first upgraded the amd64 context the first time and had backed off amd64
first the second t
/usr/local/bin/x86_64-freebsd-ld: unrecognized option '--no-rosegment'
is the message that reports what stops the build. I think this traces
back to:
/usr/src/share/mk/bsd.sys.mk:LDFLAGS+= ${LDFLAGS.${LINKER_TYPE}}
being incorrect for an amd64-gcc / x86_64-freebsd-ld based build.
The details
https://gcc.gnu.org/gcc-8/changes.html reports:
• Support for the powerpc*-*-*spe* target ports which have been
recently unmaintained and untested in GCC has been declared obsolete in GCC 8
as announced here. Unless there is activity to revive them, the next release of
GCC will have the
[I experiment with targeting powerpc family members with
modern tool chains. In this case trying to use
devel/xtoolchain-llvm60 . This was indirectly reached via
commenting on a bugzilla entry for something else powerpc
family related.]
BEGIN setup notes:
Because of (at least) lld problems for ta
On 2018-May-11, at 4:09 PM, Mark Millard wrote:
> [I experiment with targeting powerpc family members with
> modern tool chains. In this case trying to use
> devel/xtoolchain-llvm60 . This was indirectly reached via
> commenting on a bugzilla entry for something else powerpc
> family related.]
>
pkg-plist.mips seems to be missing any objcopy variant. (Is objcopy not needed?)
(Only this mips variant uses %%BUTARGET%% notation in the pkg-plist.* file.)
pkg.plist.powerpc64 has 3 objcopy variants/places but 2 man1's.
pkg.plist.sparc64 has 2 objcopy variants/places but one man1.
(no bin/sparc
Retrying the amd64 -> powerpc64 cross build via a powerpc64-gcc
this time, combined with WITH_LIB32= , got: "sh: head: not found" and its
later consequences, like before for installworld (to a directory on the
amd64 host context). This is from the /usr/src/share/mk/bsd.linker.mk line
that results i
On 2018-May-14, at 9:00 AM, John Baldwin wrote:
> On Saturday, May 12, 2018 10:38:20 PM Mark Millard wrote:
>> . . .
>>
>
> Yes, we are now using objcopy from elftoolchain and it seems that
> base/binutils was not updated when that happened. We should probably
> remove objcopy from the other p
On 2018-May-14, at 5:04 PM, Bryan Drewery wrote:
> On 5/13/2018 1:13 AM, Mark Millard wrote:
>> Retrying the amd64 -> powerpc64 cross build via a powerpc64-gcc
>> this time, combined with WITH_LIB32= , got: "sh: head: not found" and its
>> later consequences, like before for installworld (to a di
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
--- all_subdir_usr.sbin/pmc ---
In file included from
/workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/ios:216:0,
from
/workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/iostrea
On 2018-Jun-5, at 10:49 AM, Dimitry Andric wrote:
> On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain
> wrote:
>>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
>>
>> --- all_subdir_usr.sbin/pmc ---
>> In file includ
[Just fixing a dumb typo in a build number.]
On 2018-Jun-5, at 12:22 PM, Mark Millard wrote:
> On 2018-Jun-5, at 10:49 AM, Dimitry Andric wrote:
>
>> On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain
>> wrote:
>>>
>>> https://ci.freebsd
[Note: I sometimes build for powerpc families via clang
as part of identifying what is not yet working. Currently
I do not have access to any powerpc system so I only build.
This involves using devel/powerpc-binutils currently.]
Despite for head -r334932:
# find /usr/src/* -name altivec.h -print
On 2018-Jun-11, at 6:37 AM, Mark Millard wrote:
> [Note: I sometimes build for powerpc families via clang
> as part of identifying what is not yet working. Currently
> I do not have access to any powerpc system so I only build.
> This involves using devel/powerpc-binutils currently.]
>
> Despite
In watching ci.freebsd.org builds I've seen a notable
number of one time failures, such as (example from
powerpc64):
--- all_subdir_lib/libufs ---
ranlib -D libufs.a
ranlib: fatal: Failed to open 'libufs.a'
*** [libufs.a] Error code 70
where the next build works despite the change being
irrelevan
On 2018-Jun-18, at 12:42 PM, Bryan Drewery wrote:
> On 6/15/2018 10:55 PM, Mark Millard wrote:
>> In watching ci.freebsd.org builds I've seen a notable
>> number of one time failures, such as (example from
>> powerpc64):
>>
>> --- all_subdir_lib/libufs ---
>> ranlib -D libufs.a
>> ranlib: fat
On 2018-Jun-18, at 4:08 PM, Bryan Drewery wrote:
> On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
>> ranlib -D libpcap.a
>> ranlib: fatal: Failed to open 'libpcap.a'
>
> Where is this error even coming from? It's not in the usr.bin/ar code
> and ranlib does not cause it.
>
> # ranlib -D uh
> ranlib
On 2018-Jun-18, at 6:03 PM, Mark Millard wrote:
> On 2018-Jun-18, at 4:08 PM, Bryan Drewery wrote:
>
>> On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
>>> ranlib -D libpcap.a
>>> ranlib: fatal: Failed to open 'libpcap.a'
>>
>> Where is this error even coming from? It's not in the usr.bin/ar code
>> an
On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote:
> On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote:
>> Li-Wen reported that the build is done in a 11.1-rel jail though, so
>> the libarchive (or any userland) change shouldn't be responsible.
>>
>> Can we update a canary builder to somewhere betwe
On 2018-Jun-19, at 9:14 PM, Li-Wen Hsu wrote:
> On Tue, Jun 19, 2018 at 9:24 PM Mark Millard wrote:
>>
>> On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote:
>>
>>> On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote:
Li-Wen reported that the build is done in a 11.1-rel jail though, so
the
On 2018-Jun-19, at 9:14 PM, Li-Wen Hsu wrote:
> On Tue, Jun 19, 2018 at 9:24 PM Mark Millard wrote:
>>
>> On 2018-Jun-19, at 8:02 AM, Li-Wen Hsu wrote:
>>
>>> On Mon, Jun 18, 2018 at 8:36 PM Ed Maste wrote:
Li-Wen reported that the build is done in a 11.1-rel jail though, so
the li
[Still true of -r335385. But, based on a build of devel/llvm60
supplying the XCC/XCXX/XCPP, FreeBSD can be built, including the
clang compiler. The problem is FreeBSD system-clang-building
specific, not general to llvm targeting powerp64.]
On 2018-Jun-11, at 12:58 PM, Mark Millard wrote:
> On 2
> On 2018-Jun-27, at 10:01 AM, Bryan Drewery wrote:
>
> As of r335704:
>
> - make tinderbox/universe will now build the bootstrap clang *once*.
> Each target clang is still build of course. This support does not work
> with gcc.
> - make buildworld (kernel-toolchain and toolchain) will build
Going from -r335799 to -r335812 buildworld buildkernel reported:
--- buildworld ---
make[1]: "/usr/src/Makefile.inc1" line 342: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 349: SYSTEM_LINKER: libclang
On 2018-Jun-29, at 10:45 PM, Mark Millard wrote:
> Going from -r335799 to -r335812 buildworld buildkernel reported:
>
> --- buildworld ---
> make[1]: "/usr/src/Makefile.inc1" line 342: SYSTEM_COMPILER: Determined that
> CC=cc matches the source tree. Not bootstrapping a cross-compiler.
> ma
On 2018-Jun-30, at 7:40 PM, Bryan Drewery wrote:
>> On Jun 29, 2018, at 23:32, Mark Millard wrote:
>>
>>
>>
>>> On 2018-Jun-29, at 10:45 PM, Mark Millard wrote:
>>>
>>> Going from -r335799 to -r335812 buildworld buildkernel reported:
>>>
>>> --- buildworld ---
>>> make[1]: "/usr/src/Ma
src/contrib/elftoolchain/elfcopy/sections.c has and uses the macro:
716 #define COPYREL(REL, SZ) do { \
717 if (nrels == 0) { \
718 if ((REL##SZ = malloc(cap * \
719
tech-lists tech-lists at zyxst.net wrote on
Wed Jul 11 11:42:58 UTC 2018 :
> Hello lists [x-posted to -current where it's also relevant]
>
> 12-current-arm64 fails to build generic-nodebug kernel
>
> context:
> 12.0-CURRENT #0 r336134: Mon Jul 9 GENERIC arm64 (this is the older rpi3B+)
>
>
>
On 2018-Jul-12, at 2:44 AM, tech-lists wrote:
> On 11/07/2018 17:21, Mark Millard wrote:
>> It seems from the quoted material that neither kernel-toolchain nor
>> build world was done before buildkernel . My understanding is that
>> the intent is that one or the other be done first. (But for aarc
On 2018-Jul-12, at 11:32 AM, Dimitry Andric wrote:
> On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain
> wrote:
>>
>> On 2018-Jul-12, at 2:44 AM, tech-lists wrote:
>>
>>> On 11/07/2018 17:21, Mark Millard wrote:
>>>> It seems
On 2018-Jul-13, at 3:15 AM, tech-lists wrote:
> On 12/07/2018 19:32, Dimitry Andric wrote:
>> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
>> , an intrinsics header, which in turn requires .
>> This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921,
>> and at
Looks like gcc8 was not added to, for example,
https://svnweb.freebsd.org/ports/head/Mk/bsd.gcc.mk :
# All GCC versions supported by the ports framework. Keep them in
# ascending order and in sync with the table below.
# When adding a version, please keep the comment in
# Mk/bsd.default-versions.
On 2018-Jul-15, at 12:14 PM, Gerald Pfeifer wrote:
> Hi Mark,
>
> On Sat, 14 Jul 2018, Mark Millard via freebsd-toolchain wrote:
>> Looks like gcc8 was not added to, for example,
>> https://svnweb.freebsd.org/ports/head/Mk/bsd.gcc.mk :
>
> I've done t
I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
buildkernel
targeting aarch64 from amd64 based on head -r336349 . It failed by ending up
using an ld that can only target elf_x86_64_fbsd elf_i386_fbsd :
. . .
--- buildkernel ---
Building
/usr/obj/cortexA53_clang/arm64.aar
On 2018-Jul-16, at 3:31 PM, Bryan Drewery wrote:
> On 7/16/18 1:21 PM, Mark Millard wrote:
>> I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
>> buildkernel
>> targeting aarch64 from amd64 based on head -r336349 . It failed by ending up
>> using an ld that can only ta
On 2018-Jul-16, at 4:47 PM, Bryan Drewery wrote:
> On 7/16/2018 3:49 PM, Mark Millard wrote:
>>
>>
>> On 2018-Jul-16, at 3:31 PM, Bryan Drewery wrote:
>>
>>> On 7/16/18 1:21 PM, Mark Millard wrote:
I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
buildker
[ toolchain-metadata.mk is missing when kernel-toolchain is used.
I've no clue if this is intentional or not. ]
On 2018-Jul-16, at 6:13 PM, Mark Millard wrote:
> On 2018-Jul-16, at 4:47 PM, Bryan Drewery wrote:
>
>> On 7/16/2018 3:49 PM, Mark Millard wrote:
>>>
>>>
>>> On 2018-Jul-16, at 3:3
[I experiment with targeting powerpc family via modern
toolchains. So this is outside the official range for
FreeBSD. I've not tried clang 7 yet. The below is
relative to system clang 6 behavior.]
As stands amd64 -> powerpc64 cross builds fail building clang
via the system clang because of errors
[Resent from the right account. I wish I could remove the prior send.]
On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
>
> On 11 Aug 2018, at 19:31, Warner Losh wrote:
>>
>> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric wrote:
>> On 11 Aug 2018, at 16:55, Warner Losh wrote:
>>>
>>> It lo
[Replying from the intended Email address, rather
than the one I accidentally used originally.]
On 2018-Aug-11, at 5:05 PM, Warner Losh wrote:
> On Sat, Aug 11, 2018 at 1:01 PM, Mark Millard
> wrote:
> On 2018-Aug-11, at 11:09 AM, Dimitry Andric wrote:
> >
> > On 11 Aug 2018, at 19:31, Warner
On 2018-Aug-16, at 6:38 AM, Ed Maste wrote:
> On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
> wrote:
>>
>> Is the link command itself available? (The .../sys/*/kernel.full.meta
>> likely has it if it is still around.)
>
> I tried a tinderbox b
> On 2018-Aug-16, at 7:16 AM, Warner Losh wrote:
>
> On Thu, Aug 16, 2018 at 8:14 AM, Mark Millard wrote:
>> On 2018-Aug-16, at 6:38 AM, Ed Maste wrote:
>>
>> > On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
>> > wrote:
>> >>
t;>
>>>> On 11 August 2018 at 20:45, Mark Millard via freebsd-toolchain
>>>> wrote:
>>>>>
>>>>> Is the link command itself available? (The .../sys/*/kernel.full.meta
>>>>> likely has it if it is still around.)
>>>&
Is head buildworld buildkernel supposed to work with:
WITHOUT_BINUTILS_BOOTSTRAP=
without providing an alternate binutils binding for clang to find? My attempt
failed:
--- buildworld ---
make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree.
[My previous build was based on head -r337400 and did not have
this problem. I experiment with powerpc64 and powerpc builds
via fairly modern compilers and toolchains, although I currently
do nto have access to such hardware.]
Despite the amd64 and i386 focused comment in:
QUOTE
# Slim down the i
When I looked at
http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html
I found notes about 2 ABI breakages compared to clang 6 and before:
QUOTE
• Clang’s handling of the GCC packed class attribute in C++ has been
fixed to apply only to non-static data members and not to base
This was targeting amd64.
--- if_fxp.o ---
/usr/src/sys/dev/fxp/if_fxp.c:1630:3: error: array index -1 is before the
beginning of the array [-Werror,-Warray-bounds]
cbp->tbd[-1].tb_size = htole32(m->m_pkthdr.tso_segsz << 16);
^~~
/usr/src/sys/dev/fxp/if_fxp
In looking into another report about using devel/amd64-gcc to buld
head I tried a build of -r338675 ( with WERROR= ). It got:
--- kernel.full ---
linking kernel.full
/usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored.
ctfmerge -L VERSION -g -o kernel.full ...
text
On 2018-Sep-21, at 12:21 PM, Warner Losh wrote:
>> On Fri, Sep 21, 2018 at 12:35 PM Mark Millard via freebsd-hackers
>> wrote:
>> [I decided that freebsd-hackers might be better for this,
>> under a different wording.]
>>
>> sys/dev/fxp/if_fxp.c uses the statement:
>>
>> cbp->tbd[-1].tb_si
[This is based on buildworld buildkernel and installing.]
I've updated to:
# uname -apKU
FreeBSD pine64 12.0-ALPHA7 FreeBSD 12.0-ALPHA7 #17 r338921M: Mon Sep 24
19:19:08 PDT 2018
markmi@pine64:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG
arm64 aarch64 120
On 2018-Sep-25, at 8:29 AM, Ed Maste wrote:
> On 25 September 2018 at 02:06, Mark Millard via freebsd-toolchain
> wrote:
>> [This is based on buildworld buildkernel and installing.]
>>
>> But man ld reports GNU/BFD material:
>>
>> # man ld
>> LD
On 2018-Sep-25, at 9:27 AM, Ed Maste wrote:
> On 25 September 2018 at 11:59, Mark Millard wrote:
>>
>> install -o root -g wheel -m 444 ld.lld.1.gz /usr/share/man/man1/
>> rm -f /usr/share/man/man1/ld.1 /usr/share/man/man1/ld.1.gz; install -l h -o
>> root -g wheel -m 444 /usr/share/man/man1
In trying to follow the base/binutils part of
https://wiki.freebsd.org/ExternalGCC
(or /usr/ports/base/README) for targeting powerpc64 I got:
( My /etc/make.conf has: WRKDIRPREFIX?=/wrkdirs .)
# cd ../../base/binutils/
# make CROSS_TOOLCHAIN=powerpc64-gcc
CROSS_SYSROOT=/usr/obj/DESTDIRs/xtcgcc-
[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
Is the following as intended?
In /usr/src/Makefile.inc1 there is:
# If all targets are disabled for system llvm then don't expect it to work
# for cross-builds.
.if !defined(TOOLS_PREFIX) && ${MK_LLVM_TARGET_ALL} == "no" && \
${MACHINE} != ${TARGET} && ${MACHINE_ARCH} != ${TARGET_ARCH} && \
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 --sy
The following is on a powerpc64 machine (old PowerMac G5 so-called
"Quad Core") running a personal build of head -r339076 that was
built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1).
The compiler for the port build is system-clang (so clang 6 as cc),
not used for buildworld buildkerne
In updating a powerpc64 context after a poudriere-devel bulk run, I
got the following from pkg upgrade . . .
Installed packages to be REINSTALLED: xmlcharent-0.3_2 (ABI changed:
'freebsd:12:powerpc:64' -> 'freebsd:12:*')
. . .
iso8879-1986_3 (ABI changed: 'freebsd:12:powerpc:64' -> 'fre
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-u
[I experiment with using modern compilers on
powerpc64, here buildworld buildkernel was
via devel/powerpc64-xtoolchain-gcc but included
building clang and having clang as cc. clang's
problems are tied to aspects of buildworld
buildkernel but is otherwise usable.]
When clang is built with support f
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 buildker
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 --sy
8 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:
[I was not expecting lldb to work on/for powerpc64. But I
thought the powerpc64le reference by lldb was interesting.]
# lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (powerpc64le).
# file a.out
a.out: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1
While investigating powerpc64 C++ exception handling for
builds under devel/powerpc64-gcc I ran into the following
in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c :
/* As a special exception, if you link this library with other files,
some of which are compiled with GCC, to produce an executable
understand. (But I'm doing some
new experiments these days.)
I've no clue if llvm's libunwind is intended to be compliant with the
powerpc64 and powerpc ABIs that FreeBSD bases itself on for the powerpc
family.
>> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain
&g
as I understand. (But I'm doing some
> new experiments these days.)
>
> I've no clue if llvm's libunwind is intended to be compliant with the
> powerpc64 and powerpc ABIs that FreeBSD bases itself on for the powerpc
> family.
>
>>> On 13 Oct 2018, at 18:12
[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, Ma
dkernel as well as I understand. (But I'm doing some
>> new experiments these days.)
>>
>> I've no clue if llvm's libunwind is intended to be compliant with the
>> powerpc64 and powerpc ABIs that FreeBSD bases itself on for the powerpc
>> f
I now have a patch that gets some basic C++ exception throwing
going for WITH_LIBCPLUSPLUS= use when building via
devel/powerpc64-gcc . But the overall mechanism seems to mess
up the handling of powerpc64's "red zone" style of stack
processing in various cases.
I've had recent list submittals repo
(I happen to be using head -r339076 and ports -r480180
vintage materials, not that I expect such narrow vintage
ties.)
I finally have a simple example of the
issue on powerpc64 . . .
The following simple C++ program shows
a significant difference for powerpc64
depending on which libgcc_s.so is us
[This summarizes other results without the code
and debugger evidence and such from my recent
explorations. It should be much easier to
follow than my exploration reports.]
Documents like DWARF5.pdf document the "row" vs. Location
information for Call Frame Information as (also used
for .eh_frame
[I add a note indicating that clang++ does
generate examples of DW_CFA_remember_state
and DW_CFA_restore_state use for pwoerpc64
that lead to /lib/libgcc_s.so messing up
the exception handling.]
On 2018-Oct-17, at 1:25 PM, Mark Millard wrote:
> [This summarizes other results without the code
> a
[I'm adding toolchain and John B. to the TO: list. John B.
may want to reply to Sean F. I'm also adding a
/lib/libgcc_s.so related item to the list of 3 known
issues.]
> On 2018-Oct-19, at 6:21 AM, Sean Fertile wrote:
>
> Clang isn't getting the tls model wrong, it actually generates pic code by
[Mostly just giving some powerpc64 detail, at least
when base/binutils is used.]
On 2018-Oct-22, at 2:35 PM, John Baldwin wrote:
> On 10/19/18 7:23 AM, Mark Millard wrote:
>> [I'm adding toolchain and John B. to the TO: list. John B.
>> may want to reply to Sean F. I'm also adding a
>> /lib/libg
In trying to amd64 -> armv7 cross build ports via poudriere-devel
use with native cross tools involved (and UFS, not ZFS), I'm
getting about 117 ports that built and then one that ends up stuck
in wait/uwait . ^C to poudriere and restarting it repeats the
stuck behavior at the same point (a cc and
[Attaching to the ld process with gdb and detaching let things
continue.]
On 2018-Oct-26, at 8:42 PM, Mark Millard wrote:
> In trying to amd64 -> armv7 cross build ports via poudriere-devel
> use with native cross tools involved (and UFS, not ZFS), I'm
> getting about 117 ports that built and th
[Some of this discussion occurred off list. The point here
is not specific to the hang that I originally reported.]
On 2018-Oct-27, at 3:03 PM, Mark Millard wrote:
>
>> . . .
>>
>>
>>> There are bugs in qemu that can cause such deadlock, you can try these
>>> 2 patches:
>>> https://github.com/
[Just the __packed removal patch was sufficient to no longer
have the hang problem that I originally reported for the
print/texinfo build in poudriere.]
On 2018-Oct-27, at 4:33 PM, Mark Millard wrote:
> [Some of this discussion occurred off list. The point here
> is not specific to the hang that
[The bigger test still hung up.]
On 2018-Oct-27, at 5:30 PM, Mark Millard wrote:
> [Just the __packed removal patch was sufficient to no longer
> have the hang problem that I originally reported for the
> print/texinfo build in poudriere.]
>
> On 2018-Oct-27, at 4:33 PM, Mark Millard wrote:
>
[I have a work around for the specific activity to avoid
the hang.]
On 2018-Oct-27, at 6:00 PM, Mark Millard wrote:
> [The bigger test still hung up.]
>
> On 2018-Oct-27, at 5:30 PM, Mark Millard wrote:
>
>> [Just the __packed removal patch was sufficient to no longer
>> have the hang problem
For looking into a bugzilla issue I used both
elfdump and objdump for /boot/kernel/kernel
(for example) in a amd64 context and in a
powerpc64 context. I ran into more odd
differences in the powerpc64 context but
noticed one also seen on amd64.
objdump for powerpc64:
(just some examples)
Sections:
On 2018-Nov-4, at 1:06 AM, Thomas Zander wrote:
> On Fri, 1 Sep 2017 at 01:37, Mark Millard wrote:
>
>> [I show some of the target/ppc/translate.c source code
>> and related material this time. Not that I know enough
>> to patch it correctly.]
>
> This is still an issue, correct?
> I tried to
1 - 100 of 264 matches
Mail list logo
