Re: clang options for load segments

[Ed Maste]

On Tue, 2 Mar 2021 at 14:37, Paul Floyd  wrote:
>
> I'll work on fixing it in Valgrind, but that is likely to be fair amount
> of work.

I guess that recent Clang+lld will produce the same PT_LOAD on Linux
too, so it seems like this is definitely something Valgrind will need
to handle.

> No need to hold your breath. Concerning the FreeBSD port I've been
> working on Valgrind on FreeBSD for about a year or so and now it's not
> too far from working as well on FreeBSD as it does on Linux*.
>
> Either install the devel/valgrind-devel package (note: not
> devel/valgrind) or even better build and install from my github repo
> https://github.com/paulfloyd/freebsd_valgrind. I have a commit bit for
> upstream Valgrind and am working on integrating FreeBSD support in the
> 'official' Valgrind. This probably won't be in the next release, 3.17,
> due soon, but I hope that it gets into the next one (3.17.1 or 3.18).
> And I'm always on the lookout for any user feedback :-) .

Thank you so much for this, I will be very happy to finally see
FreeBSD support upstream.

IMO we should look at removing devel/valgrind and replacing it with
valgrind-devel, given the amount of not-upstream work that exists in
both of them.
___
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: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

Adding the FreeBSD-stable list to CC for more visibility.

On Wed, 2 Dec 2020 at 12:43, Ed Maste  wrote:
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.

The crashinfo man page now references the gdb port/package, and
crashinfo itself emits a message that the port/package should be
installed if kgdb is not found.

GDB's proposed retirement has now been added to
https://wiki.freebsd.org/DeprecationPlan.

I expect to make GDB default to NO next week, and then remove it from
the tree a week or two later, if there is no compelling objection.
___
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: Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

On Wed, 2 Dec 2020 at 12:52, Warner Losh  wrote:
>
> even if lldb isn't a complete drop in replacement (I've not used it at all, 
> so I can't say one way or another).

Quick comment on this point - the FreeBSD Foundation has been
sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've done
great work getting it into shape. Their work is in LLVM upstream now,
and they're iterating on fixing issues found by LLDB's test suite.
LLDB 12 should provide a capable userland debugging experience in
FreeBSD 13, although I suspect many users will still install the gdb
port or package for the familiar command line interface.

There's no FreeBSD kernel support in LLDB yet, but it's being investigated.
___
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"

Removing obsolete GDB 6.1.1 for FreeBSD 13

[Ed Maste]

We currently have an obsolete version of GDB 6.1 installed as
/usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
some basic information from a kernel core dump after a crash. If the
gdb port is installed crashinfo will use that in preference to
/usr/libexec/gdb. If neither exists it will not perform any analysis,
reporting "Unable to find a kernel debugger."

GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
support all of the architectures that FreeBSD does, and imposes
limitations on the FreeBSD kernel build - the continued use of DWARF2.

I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
switch the GDB knob to default to NO in the near future. If the
crashinfo utility and related man pages do not already include
references to installing the gdb port/package I will add those before
making the change.

In the fullness of time we may use LLDB to extract the same
information, or provide other tooling to do so, but I do not want to
block GDB 6.1.1's removal on this.

Please let me know of any objections or comments.
___
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: add linker option for LIB32 step on PowerPC64

[Ed Maste]

On Thu, 2 May 2019 at 14:03, Alfredo Dal Ava Junior
 wrote:
>
> Hi all,
>
> I'm working on having PowerPC64 using LLVM by default, but LLD support for 32 
> bit seems to be incomplete.  As workaround I'm using ld.bfd (2.17) for the 
> LIB32 step.

Ok - eventual goal should be to have 32- and 64-bit linked with lld,
but I have no objection to an interim step that uses ld.bfd 2.17.50
for the 32-bit build. Note that there's a goal of removing GCC 4.2.1
and binutils 2.17.50 (requiring external toolchain for architectures
that have not migrated to clang/lld).

> I found no way to specify the linker for LIB32 step, so I created a variable 
> called LIB32LD that I pass to "make buildworld". Apparently we'll have to 
> make this workaround official, so I would like to know your thoughts about 
> this approach or if you have some other idea to share.

I think this would be fine, and it would default to ld.bfd on ppc64?
___
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: Optimization bug with floating-point?

[Ed Maste]

On Mon, 25 Mar 2019 at 14:32, Steve Kargl
 wrote:
>
> This is now
>
> https://bugs.llvm.org/show_bug.cgi?id=41224

Thanks for submitting a bug report to LLVM, I hope it gets some traction.
___
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: Linking problem with lld

[Ed Maste]

On Fri, 22 Feb 2019 at 10:09, Willem Jan Withagen  wrote:
>
> My guess is that your linker doesn't support the new symbol versioning
> exports and since the symbols are hidden by default they aren't visible
> in the shared library. Previously there was a bug (since Luminous and
> the switch the cmake) where every public and private symbol was exported
> by librados.

lld is largely compatible with GNU ld / gold on the command-line and
in linker scripts and version scripts. Can you provide the error you
see or an example of one of the symbols with incorrect visibility?
___
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: GNU binutils 2.17.50 retirement planning

[Ed Maste]

On Sat, 24 Nov 2018 at 17:24, Charlie Li  wrote:
>
> some Makefile logic in stand/i386/btx specify a
> hard-coded /usr/bin/as without bootstrapped binutils, necessitating a
> symlink.

Which logic specifically? I can't seem to find it.

> If it is true that the only assembly files that clang IAS cannot
> assemble are for amd64 and i386, has there been any research into nasm
> and yasm at least? nasm is specified as a build dependency in certain
> multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code.
> Both are licensed under some BSD licence variant.

The most significant issue is
sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use
of GNU macro extensions. I have looked at nasm and yasm but believe
the macro extension support in those is less developed than in Clang's
IAS.

There are a number of files in stand/ tagged with CLANG_NO_IAS, in
gptzfsboot, cdboot, zfsboot, boot2, and pxeldr. These could likely be
removed now (they were added because Clang IAS did not support .codeNN
long ago), but they need to be tested first because the generated
output is slightly different.
___
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: GNU binutils 2.17.50 retirement planning

[Ed Maste]

On Sun, 25 Nov 2018 at 07:52, David Chisnall  wrote:
>
> We probably need to kill ld.bfd before 12.0.  It predates ifunc and so 
> interprets anything with an ifunc as requiring a copy relocation.

I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd
when LLD_IS_LD is enabled. This will have the effect of removing
ld.bfd on amd64 (where ifuncs are in use) as well as other
architectures which do not yet use ifuncs, but this seems like a
reasonable step in the process of removing these obsolete tools.
___
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"

GNU binutils 2.17.50 retirement planning

[Ed Maste]

For some time we have been incrementally working to retire the use of
obsolete GNU Binutils 2.17.50 tools. At present we still install three
binutils by default:

as
ld.bfd
objdump

The intent is to retire all of these by FreeBSD 13. Depending on tool
and architecture we will just remove it, migrate to LLVM tools, or
rely on external toolchain components.

Retiring GNU as requires further investigation and effort as we have
some assembly files (for amd64 at least) which cannot be assembled by
Clang's integrated assembler. If Clang gains support for the required
functionality we'll switch to using IAS for all assembly files, and if
not we could rewrite the few assembly files to work with IAS.

ld.bfd is installed, but is not the default linker (/usr/bin/ld) on
amd64, arm64 and arm, and soon i386 as well. We can just stop
installing it at the appropriate time.

For objdump I have proposed installing LLVM's llvm-obdump as objdump,
in review D18307. It does not support all of the options that GNU
objdump does, but is usable for many common operations. In addition,
non-obsolete GNU objdump is available in the binutils port or package.
Please try out llvm-objdump and see if it supports the options you
need/use, and add a note in PR 229046 if not.
___
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: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

[Ed Maste]

On 25 September 2018 at 14:21, Mark Millard  wrote:
>
> Did you notice the delete-old listing that I provided? It
> included: (>>> from delete-old prefix replaced below)

No I missed that.

> It appears that delete-old should not be listing
> /usr/share/man/man1/ld.1.gz as something to potentially delete
> in this aarch64 context.

Correct. I now have a fix waiting on re@ approval, thanks for the report.
___
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: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

[Ed Maste]

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/ld.lld.1.gz 
> /usr/share/man/man1/ld.1.gz

So this looks like ld.1 should indeed be a link to ld.lld.1.

Is it possible you're getting ld.1 from /usr/local? Does
/usr/share/man/man1/ld.1.gz exist?
___
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: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

[Ed Maste]

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(1)GNU Development Tools   LD(1)
...

Odd. I see this on ref12-arm64.freebsd.org as well. It claims to be
r334753:336279M, which spans some related work (r335447).

Can you find instances of ld.1 in your install log?
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Ed Maste]

On 23 September 2018 at 07:31, Michael Tuexen  wrote:
> Using this patch I was able to build/install world and kernel on an i386 
> system.
> However, after removing it, I can't build world then. When trying to compile a
> kernel "the old way" I end up with:
>
> tuexen@head:~/head/sys/i386/conf % config -g TCP
> WARNING: duplicate option `GEOM_PART_GPT' encountered.
> Kernel build directory is ../compile/TCP
> Don't forget to do ``make cleandepend && make depend''
> tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/
> tuexen@head:~/head/sys/i386/compile/TCP % make -j 6
> make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel 
> requires linker ifunc support
>
> This is r338893.
>
> amd64 works without any problem. So this is i386 specific. Any idea how to 
> fix it?

This safety belt is in place to ensure we don't build a non-functional
kernel - now that the i386 kernel requires ifunc support using old GNU
ld results in a kernel that doesn't boot.

The workaround for the "old way" is to explicitly set LD=ld.lld in the
environment - "LD=ld.lld make -j 6" should work. More details in this
-arch thread, when amd64 encountered this hiccup:
https://lists.freebsd.org/pipermail/freebsd-arch/2018-May/018967.html

The same issue now affects i386 as it has started using ifuncs, and
will be resolved once we can switch i386's /usr/bin/ld to be lld,
which is waiting on ports fixes in PR214864.
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Ed Maste]

On 21 September 2018 at 15:31, Mark Johnston  wrote:
>
> Perhaps the following?  It's not quite right since it'll still use
> -zifunc-noplt with an external LLVM toolchain, but I can't seem to
> figure out how to define a linker feature for only non-cross toolchains.
> In any case, we're going to upstream the option soon.

I wouldn't worry too much about out-of-tree since it will be upstream
soon as you say, otherwise looks good.

> +.if ${MACHINE_CPUARCH} == "amd64" || ${MACHINE_CPUARCH} == "i386"
> +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
>  .error amd64/i386 kernel requires linker ifunc support
>  .endif
> +.if defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc-noplt} != ""

Maybe roll && defined(LINKER_FEATURES) into the outer .if?
___
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: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Ed Maste]

On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain
 wrote:
> In looking into another report about using devel/amd64-gcc to buld
> head I tried a build of -r338675 ( with WERROR= ). It got:
>
...
>
> Question:
>
> Is ignoring "-z ifunc-noplt" a problem for using what
> is built?

This will have no functional impact, should just result in a missed
optimization. (We ought to avoid passing it to non-lld linkers
though.)
___
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: Broken arm support in clang now?

[Ed Maste]

On 16 August 2018 at 10:49, Mark Millard  wrote:
>
> Ahh. Okay. 32-bit non-armv7+ cannot be fully llvm based.
> Intersting.

Indeed; there are a couple of patches in review upstream to address
the outstanding issues involved with using lld to link armv5/armv6.

> The implication would be that ld was then directly
> invoked instead of via cc (clang).

Yes, the issue I encountered appears to be a bug in recent logic that
shares a single clang and lld for multiple architectures in "make
tinderbox." It's directly invoking a newly-built lld.

The other issue observed with lld errors from linking arm or armv6
appears to be due to a failure to execute "make buildworld" or "make
kernel-toolchain" before "make buildkernel." In this case the build
invokes the host's system linker (ld). Previously on amd64 this was
the GNU BFD ld, not a cross-linker, and this resulted in an error. Now
that amd64's system ld is lld it's inherently a cross linker.
___
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: Broken arm support in clang now?

[Ed Maste]

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 build right now and saw the lld warnings from
linking zfs.ko.  It appears to be fallout from the change to build
clang and lld only once for tinderbox, because we're invoking ld from
the ${HOST_TARGET} path:

/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld
-m armelf_fbsd -Bshareable -znotext -d -warn-common --build-id=sha1
-o zfs.ko.full zfs.kld
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld:
warning: lld uses extended branch encoding, no object with
architecture supporting feature detected.
/scratch/tmp/emaste/obj/scratch/tmp/emaste/freebsd/freebsd11-amd64/tmp/usr/bin/ld:
warning: lld may use movt/movw, no object with architecture supporting
feature detected.
___
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: Migrating arm(v7) to LLD_BOOTSTRAP

[Ed Maste]

On 16 January 2018 at 18:45, Ed Maste  wrote:
> With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready
> to be used as the system linker for armv7, and I plan to enable
> LLD_BOOTSTRAP by default after a couple of WIP patches land and after
> a little more testing. This may happen a week or two from now. This
> should have little impact on port builds, because /usr/bin/ld will
> still be GNU ld.bfd (although there may be some unexpected fallout).

There was one significant issue preventing use of lld for armv7 - it
was not handling float type flags in the ELF header.

This was just fixed upstream, and I brought the change into FreeBSD in
r336972. I believe we're now ready to enable LLD_BOOTSTRAP by default
for armv7, and have posted the patch in review D16528[1] for
comments/feedback.

[1] https://reviews.freebsd.org/D16528
___
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: Tool Chain Migration: objdump users, please test llvm-objdump

[Ed Maste]

On 21 June 2018 at 09:09, Ed Maste  wrote:
>
> We'll also need a man page.

I took a quick look at this, and in doing so found that the output
from "llvm-objdump --help" appears to be missing a large number of
single-letter options, so one more thing to sort out.

As it happens there are LLVM bugs open for a number of the
llvm-objdump issues (even including some I submitted but forgot
about):
https://bugs.llvm.org/buglist.cgi?component=llvm-objdump_id=140941=tools_format=advanced=---
___
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: Tool Chain Migration: objdump users, please test llvm-objdump

[Ed Maste]

On 20 June 2018 at 17:26, Alexander Richardson  wrote:
>
> When I made the change to use llvm-objdump in CheriBSD I had to change the
> objdump flags from -xrsSd to -r -s -p -S -d -h -l -t.

Ah yes, I recall discussing this now. Per GNU objdump's man page, -x
is equivalent to -a -f -h -p -r -t. llvm-objdump doesn't support
these:

-a archive headers
-f file headers

so we probably want to address those as well. We'll also need a man page.
___
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: Tool Chain Migration: objdump users, please test llvm-objdump

[Ed Maste]

On 20 June 2018 at 18:25, Shawn Webb  wrote:
>
> Would you like me to quantify the compilation breakages due to the
> full llvm toolchain switch? If so, I can do that after July 12th.

Thanks Shawn, right now I'm interested specifically in llvm-objdump,
with the goal of sorting it out in advance of FreeBSD 12.

I think it's a worthwhile endeavour to quantify the breakage from
using all of the LLVM tools though, and if you're able to triage the
issues and submit LLVM, FreeBSD, or upstream port issues as
appropriate that would be much appreciated. (It's just not yet on the
critical path for me.)
___
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"

Tool Chain Migration: objdump users, please test llvm-objdump

[Ed Maste]

Work is in progress to migrate fully to modern and permissively
licensed components for the tool chain. This includes moving away from
the three obsolete binutils components that are still in the base
system (as, ld, objdump). objdump is a tool to report information
about binary objects (such as headers, symbols, etc.), is not required
as a build tool, and in any case many uses of objdump are better
served by readelf.

For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is
open to track tasks related to its removal, and users who need GNU
objdump can install an up-to-date version from the ports tree or the
binutils package.

That said, llvm includes a somewhat equivalent llvm-objdump, and it is
built by default in FreeBSD now. If llvm-objdump's command line option
support and output format is "close enough" to GNU objdump for most
users we may decide to install it as /usr/bin/objdump. Therefore, I
would like to ask users of GNU objdump in FreeBSD to give llvm-objdump
a try. Please let me know if it works for your uses, or describe
deficiencies that you found.

[1] https://bugs.freebsd.org/229046
___
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: A head buildworld race visible in the ci.freebsd.org build history

[Ed Maste]

On 18 June 2018 at 19:29, Bryan Drewery  wrote:
>
> The error is coming from libarchive which had a change between those
> revisions:
>
>> 
>> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines

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 between r328278 and r88?
___
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"

HEADS-UP: Linker issues building amd64 kernels with config & make

[Ed Maste]

As of r333461 the amd64 kernel makes use of ifuncs, and requires
support in the linker. A safety belt added in r333470 enforces this,
and will produce an explicit error if the linker does not support
ifuncs.

lld is the default bootstrap linker for amd64 and has ifunc support.
The typical 'make buildworld' (or kernel-toolchain) followed by 'make
buildkernel' process will use lld and successfully link a working
kernel.

The old-style kernel build (using 'config' followed by a 'make' in the
kernel directory) uses the host linker (/usr/bin/ld). This still
defaults to GNU ld 2.17.50, which does not support ifuncs. This can be
worked around in one of two ways:

1. Install lld as the system linker (/usr/bin/ld), by adding
WITH_LLD_IS_LD to /etc/src.conf and building and install world.
WITH_LLD_IS_LD will become the default on amd64 in the near future -
I'm just waiting on updates to the lang/ghc port and another exp-run.

2. Override LD when you build the kernel:
$ LD=ld.lld make

These tool chain components will undergo additional changes for the next while.
___
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: Heads-up: linker (lld) changes for amd64 coming soon

[Ed Maste]

On 26 March 2018 at 22:14, Ed Maste <ema...@freebsd.org> wrote:
> Some changes related to the amd64 linker are nearly ready to be
> committed (within a week or three), so I'm sending this notice to
> request any final comments or concerns before these changes are made.

It took somewhat longer than a week or three, but these changes will
now happen quite soon.

> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the
> first use being Supervisor Mode Access Prevention (SMAP) on amd64.
> This relies on linker support that is available in the in-tree lld and
> in contemporary binutils ld.bfd from ports, but not in the in-tree
> ld.bfd 2.17.50.

This is ready to be committed at any time.

> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld,
> and thus the linker used for linking ports. I plan to switch this to
> default on.

There was one significant remaining issue in the ports tree with lld
as /usr/bin/ld: lang/ghc. This was due (at least in part) to a bug in
lld's note handling. The bug is now fixed upstream and in FreeBSD in
r333401.

The latest version of ghc claims to have improved support for using
lld as the linker, and a lang/ghc update is currently in progress
(PR227968). Once this is committed I will request one more exp-run
with lld. As long as those results are acceptable, I'll then make the
switch to install lld as /usr/bin/ld on amd64.
___
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: Heads-up: linker (lld) changes for amd64 coming soon

[Ed Maste]

On 26 April 2018 at 23:07, Fāng-ruì Sòng  wrote:
>
> I'd like to experiment with LLD --warn-backrefs, which keeps compatibility
> with GNU linkers (bfd, gold) in terms of handling of LazyArchive and
> LazyObject (see
> http://lists.llvm.org/pipermail/llvm-dev/2018-April/122383.html for
> details).

Ah, thanks for the note. It was not documented in lld's man page; I
just added it upstream.

> I think a few representative FreeBSD packages may be a great playground to
> try --warn-backrefs
>
> Do you have some pointers on how I can build these packages locally with
> --warn-backrefs ?

Just adding LDFLAGS=-Wl,--warn-backrefs to /etc/make.conf should be
sufficient. I'm not sure of the proper way to replace the linker (with
a build from upstream that supports --warn-backrefs) or provide a
custom make.conf in Poudriere though, and hope that someone else can
provide some guidance on that.
___
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: Heads-up: linker (lld) changes for amd64 coming soon

[Ed Maste]

On 27 March 2018 at 18:21, Ed Maste <ema...@freebsd.org> wrote:
> (Moved from -current to -ports)
>
> On 27 March 2018 at 13:15, Ed Maste <ema...@freebsd.org> wrote:
>>
>> Fair enough - this was the reason I sent the email. I've now gone
>> through and submitted a PR for for each failure that did not already
>> have one. I've also added LLD_UNSAFE to a few ports where where it was
>> straightforward.
>
> Via tobik's commit to lang/myrddin (r465725) I discovered
> BINARY_ALIAS=ld=ld.bfd, which is a usable workaround for some ports
> which don't honour $LD or -fuse-ld=bfd in CFLAGS.

As of ports r465900 BINARY_ALIAS is now set automatically if LLD_UNSAFE is set.

There are now 14 PRs open for failures when lld is /usr/bin/ld. Thanks
to recent commits from krion@ all unmaintained ports that had issues
have been addressed, except for print/openprinting (PR221809) and some
openal-related failures (PR226980). I'll try to take a look at the
openal issues; it's likely that the interim solution will be just to
set LLD_UNSAFE in all of the dependent ports.

The remaining 12 PRs are all for maintained ports. I believe that now
the only port responsible for a significant number of skipped
dependent ports is lang/ghc (PR226872).
___
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: Heads-up: linker (lld) changes for amd64 coming soon

[Ed Maste]

(Moved from -current to -ports)

On 27 March 2018 at 13:15, Ed Maste <ema...@freebsd.org> wrote:
>
> Fair enough - this was the reason I sent the email. I've now gone
> through and submitted a PR for for each failure that did not already
> have one. I've also added LLD_UNSAFE to a few ports where where it was
> straightforward.

Via tobik's commit to lang/myrddin (r465725) I discovered
BINARY_ALIAS=ld=ld.bfd, which is a usable workaround for some ports
which don't honour $LD or -fuse-ld=bfd in CFLAGS.

As you point out in reply to my r465755 BINARY_ALIAS alone is not
sufficient, because arm64 does not provide ld.bfd by default and
LLD_UNSAFE automatically brings in ports binutils if /usr/bin/ld.bfd
does not exist. So we need both LLD_UNSAFE and BINARY_ALIAS.

Should we just have LLD_UNSAFE also set BINARY_ALIAS=ld=ld.bfd?
___
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: Heads-up: linker (lld) changes for amd64 coming soon

[Ed Maste]

On 27 March 2018 at 02:20, Antoine Brodin  wrote:
>> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the
>> first use being Supervisor Mode Access Prevention (SMAP) on amd64.
>> This relies on linker support that is available in the in-tree lld and
>> in contemporary binutils ld.bfd from ports, but not in the in-tree
>> ld.bfd 2.17.50.
>
> I have no concerns about 1.

OK. My guess is I won't get any other feedback on this one until it
makes it into a release. I suspect kib will commit this part later
this week or early next week.

>> 2. WITH_LLD_IS_LD controls whether /usr/bin/ld is ld.bfd or ld.lld,
>> and thus the linker used for linking ports. I plan to switch this to
>> default on.
>>
>
> About 2.,  I am concerned that changes breaking a large number of
> ports are committed without portmgr@ approval.
> If WITH_LLD_IS_LD is committed as is on amd64,  packages for head
> won't be published as it doesn't meet our current criteria for
> publication.

Fair enough - this was the reason I sent the email. I've now gone
through and submitted a PR for for each failure that did not already
have one. I've also added LLD_UNSAFE to a few ports where where it was
straightforward.

In this batch of PRs I noticed four main issues:

1. Ports that pass compiler flags, such as -fPIC, to the linker. lld
has more strict command-line parsing and rejects these invalid
invocations, while ld.bfd happily creates bogus output (e.g. a shared
library with a DT_AUXILIARY entry of "PIC"). PR 221808 has a
reasonable discussion of this issue.

2. lld has no built-in search paths (/lib, /usr/lib). Normally the
linker is invoked from the compiler driver, which provides default
search paths. If lld is invoked directly then library search paths
must be specified explicitly with -L/lib -L/usr/lib.

3. Shared library protected visibility symbol preemption.

4. lld does not have a built-in default output target. For the common
use of the linker (linking individual .o objects into an executable or
shared object) lld infers the target from the first object file.
However, when the linker is used to convert an arbitrary binary file
into an ELF ojbect (via -r -b binary) lld needs the output target to
be specified explicitly with -m.

The vast majority of skipped ports in the exp-run come from two
failures: lang/ghc (PR226872) and lang/fpc (222172). The PR for
lang/ghc reports that the current released version of ghc mentions
improved lld support; I hope the port update will solve this issue.

I submitted a bug report upstream for lang/fpc about one fpc bug that
affected lld, and that issue has now been resolved upstream. We'll
need to check again once the port is updated.
___
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: Migrating arm(v7) to LLD_BOOTSTRAP

[Ed Maste]

On 17 January 2018 at 00:35, Michal Meloun  wrote:
>
>>> ld: error: lld may use movt/movw, no object with architecture
>>> supporting feature detected.
>
> But this means that we can not use lld for kernel module linking.
> (assuming that lld can emits movt/movw with attached relocation).

Right now for pre-v7 lld exits with the "may use" before attempting to
link, with no indication of whether movt/movw would actually be used.

It seems in practice linking armv7 with lld does not use movt/movw.
___
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"

Migrating arm(v7) to LLD_BOOTSTRAP

[Ed Maste]

With the update to Clang/LLVM/lld 6.0.0 I believe lld is nearly ready
to be used as the system linker for armv7, and I plan to enable
LLD_BOOTSTRAP by default after a couple of WIP patches land and after
a little more testing. This may happen a week or two from now. This
should have little impact on port builds, because /usr/bin/ld will
still be GNU ld.bfd (although there may be some unexpected fallout).

I expect to enable LLD_IS_LD by default a little later, and
/usr/bin/ld will then be lld. This is the same path we're taking with
amd64.

lld currently does not support architectures prior to armv7, and fails
with some combination of these errors when I try to use it for
arm{,v5,v6,eb}:

ld: error: lld uses blx instruction, no object with architecture
supporting feature detected.
ld: error: lld uses extended branch encoding, no object with
architecture supporting feature detected.
ld: error: lld may use movt/movw, no object with architecture
supporting feature detected.

I expect this will be addressed in a future version of lld.
___
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: Ports and LLVM's lld linker

[Ed Maste]

On 18 December 2017 at 22:10, Ed Maste <ema...@freebsd.org> wrote:
>
> With a couple of recent changes in src head (r326831 and r326897) lld
> is now suitable for use as the base system /usr/bin/ld on amd64 and
> i386. We're working through ports failures, starting with those
> responsible for the largest number of skipped ports.
>
> The top four, on amd64:
>
> port# skipped
> devel/libunwind 7994
> databases/postgresql*-client230

These two are now addressed by setting LLD_UNSAFE=yes so that they'll
still link with ld.bfd once ld.lld is installed as /usr/bin/ld.

The issue with libunwind was already reported upstream (from someone
trying to use ld.gold, which fails in the same way), and libunwind's
developers will address it in a new version.

The postgresql*-client issues need more investigation, but now will
not prevent the migration to lld.

> lang/fpc76

This one's a little tricky, because it's a (Pascal) tool chain that
doesn't support usual environment variables like LD to specify a
linker explicitly.

> lang/mono   22

I'll mark this one LLD_UNSAFE after a libtool dependency is sorted out
(PR224514).

After setting LLD_UNSAFE=yes for libunwind some previously-skipped
ports attempt to build, and some of those now fail with lld. I'm
working through that list and may have a dozen or so more that will
become LLD_UNSAFE.
___
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: Ports and LLVM's lld linker

[Ed Maste]

On 27 November 2017 at 15:39, Ed Maste <ema...@freebsd.org> wrote:
> We're making good progress on using LLVM's lld linker as FreeBSD's
> /usr/bin/ld, so I'd like to raise awareness of the new linker within
> the ports community.

With a couple of recent changes in src head (r326831 and r326897) lld
is now suitable for use as the base system /usr/bin/ld on amd64 and
i386. We're working through ports failures, starting with those
responsible for the largest number of skipped ports.

The top four, on amd64:

port# skipped
devel/libunwind 7994
databases/postgresql*-client230
lang/fpc76
lang/mono   22

The remaining failures are responsible for no more than 2 skipped ports each.

devel/libunwind fails due to the shared object protected visibility
symbol preemption issue; Dimitry Andric and I are searching for an
appropriate fix.

The databases/postgresql*-client failures have been worked around by
r456635, adding LLD_UNSAFE=yes so that the port uses ld.bfd.

lang/fpc appears to suffer from stricter validation performed by lld:
/usr/bin/ld: error: x86_64/units/x86_64-freebsd/i_linux.o: invalid
alignment of section headers

lang/mono fails because lld defaults to -z text, disallowing
relocations in read-only segments (like .text). A workaround is to add
-z notext to the link command line, which turns off lld's error for
this case and results in the same behaviour as ld.bfd and ld.gold
provide by default.

Unfortunately usual workarounds (LLD_UNSAFE=yes or
LDFLAGS=Wl,-z,notext) fail for both lang/fpc and lang/mono, and it's
not immediately obvious to me how their respective builds handle the
options. I'll probably need help from acm@ and mono@ for these.

For reference the remaining ports failing with lld on amd64 are:
archivers/lua51-zlib
audio/alure
benchmarks/wrk
databases/postgres-xl
devel/libds
devel/libtecla
devel/pdcurses
devel/ztcl
emulators/gem5
ftp/rexx-curl
irc/eggdrop
irc/eggdrop-devel
irc/evangeline
lang/rexx-imc
lang/rexx-regutil
lang/siod
lang/smlnj
lang/tclX
mail/qmail-dk
math/rexx-regmath
misc/seabios
net-im/uTox
net/py-netif
net/py-netif
print/openprinting
print/pdftk
security/otpw
shells/bash-static
sysutils/dupd
sysutils/e2fsprogs
sysutils/installwatch
sysutils/unieject
www/cgihtml
www/dummyflash
www/mod_jk
www/mozplugger
www/tdom
___
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: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]

[Ed Maste]

On 4 November 2017 at 07:41, Andriy Gapon  wrote:
> On 04/11/2017 12:32, Mark Millard wrote:
>>   if (int Err = ::posix_fallocate(FD, 0, Size)) {
>> if (Err != EOPNOTSUPP)
>>   return std::error_code(Err, std::generic_category());
>>   }
>
> The commit message that you didn't include into your reply contains some 
> useful
> information that authors / maintainers of this code should probably take into
> account:
>
>>   Please note that EINVAL is used to report that the underlying file system
>>   does not support the operation (POSIX.1-2008).
>
> Here is a link for that:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html

I have no idea how they decided EINVAL was a reasonable errno for this case.

Mark, can you give this patch a try:

diff --git a/contrib/llvm/lib/Support/Unix/Path.inc
b/contrib/llvm/lib/Support/Unix/Path.inc
index 45097eb918b7..67edb46f0025 100644
--- a/contrib/llvm/lib/Support/Unix/Path.inc
+++ b/contrib/llvm/lib/Support/Unix/Path.inc
@@ -427,7 +427,7 @@ std::error_code resize_file(int FD, uint64_t Size) {
   // If we have posix_fallocate use it. Unlike ftruncate it always allocates
   // space, so we get an error if the disk is full.
   if (int Err = ::posix_fallocate(FD, 0, Size)) {
-if (Err != EOPNOTSUPP)
+if (Err != EINVAL && Err != EOPNOTSUPP)
   return std::error_code(Err, std::generic_category());
___
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: June 2017 update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

On 12 June 2017 at 17:21, Ed Maste <ema...@freebsd.org> wrote:
> Another update on using LLD as the FreeBSD base system linker:

Since "amd64" and "arm64" look similar, let me clarify one point:

arm64 -- 64-bit ARM -- is built with, and has as /usr/bin/ld, LLD
4.0.0. This is true in HEAD and in stable/11 (and hence the upcoming
11.1)

amd64 -- 64-bit x86 -- is built with, and has as /usr/bin/ld, GNU BFD
ld 2.17.50. LLD is installed as ld.lld; adding -fuse-ld=lld to CFLAGS
can be used to test linking various software with LLD. Also, the amd64
linker will not change in stable/11.

> Then the ports infrastructure
> can automatically use ld.bfd, until the issue is addressed in the
> individual port or in LLD. It will be something like
> "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so.

Still waiting on this; once it is ready I expect to switch amd64 to LLD.

> Outstanding issues with i386 and 32-bit arm prevent us from turning it
> on for those architectures right now. The LLVM tracking bug in
> http://llvm.org/pr23214 depends on those individual issues; i386
> should be relatively straightforward, while arm needs more work.

i386 still needs investigation, but progress has been made on 32-bit
arm. andrew@ booted an lld-linked arm kernel/userland to the login
prompt, with a few workarounds. Note that this is specifically for
armv7. LLD does not currently support earlier ARM architectures.
TARGET_ARCH=armv7 support is in discussion/planning, and for now I
assume that we'd initially switch only it to LLD. TARGET_ARCH=arm and
TARGET_ARCH=armv6 will continue to use ld.bfd.

It appears we are on a credible path to enable LLD by default in 12.0
for the tier-1 and almost tier-1 architectures of i386, amd64, armv7,
arm64.
___
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"

June 2017 update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

Another update on using LLD as the FreeBSD base system linker:

> We now have LLD 4.0.0 in the tree and it can build all of
> FreeBSD/amd64 kernel and world, and most of ports.

LLD 4.0.0 is in HEAD and stable/11, and WITH_LLD_IS_LD and
WITH_LLD_BOOTSTRAP are enabled by default for arm64 on both branches.
There are a few post-4.0.0 bugfixes in LLD that we need to import into
HEAD in short order and MFC for the 11.1 release.

It is possible to build both the amd64 and arm64 world + kernel with
WITH_LLD_IS_LLD and WITH_LLD_BOOTSTRAP. My daily driver desktop and
laptop are using LLD as /usr/bin/ld.

>> 6. Request ports exp-runs and issue a call for testing with 3rd party
>> software. Fix issues found during this process.
>
> This is in progress now, in PR 214864. There are currently 270 failing
> ports and 963 skipped. The top ten failing ports (by # skipped) are
> responsible for 808 of the skipped; addressing those should allow us
> to build nearly 98% of the ports collection with LLD.

bapt@ and I discussed this at BSDCan and we intend to create a way to
flag ports that don't build with LLD. Then the ports infrastructure
can automatically use ld.bfd, until the issue is addressed in the
individual port or in LLD. It will be something like
"USES=linker:not_lld" or "LLD_UNSAFE=yes" or so.

>> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
>> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
>
> While there is still no timeline set for this, it is already done for
> arm64 (where we have no in-tree GNU ld available), and it is close to
> being feasible for amd64. Further investigation is needed on i386 and
> 32-bit arm before moving forward here.

Once the ports infrastructure is in place I plan to enable LLD as
/usr/bin/ld by default on amd64.

Outstanding issues with i386 and 32-bit arm prevent us from turning it
on for those architectures right now. The LLVM tracking bug in
http://llvm.org/pr23214 depends on those individual issues; i386
should be relatively straightforward, while arm needs more work.
___
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: svn commit: r317159 - head/contrib/libstdc++/config/abi/pre

[Ed Maste]

On 19 April 2017 at 15:06, Ed Maste <ema...@freebsd.org> wrote:
> Author: emaste
> Date: Wed Apr 19 19:06:47 2017
> New Revision: 317159
> URL: https://svnweb.freebsd.org/changeset/base/317159
>
> Log:
>   libstdc++: fix symbol version script for LLD
>
>   LLD is less tolerant of inconsistencies in the symbol version script.
>
>   - Add a ; on the last entry in a version block
>   - Remove duplicated symbols, retaining those in the earliest block

For reference, with this change and two others I was able to link
FreeBSD/mips64 world and kernel using the in-tree LLD 4.0.0, although
I haven't yet tested the result. Everything was compiled with the
in-tree GCC 4.2.1.

The other changes I used:
1) applying -mxgot globally, by adding it to CFLAGS in bsd.cpu.mk
2) disabling static_libpam in lib/libpam/Makefile

There is a patch in LLVM's Phabricator to add multi-GOT support to
LLD[1], although it's meeting some resistance: LLD's main authors
don't want the additional complexity in LLD to support ABI oddities
that only apply to MIPS.

The static libpam failed because it needs to output a relocatable
object (ld -r) from multiple input object objects with
different/non-zero ri_gp_value, and LLD is not capable of this.

[1] https://reviews.llvm.org/D31528
___
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: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?

[Ed Maste]

On 14 April 2017 at 20:16, Mark Millard  wrote:
> So it sounds like I can freely mix WITH_LLD_IS_LD and WITH_SYSTEM_COMPILER
> in any system-clang 4.0 based system build context, no actual problem
> cases, even if the existing system build used a binutils ld (for example).

Yes. WITH_LLD_IS_LD implying WITHOUT_SYSTEM_COMPILER was added because
LLD requires tblgen and libllvm, but they were originally built only
when needed for Clang. In cases where the SYSTEM_COMPILER default
logic determined that the host compiler was identical to the
to-be-built bootstrap compiler the build would skip building Clang,
tblgen, and libllvm. This was fixed by r316647 and the connection
between LLD_IS_LD and SYSTEM_COMPILER can be removed in due course.
___
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: FYI: amd64 built with WITH_LLD_IS_LD= vs. devel/libunwind : cannot preempt symbol (for various symbols)

[Ed Maste]

On 16 April 2017 at 04:10, Mark Millard  wrote:
> Context: amd64 FreeBSD -r316952 as a VirtualBox guest
> that was built using WITH_LLD_IS_LD= . ports -r438577.
>
> x11/xorg-minimal indirectly gets to devel/libunwind and
> devel/libunwind fails to build from source:
>
>
> --- Lperf-simple ---
> libtool: link: cc -O2 -pipe -g -fstack-protector -fno-strict-aliasing 
> -fexceptions -Wall -Wsign-compare -fstack-protector -o .libs/Lperf-simple 
> Lperf-simple.o  ../src/.libs/libunwind.so -lgcc -llzma -Wl,-rpath 
> -Wl,/usr/local/lib
> /usr/bin/ld: error: ./Gperf-simple.c:195: cannot preempt symbol 
> '_ULx86_64_init_local' defined in ../src/.libs/libunwind.so

The LLD ports exp-run identified the "cannot preempt symbol" issue as
being responsible for the largest number of failed or skipped ports.
You can find a description of the issue in LLVM PR 30960
(https://bugs.llvm.org//show_bug.cgi?id=30960). This is a tricky
issue, and one for which there's not a clear right answer, but is
arguably a problem that needs to be addressed in the individual pieces
of software (libunwind, openal-soft, etc.)

As a temporary workaround you can add CFLAGS+= -fPIC to the port's
Makefile, as in
https://github.com/emaste/freebsd-ports/commit/4857444b31ca546e29e221dce2a41092765e6062
___
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"

April 2017 update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

Here's a fresh update on LLVM's LLD linker in the base system,
referencing the plan originally posted at the beginning of 2016. This
work is primarily taking place on amd64 right now, and unless
otherwise noted these results apply to amd64.

First, the completed items:

> 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
> on the same architectures that use Clang (amd64, arm, arm64, i386).
> 3. Update lld again (most likely to a snapshot from upstream SVN) once
> it is able to link an unmodified FreeBSD kernel.

We now have LLD 4.0.0 in the tree and it can build all of
FreeBSD/amd64 kernel and world, and most of ports.

> 4. Modify the boot loader and kernel builds to avoid using features
> not implemented by lld.
> 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
> hardlink instead of /usr/bin/ld.bfd.

This became WITH_LLD_IS_LD for consistency with WITH_CLANG_IS_CC. It
also controls the bootstrap linker: adding WITH_LLD_IS_LD=yes to
src.conf means that the system will be built with LLD, and LLD will be
/usr/bin/ld in the resulting world.

This option is currently enabled by default on arm64 (only).


Next, where we are today:

> 6. Request ports exp-runs and issue a call for testing with 3rd party
> software. Fix issues found during this process.

This is in progress now, in PR 214864. There are currently 270 failing
ports and 963 skipped. The top ten failing ports (by # skipped) are
responsible for 808 of the skipped; addressing those should allow us
to build nearly 98% of the ports collection with LLD.

For reference, the top ten ports by # skipped are: audio/openal-soft
devel/libunwind editors/libreoffice lang/fpc print/gl2ps editors/emacs
lang/gcc6-aux lang/mono archivers/arj multimedia/libxine


Finally, future tasks:

> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.

While there is still no timeline set for this, it is already done for
arm64 (where we have no in-tree GNU ld available), and it is close to
being feasible for amd64. Further investigation is needed on i386 and
32-bit arm before moving forward here.
___
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: clang 4.0.0 with_lld_is_ld build

[Ed Maste]

On 8 February 2017 at 08:10, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
> On Tuesday, 07 February 2017 06:55:44 PM Ed Maste wrote:
>> On 7 February 2017 at 17:32, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
>> > Hey All,
>> >
>> > On a system with clang 4.0.0 already installed with lld as ld, I get the
>> > following error compiling the latest HEAD of projects/clang400-import when
>>
>> > WITH_LLD_IS_LD is set:
>> For now try setting WITHOUT_SYSTEM_COMPILER.
>
> buildworld now works when also setting WITHOUT_SYSTEM_COMPILER.

Thanks for the report and testing.

I've created https://reviews.freebsd.org/D9487 to set this
automatically for now, and later we'll need to add a FreeBSD-specific
version to the linker (or just share Clang's FREEBSD_CC_VERSION) and
compare the host / in-tree linker versions as well.
___
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: clang 4.0.0 with_lld_is_ld build

[Ed Maste]

On 7 February 2017 at 17:32, Shawn Webb  wrote:
> Hey All,
>
> On a system with clang 4.0.0 already installed with lld as ld, I get the
> following error compiling the latest HEAD of projects/clang400-import when
> WITH_LLD_IS_LD is set:

For now try setting WITHOUT_SYSTEM_COMPILER.
___
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: elfdump doesn't support .a files?

[Ed Maste]

On 17 January 2017 at 18:06, Ngie Cooper (yaneurabeya)
 wrote:
> Hi Ed,
> I tried running elfdump on a .a archive and it seems that elfdump 
> doesn’t support this (whereas objdump does). Is this expected?

Indeed it does not. We're still using FreeBSD's original elfdump. The
ELF Tool Chain project (which provides the objcopy, size, strings etc.
that we use) also imported FreeBSD's elfdump and made some
enhancements, including the ability to handle .a files.

Unfortunately there are a few changes which exist in FreeBSD's elfdump
but not ELF Tool Chain's version. We need to port those from FreeBSD
to ELF Tool Chain before we can migrate to ELF Tool Chain's elfdump.
___
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: clang on armv6 incorrectly emits call to sincos()

[Ed Maste]

On 11 January 2017 at 09:42, Jia-Shiun Li  wrote:
>
> Think this optimization should be turned off for armv6 from base
> clang/llvm, instead of patching individual ports or ports infrastructure.

You're right that this needs to be fixed in the compiler or the base
system, not individual ports. LLVM has a hasSinCos() and should not be
emitting the sincos libcall on platforms that do not have it. Would
you care to submit a PR for this?

-Ed
___
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: /usr/bin/ld.lld on powerpc64: produces a.out for which: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374

[Ed Maste]

On 11 January 2017 at 04:15, Mark Millard  wrote:
>
> # ./a.out
> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374
> Abort trap (core dumped)

Would you paste the output of `readelf -r a.out`?
___
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: I've submitted llvm bugzilla report 31538 on clang 3.9.1 not supporting the mfpmr and mtpmr instructions used in dev/hwpmc/hwpmc_e500.c

[Ed Maste]

On 4 January 2017 at 17:46, Mark Millard  wrote:
> I have submitted to llvm (matching up with FreeBSD bugzilla 214904):
>
> Bug 31538 - FreeBSD head (12) buildkernel based on clang FreeBSD's 3.9.1 
> stops for mfpmr and mtpmr instructions not being supported (used in 
> dev/hwpmc/hwpmc_e500.c )

Thank you.

> This report likely should be added to the depends on list in:
>
> Bug 25780 - [META] Using Clang as the FreeBSD/ppc system compiler

Agreed, I've added it there. Please feel free to add other issues you
find as blocking 25780; my intent is to have it track all of the
outstanding issues preventing a Clang-based "make buildworld
buildkernel" from succeeding on any ppc / ppc64.
___
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"

Update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

LLD developers have made much progress since my last update in August.

Two options used by the FreeBSD build, -dc and -r, are now
implemented. The issues with linker script expression support and
symbol version maps have been addressed. At this point an LLD built
from subversion can link a working FreeBSD-HEAD kernel and world
except for the boot loaders.

Here's an update on the plan I posted previously:

> 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
> on the same architectures that use Clang (amd64, arm, arm64, i386). I
> don't think there's a need for a WITH_LLD src.conf knob, but will add
> one if desired.

Now complete, with Dimitry's import of Clang 3.9.0 in r309124. There
is a WITH_/WITHOUT_LLD knob, which defaults to on for amd64 and arm64,
and off for all other architectures for now.

> 3. Update lld again (most likely to a snapshot from upstream SVN) once
> it is able to link an unmodified FreeBSD kernel.

This is now possible, but I'm going to wait for 3.9.0 to settle and
for the 3.9.1 update to happen first.

> 4. Modify the boot loader and kernel builds to avoid using features
> not implemented by lld.

There are a few outstanding issues in LLD that prevent linking the
boot loaders, but I'm hopeful that they will be addressed in the near
future.

> 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
> hardlink instead of /usr/bin/ld.bfd.

I've added this already, to allow for testing and experimentation, and
to provide some linker on arm64 image builds that can be used to
bootstrap a later GNU ld or LLVM lld. It defaults to on for arm64 and
off everywhere else. Note that the knob affects the installed linker
(/usr/bin/ld), but does not change the linker actually used to build
world and kernel, which remains GNU ld.

> 6. Request ports exp-runs and issue a call for testing with 3rd party
> software. Fix issues found during this process.

This can start happening any time now for LLD 3.9.0, either by setting
WITH_LLD_AS_LD with poudriere, or by using -fuse-ld=lld in LDFLAGS.

For example,
% cd /usr/src/bin/ls
% LDFLAGS=-fuse-ld=lld make

> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.

It's still too early to plan a switch by default.
___
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: Update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

On 1 August 2016 at 17:40, Ed Maste <ema...@freebsd.org> wrote:
> Over the past year or so I have been investigating the state of LLVM's
> lld linker for use in the FreeBSD base system, to see if it could be
> used as FreeBSD's system linker.

A quick update: most of the required changes have now made it into
LLD, and I'm currently testing with an unmodified upstream LLD. I can
now build world and kernel with an out-of-tree LLD (setting XLD=...),
when using these src.conf knobs:

WITHOUT_BINUTILS
WITHOUT_BINUTILS_BOOTSTRAP
WITHOUT_BOOT
WITHOUT_RESCUE

There's some upstream work in progress that may address the the boot
issue, or at least part of it. Rescue will still be left for later.

LLD 3.9 will be available once dim@'s clang390-import branch is merged
to FreeBSD HEAD. Although it's a bit older than the LLD HEAD snapshot
I've been using for my testing, it will facilitate further testing and
experimentation with LLD (e.g. testing ports builds).
___
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: Update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

On 1 August 2016 at 17:40, Ed Maste <ema...@freebsd.org> wrote:
> Over the past year or so I have been investigating the state of LLVM's
> lld linker for use in the FreeBSD base system, to see if it could be
> used as FreeBSD's system linker.
>
> ...
> There are a few features used by the FreeBSD base system that lld
> developers (intentionally) do not expect to implement, unless they're
> reasonably widely used in a variety of different software. If they're
> not implemented we can modify FreeBSD to avoid using them. I'm aware
> of:
>
> -N/--omagic, used by some boot loader components. We can achieve the
> same effect with a linker script.

Warner addressed this for x86 boot components in r305353. We still
have an issue: lld does not support -Ttext, but does have an
-image-base option to set the start address. It would be nice to
reconcile this and LLVM PR 30269 is open to track this for lld.

> -dc, used by the rescue build. As long as object files are built
> specifically for rescue we can probably use -fno-common instead.

I briefly tried to get the rescue build working with lld, but was not
successful and have just left it disabled in my tests. We can
investigate this later.

> -b binary to convert binary files into ELF objects, used by some
> device drivers in kernel and module builds. We can use
> objcopy(elfcopy) instead.

There is now an lld change in progress to add support for -b binary:
https://reviews.llvm.org/D24060
___
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: Time to enable partial relro

[Ed Maste]

On 26 August 2016 at 10:18, Warner Losh  wrote:
>
> So what's the summary of why we'd want to do that? What benefit does it bring?
> Sure, other folks do it, but why?

It's a relatively low cost technique to mitigate certain
vulnerabilities. rtld needs to write to some sections during load but
they don't need to be writeable after starting the program. relro
reorders the output sections so that they are grouped together, and
rtld remaps them read-only on start. This is often called "partial
relro." I don't know of any real downside to enabling it, other than
it could possibly break some strangely built third party software.
It's been enabled on other platforms for quite some time though and I
doubt we'd run into new issues.

It doesn't bring a huge benefit by itself though; the PLT is still
writeable. Adding "-z now" to the linker invocation produces "full
relro" which makes the PLT read-only too. It has a negative impact on
process start-up time though.
___
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: Update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

For some reason Warner's email didn't make it to me, but I spotted it
in the list archive.

Warner writes:
> On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste  wrote:
>> -N/--omagic, used by some boot loader components. We can achieve the
>> same effect with a linker script.
>
> Agreed. Or objcopy even.

I'm not sure objcopy (alone) can do what we need, because -N also
turns off page alignment for .data. But either way I don't think will
be hard to work around.

>> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
>> on the same architectures that use Clang (amd64, arm, arm64, i386). I
>> don't think there's a need for a WITH_LLD src.conf knob, but will add
>> one if desired.
>
> I'm on the fence here. Since it is ld.lld, I'm not sure there's much value
> here so long as it falls under one of the clang WITH/WITHOUT symbols.

Yeah, I planned to bundle it with some knob that already controls
lld's dependencies.

>> 4. Modify the boot loader and kernel builds to avoid using features
>> not implemented by lld.
>
> This can be done in parallel starting now. I may take a stab at the boot
> loader bits since I think that will be easy.

Sounds good. We want to have it done by that point in the list but
you're absolutely right that we don't need to wait to start working on
it. If it hasn't happened by the time we finish up the earlier tasks
I'll look at it then.

>> 6. Request ports exp-runs and issue a call for testing with 3rd party
>> software. Fix issues found during this process.
>
> Experience suggests this may be the long poll :)

Indeed, and that's a big part of my motivation for trying to make lld
more readily available as early as possible, even if we're still
waiting on some required features.

>> 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
>> architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.
>
> For the WITH/WITHOUT things, this is just a matter of changing the default
> MK_foo setting, right?

Right.

> OK. How does this square up against the gcc 4.2 removal timelines and
> plans? Once gcc is gone, we'll have to use an external toolchain anyway
> to build mips at least (though clang is close, it isn't there yet despite Sean
> Bruno's wonderful work).

I'm intentionally trying to keep lld decoupled from GCC 4.2 removal,
and don't think it should directly enable (or prevent) any progress
there. I don't yet have a good handle on GCC 4.2 removal timelines but
will definitely pay attention to progress there and potential
interaction with lld work.

> What's the timeline for all this stuff, do you think?

Significant progress is being made in lld at the moment. I don't want
to speak for others who are doing much of the work upstream, but I
would not be surprised if within two months we can build a working
world and kernel with lld (modulo rescue and boot loader fixes). If
testing and ports exp-runs go well I'd guess we could make it the
default in head a couple of months after that.

> Generally, I like it though. My concerns are mostly with ports and gcc plans.
> Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan
> for both before we get out the axes. Note this is purely a timing argument,
> not whether to get them out, just when :)

Yes, fully agree. I want to have lld available as soon as is feasible,
but have no intention of trying to remove old GNU ld or GCC 4.2 until
a viable path forward exists for all architectures.
___
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"

Update on using LLVM's lld linker in the FreeBSD base system

[Ed Maste]

Over the past year or so I have been investigating the state of LLVM's
lld linker for use in the FreeBSD base system, to see if it could be
used as FreeBSD's system linker.

Why do we need a new linker? Compared to the GNU ld 2.17.50 that we
have in the FreeBSD base system, lld will bring:

* AArch64 (arm64) support
* Link Time Optimization (LTO)
* New ABI support
* Other linker optimization
* Much faster link times
* Maintained code base

I've posted a couple of status updates on the LLVM mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html
http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html

Since the last update in March several lld developers have implemented
much of the missing functionality. The main blockers were symbol
version support and expression evaluation in the linker script
expression parser. Both are now nearly complete.

There are a few features used by the FreeBSD base system that lld
developers (intentionally) do not expect to implement, unless they're
reasonably widely used in a variety of different software. If they're
not implemented we can modify FreeBSD to avoid using them. I'm aware
of:

-N/--omagic, used by some boot loader components. We can achieve the
same effect with a linker script.

-dc, used by the rescue build. As long as object files are built
specifically for rescue we can probably use -fno-common instead.

-r binary to convert binary files into ELF objects, used by some
device drivers in kernel and module builds. We can use
objcopy(elfcopy) instead.

Davide Italiano and Rafael Ávila de Espíndola presented an update on
the state of lld at BSDCan 2016:
https://www.bsdcan.org/2016/schedule/events/656.en.html

At this point I'm confident that lld is going to be a viable linker
for the FreeBSD base system, and am beginning to plan its import.

I expect the process will look something like this:

1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on.
2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld
on the same architectures that use Clang (amd64, arm, arm64, i386). I
don't think there's a need for a WITH_LLD src.conf knob, but will add
one if desired.
3. Update lld again (most likely to a snapshot from upstream SVN) once
it is able to link an unmodified FreeBSD kernel.
4. Modify the boot loader and kernel builds to avoid using features
not implemented by lld.
5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld
hardlink instead of /usr/bin/ld.bfd.
6. Request ports exp-runs and issue a call for testing with 3rd party
software. Fix issues found during this process.
7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using
architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld.

There is (some) support for mips and powerpc in lld, but I'm not sure
how well tested it is. RISC-V is not yet supported but there is a
desire to have a full LLVM-based RISC-V toolchain. I'm not aware of
any plan with respect to sparc64 in lld. In any case, I do not plan to
address these architectures in the initial lld work. In the near term
they will continue to use GNU ld 2.17.50.

I'm interested in your comments, questions and concerns about this plan.
___
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: clang confuses kgdb on static symbols

[Ed Maste]

On 20 October 2015 at 13:27, John Baldwin  wrote:
>
> If '-gdwarf-4' works then you can just set that in the DEBUG makeoptions as a
> test, otherwise try hacking kern.mk to disable this bit:
>
> #
> # Add -gdwarf-2 when compiling -g. The default starting in clang v3.4
> # and gcc 4.8 is to generate DWARF version 4. However, our tools don't
> # cope well with DWARF 4, so force it to genereate DWARF2, which they
> # understand. Do this unconditionally as it is harmless when not needed,
> # but critical for these newer versions.
> #
> .if ${CFLAGS:M-g} != "" && ${CFLAGS:M-gdwarf*} == ""
> CFLAGS+=-gdwarf-2
> .endif

Note that Clang defaults to DWARF 2 on FreeBSD, so removing the
override in kern.mk isn't sufficient.

>From contrib/llvm/tools/clang/lib/Driver/Tools.cpp:
else if (!A->getOption().matches(options::OPT_g0) &&
 !A->getOption().matches(options::OPT_ggdb0)) {
  // Default is dwarf-2 for Darwin, OpenBSD, FreeBSD and Solaris.
  const llvm::Triple  = getToolChain().getTriple();
  if (Triple.isOSDarwin() || Triple.getOS() == llvm::Triple::OpenBSD ||
  Triple.getOS() == llvm::Triple::FreeBSD ||
  Triple.getOS() == llvm::Triple::Solaris)
CmdArgs.push_back("-gdwarf-2");
  else
CmdArgs.push_back("-g");
}

It may be time for us to remove this default from Clang.
___
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: clang confuses kgdb on static symbols

[Ed Maste]

On 20 October 2015 at 16:30, Konstantin Belousov  wrote:
>
> Wouldn't this cause another outburst of 'works by default' discussion
> from some other place ?

Ok, I'll hold off on this until we make progress on the gdb retirement plan.
___
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: clang confuses kgdb on static symbols

[Ed Maste]

On 20 October 2015 at 17:18, Warner Losh <i...@bsdimp.com> wrote:
>
>> On Oct 20, 2015, at 3:07 PM, Ed Maste <ema...@freebsd.org> wrote:
>>
>> On 20 October 2015 at 16:30, Konstantin Belousov <kostik...@gmail.com> wrote:
>>>
>>> Wouldn't this cause another outburst of 'works by default' discussion
>>> from some other place ?
>>
>> Ok, I'll hold off on this until we make progress on the gdb retirement plan.
>
> Have the issues with ctfconvert been fixed that caused us to go
> to dwarf2 by default?

It should be - kaiw imported a new libdwarf when this first came up to
pick up new DWARF support. It had a few outstanding issues, but those
should now be fixed with my elftoolchain update in r276371 last
December.

Testing that support is of course one of the prerequisites for
changing the default back to DWARF 4.
___
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: clang confuses kgdb on static symbols

[Ed Maste]

On 20 October 2015 at 15:55, Konstantin Belousov  wrote:
>
> We cannot stop generating dwarf-2 until in tree gdb and kgdb are substituted
> by a working replacement.

Note that I'm only suggesting removing the baked-in default from
Clang, not the setting in kern.mk.
___
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"

[Differential] [Request, 25 lines] D3237: Fix ar default deterministic mode for -x

[emaste (Ed Maste)]

emaste created this revision.
emaste added reviewers: jhibbits, bapt, brooks.
emaste added subscribers: freebsd-toolchain-list, jhibbits.

REVISION SUMMARY
  Reported by: @jhibbits

REVISION DETAIL
  https://reviews.freebsd.org/D3237

AFFECTED FILES
  usr.bin/ar/ar.c

CHANGE DETAILS
  diff --git a/usr.bin/ar/ar.c b/usr.bin/ar/ar.c
  --- a/usr.bin/ar/ar.c
  +++ b/usr.bin/ar/ar.c
  @@ -101,11 +101,12 @@
char*p;
size_t   len;
int  i, opt;
  + int  Dflag, Uflag;
   
bsdar = bsdar_storage;
memset(bsdar, 0, sizeof(*bsdar));
  - /* Enable deterministic mode by default. */
  - bsdar-options |= AR_D;
  + Dflag = 0;
  + Uflag = 0;
   
if ((bsdar-progname = getprogname()) == NULL)
bsdar-progname = ar;
  @@ -122,10 +123,12 @@
/* Ignored. */
break;
case 'D':
  - bsdar-options |= AR_D;
  + Dflag = 1;
  + Uflag = 0;
break;
case 'U':
  - bsdar-options = ~AR_D;
  + Uflag = 1;
  + Dflag = 0;
break;
case 'V':
ranlib_version();
  @@ -182,7 +185,8 @@
set_mode(bsdar, opt);
break;
case 'D':
  - bsdar-options |= AR_D;
  + Dflag = 1;
  + Uflag = 0;
break;
case 'f':
case 'T':
  @@ -222,7 +226,8 @@
set_mode(bsdar, opt);
break;
case 'U':
  - bsdar-options = ~AR_D;
  + Uflag = 1;
  + Dflag = 0;
break;
case 'u':
bsdar-options |= AR_U;
  @@ -275,16 +280,22 @@
argv++;
}
   
  + /* Set determinstic mode for -D, and by default without -U. */
  + if (Dflag || (Uflag == 0  (bsdar-mode == 'q' || bsdar-mode == 'r')))
  + bsdar-options |= AR_D;
  +
if (bsdar-options  AR_A)
only_mode(bsdar, -a, mqr);
if (bsdar-options  AR_B)
only_mode(bsdar, -b, mqr);
if (bsdar-options  AR_C)
only_mode(bsdar, -c, qr);
if (bsdar-options  AR_CC)
only_mode(bsdar, -C, x);
  - if (bsdar-options  AR_D)
  + if (Dflag)
only_mode(bsdar, -D, qr);
  + if (Uflag)
  + only_mode(bsdar, -U, qr);
if (bsdar-options  AR_O)
only_mode(bsdar, -o, x);
if (bsdar-options  AR_SS)

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, jhibbits, bapt, brooks
Cc: jhibbits, freebsd-toolchain-list
diff --git a/usr.bin/ar/ar.c b/usr.bin/ar/ar.c
--- a/usr.bin/ar/ar.c
+++ b/usr.bin/ar/ar.c
@@ -101,11 +101,12 @@
 	char		*p;
 	size_t		 len;
 	int		 i, opt;
+	int		 Dflag, Uflag;
 
 	bsdar = bsdar_storage;
 	memset(bsdar, 0, sizeof(*bsdar));
-	/* Enable deterministic mode by default. */
-	bsdar-options |= AR_D;
+	Dflag = 0;
+	Uflag = 0;
 
 	if ((bsdar-progname = getprogname()) == NULL)
 		bsdar-progname = ar;
@@ -122,10 +123,12 @@
 /* Ignored. */
 break;
 			case 'D':
-bsdar-options |= AR_D;
+Dflag = 1;
+Uflag = 0;
 break;
 			case 'U':
-bsdar-options = ~AR_D;
+Uflag = 1;
+Dflag = 0;
 break;
 			case 'V':
 ranlib_version();
@@ -182,7 +185,8 @@
 			set_mode(bsdar, opt);
 			break;
 		case 'D':
-			bsdar-options |= AR_D;
+			Dflag = 1;
+			Uflag = 0;
 			break;
 		case 'f':
 		case 'T':
@@ -222,7 +226,8 @@
 			set_mode(bsdar, opt);
 			break;
 		case 'U':
-			bsdar-options = ~AR_D;
+			Uflag = 1;
+			Dflag = 0;
 			break;
 		case 'u':
 			bsdar-options |= AR_U;
@@ -275,16 +280,22 @@
 		argv++;
 	}
 
+	/* Set determinstic mode for -D, and by default without -U. */
+	if (Dflag || (Uflag == 0  (bsdar-mode == 'q' || bsdar-mode == 'r')))
+		bsdar-options |= AR_D;
+
 	if (bsdar-options  AR_A)
 		only_mode(bsdar, -a, mqr);
 	if (bsdar-options  AR_B)
 		only_mode(bsdar, -b, mqr);
 	if (bsdar-options  AR_C)
 		only_mode(bsdar, -c, qr);
 	if (bsdar-options  AR_CC)
 		only_mode(bsdar, -C, x);
-	if (bsdar-options  AR_D)
+	if (Dflag)
 		only_mode(bsdar, -D, qr);
+	if (Uflag)
+		only_mode(bsdar, -U, qr);
 	if (bsdar-options  AR_O)
 		only_mode(bsdar, -o, x);
 	if (bsdar-options  AR_SS)

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

[Differential] [Request, 2, 362 lines] D3238: Remove old GNU Binutils tools now provided by ELF Tool Chain

[emaste (Ed Maste)]

emaste created this revision.
emaste added reviewers: bapt, brooks, imp.
emaste added a subscriber: freebsd-toolchain-list.

REVISION SUMMARY
  Posting for comment, review and testing.

REVISION DETAIL
  https://reviews.freebsd.org/D3238

AFFECTED FILES
  UPDATING
  gnu/usr.bin/binutils/Makefile
  gnu/usr.bin/binutils/addr2line/Makefile
  gnu/usr.bin/binutils/addr2line/Makefile.depend
  gnu/usr.bin/binutils/addr2line/addr2line.1
  gnu/usr.bin/binutils/ar/Makefile.depend
  gnu/usr.bin/binutils/nm/Makefile
  gnu/usr.bin/binutils/nm/Makefile.depend
  gnu/usr.bin/binutils/nm/nm.1
  gnu/usr.bin/binutils/ranlib/Makefile.depend
  gnu/usr.bin/binutils/readelf/Makefile
  gnu/usr.bin/binutils/readelf/Makefile.depend
  gnu/usr.bin/binutils/readelf/readelf.1
  gnu/usr.bin/binutils/size/Makefile
  gnu/usr.bin/binutils/size/Makefile.depend
  gnu/usr.bin/binutils/size/size.1
  gnu/usr.bin/binutils/strings/Makefile
  gnu/usr.bin/binutils/strings/Makefile.depend
  gnu/usr.bin/binutils/strings/strings.1
  gnu/usr.bin/binutils/strip/Makefile
  gnu/usr.bin/binutils/strip/Makefile.depend
  gnu/usr.bin/binutils/strip/strip.1
  gnu/usr.bin/cc/Makefile
  gnu/usr.bin/cc/c++filt/Makefile
  gnu/usr.bin/cc/c++filt/Makefile.depend
  tools/build/mk/OptionalObsoleteFiles.inc
  tools/build/options/WITHOUT_BINUTILS
  tools/build/options/WITHOUT_ELFTOOLCHAIN_TOOLS

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, bapt, brooks, imp
Cc: freebsd-toolchain-list
diff --git a/tools/build/options/WITHOUT_ELFTOOLCHAIN_TOOLS b/tools/build/options/WITHOUT_ELFTOOLCHAIN_TOOLS
--- a/tools/build/options/WITHOUT_ELFTOOLCHAIN_TOOLS
+++ b/tools/build/options/WITHOUT_ELFTOOLCHAIN_TOOLS
@@ -1,11 +1,10 @@
 .\ $FreeBSD$
-Set to use
+Set to avoid building ELF Tool Chain tools
 .Xr addr2line 1 ,
 .Xr c++filt 1 ,
 .Xr nm 1 ,
 .Xr readelf 1 ,
 .Xr size 1 ,
 .Xr strings 1 ,
 and
-.Xr strip 1
-from GNU binutils instead of the ELF Tool Chain project.
+.Xr strip 1 .
diff --git a/tools/build/options/WITHOUT_BINUTILS b/tools/build/options/WITHOUT_BINUTILS
--- a/tools/build/options/WITHOUT_BINUTILS
+++ b/tools/build/options/WITHOUT_BINUTILS
@@ -1,5 +1,4 @@
 .\ $FreeBSD$
-Set to not build or install binutils (as, c++-filt,
-ld, nm, objcopy, objdump, readelf, size and strip) as part
+Set to not build or install binutils (as, ld, objcopy, and objdump ) as part
 of the normal system build.
 The resulting system cannot build programs from source.
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc b/tools/build/mk/OptionalObsoleteFiles.inc
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -1025,9 +1025,6 @@
 .if ${MK_CXX} == no
 OLD_FILES+=usr/bin/CC
 OLD_FILES+=usr/bin/c++
-.if ${MK_ELFTOOLCHAIN_TOOLS} == no
-OLD_FILES+=usr/bin/c++filt
-.endif
 OLD_FILES+=usr/bin/g++
 OLD_FILES+=usr/libexec/cc1plus
 .endif
@@ -1656,14 +1653,16 @@
 OLD_FILES+=usr/share/man/man1/elfcopy.1.gz
 .endif
 
-.if ${MK_ELFTOOLCHAIN_TOOLS} == no  ${MK_BINUTILS} == no
+.if ${MK_ELFTOOLCHAIN_TOOLS} == no
 OLD_FILES+=usr/bin/addr2line
+OLD_FILES+=usr/bin/c++filt
 OLD_FILES+=usr/bin/nm
 OLD_FILES+=usr/bin/readelf
 OLD_FILES+=usr/bin/size
 OLD_FILES+=usr/bin/strings
 OLD_FILES+=usr/bin/strip
 OLD_FILES+=usr/share/man/man1/addr2line.1.gz
+OLD_FILES+=usr/share/man/man1/c++filt.1.gz
 OLD_FILES+=usr/share/man/man1/nm.1.gz
 OLD_FILES+=usr/share/man/man1/readelf.1.gz
 OLD_FILES+=usr/share/man/man1/size.1.gz
@@ -1753,9 +1752,6 @@
 .endif
 
 .if ${MK_GCC} == no
-.if ${MK_ELFTOOLCHAIN_TOOLS} == no
-OLD_FILES+=usr/bin/c++filt
-.endif
 OLD_FILES+=usr/bin/g++
 OLD_FILES+=usr/bin/gcc
 OLD_FILES+=usr/bin/gcov
diff --git a/gnu/usr.bin/cc/c++filt/Makefile.depend b/gnu/usr.bin/cc/c++filt/Makefile.depend
deleted file mode 100644
--- a/gnu/usr.bin/cc/c++filt/Makefile.depend
+++ /dev/null
@@ -1,23 +0,0 @@
-# $FreeBSD$
-# Autogenerated - do NOT edit!
-
-DEP_RELDIR := ${_PARSEDIR:S,${SRCTOP}/,,}
-
-DIRDEPS = \
-	gnu/lib/csu \
-	gnu/lib/libgcc \
-	gnu/usr.bin/cc/cc_tools \
-	gnu/usr.bin/cc/libiberty \
-	include \
-	include/xlocale \
-	lib/${CSU_DIR} \
-	lib/libc \
-	lib/libc_nonshared \
-	lib/libcompiler_rt \
-
-
-.include dirdeps.mk
-
-.if ${DEP_RELDIR} == ${_DEP_RELDIR}
-# local dependencies - needed for -jN in clean tree
-.endif
diff --git a/gnu/usr.bin/cc/c++filt/Makefile b/gnu/usr.bin/cc/c++filt/Makefile
deleted file mode 100644
--- a/gnu/usr.bin/cc/c++filt/Makefile
+++ /dev/null
@@ -1,19 +0,0 @@
-# $FreeBSD$
-
-MAN=
-.include bsd.own.mk
-
-.include ../Makefile.inc
-.include ../Makefile.fe
-
-.PATH: ${GCCLIB}/libiberty
-
-PROG=	c++filt
-SRCS=	cp-demangle.c
-
-CFLAGS+= -DSTANDALONE_DEMANGLER -DVERSION=\$(GCC_VERSION)\
-
-DPADD=	${LIBIBERTY}
-LDADD=	${LIBIBERTY}
-
-.include bsd.prog.mk
diff --git a/gnu/usr.bin/cc/Makefile b/gnu/usr.bin/cc/Makefile
--- a/gnu/usr.bin/cc/Makefile
+++ b/gnu/usr.bin/cc/Makefile
@@ -13,9 +13,6 @@
 
 .if ${MK_CXX} != no
 SUBDIR+= cc1plus c++
-.if ${MK_ELFTOOLCHAIN_TOOLS} == no
-SUBDIR+= c++filt
-.endif
 

[Differential] [Closed] D3175: ar: add -U (unique) option to disable -D (deterministic) mode

[emaste (Ed Maste)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rS285844: ar: add -U (unique) option to disable -D 
(deterministic) mode (authored by emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D3175?vs=7235id=7268#toc

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D3175?vs=7235id=7268

REVISION DETAIL
  https://reviews.freebsd.org/D3175

AFFECTED FILES
  head/usr.bin/ar/ar.1
  head/usr.bin/ar/ar.c

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, imp, brooks, bapt
Cc: freebsd-toolchain-list
diff --git a/head/usr.bin/ar/ar.1 b/head/usr.bin/ar/ar.1
--- a/head/usr.bin/ar/ar.1
+++ b/head/usr.bin/ar/ar.1
@@ -23,7 +23,7 @@
 .\
 .\ $FreeBSD$
 .\
-.Dd December 22, 2011
+.Dd July 24, 2015
 .Dt AR 1
 .Os
 .Sh NAME
@@ -66,6 +66,7 @@
 .Op Fl D
 .Op Fl f
 .Op Fl s | Fl S
+.Op Fl U
 .Op Fl v
 .Op Fl z
 .Ar archive
@@ -82,6 +83,7 @@
 .Op Fl j
 .Op Fl s | Fl S
 .Op Fl u
+.Op Fl U
 .Op Fl v
 .Op Fl z
 .Ar archive
@@ -112,6 +114,7 @@
 .Fl M
 .Nm ranlib
 .Op Fl D
+.Op Fl U
 .Ar archive ...
 .Sh DESCRIPTION
 The
@@ -207,6 +210,11 @@
 .Ar .
 This ensures that checksums on the resulting archives are reproducible
 when member contents are identical.
+If multiple
+.Fl D
+and
+.Fl U
+options are specified on the command line, the final one takes precedence.
 .It Fl f
 Synonymous with option
 .Fl T .
@@ -316,6 +324,19 @@
 .Ar
 will be extracted only if they are newer than the corresponding
 files in the file system.
+.It Fl U
+When used in combination with the
+.Fl r
+or
+.Fl q
+option, insert the real mtime, uid and gid, and file mode values
+from the members named by arguments
+.Ar .
+If multiple
+.Fl D
+and
+.Fl U
+options are specified on the command line, the final one takes precedence.
 .It Fl v
 Provide verbose output.
 When used with the
diff --git a/head/usr.bin/ar/ar.c b/head/usr.bin/ar/ar.c
--- a/head/usr.bin/ar/ar.c
+++ b/head/usr.bin/ar/ar.c
@@ -113,15 +113,18 @@
 	len = strlen(bsdar-progname);
 	if (len = strlen(ranlib) 
 	strcmp(bsdar-progname + len - strlen(ranlib), ranlib) == 0) {
-		while ((opt = getopt_long(argc, argv, tDV, longopts,
+		while ((opt = getopt_long(argc, argv, tDUV, longopts,
 		NULL)) != -1) {
 			switch(opt) {
 			case 't':
 /* Ignored. */
 break;
 			case 'D':
 bsdar-options |= AR_D;
 break;
+			case 'U':
+bsdar-options = ~AR_D;
+break;
 			case 'V':
 ranlib_version();
 break;
@@ -157,7 +160,7 @@
 		}
 	}
 
-	while ((opt = getopt_long(argc, argv, abCcdDfijlMmopqrSsTtuVvxz,
+	while ((opt = getopt_long(argc, argv, abCcdDfijlMmopqrSsTtUuVvxz,
 	longopts, NULL)) != -1) {
 		switch(opt) {
 		case 'a':
@@ -216,6 +219,9 @@
 		case 't':
 			set_mode(bsdar, opt);
 			break;
+		case 'U':
+			bsdar-options = ~AR_D;
+			break;
 		case 'u':
 			bsdar-options |= AR_U;
 			break;
@@ -364,9 +370,9 @@
 	(void)fprintf(stderr, \tar -m [-Tjsvz] archive file ...\n);
 	(void)fprintf(stderr, \tar -m [-Tabijsvz] position archive file ...\n);
 	(void)fprintf(stderr, \tar -p [-Tv] archive [file ...]\n);
-	(void)fprintf(stderr, \tar -q [-TcDjsvz] archive file ...\n);
-	(void)fprintf(stderr, \tar -r [-TcDjsuvz] archive file ...\n);
-	(void)fprintf(stderr, \tar -r [-TabcDijsuvz] position archive file ...\n);
+	(void)fprintf(stderr, \tar -q [-TcDjsUvz] archive file ...\n);
+	(void)fprintf(stderr, \tar -r [-TcDjsUuvz] archive file ...\n);
+	(void)fprintf(stderr, \tar -r [-TabcDijsUuvz] position archive file ...\n);
 	(void)fprintf(stderr, \tar -s [-jz] archive\n);
 	(void)fprintf(stderr, \tar -t [-Tv] archive [file ...]\n);
 	(void)fprintf(stderr, \tar -x [-CTouv] archive [file ...]\n);
@@ -378,7 +384,7 @@
 ranlib_usage(void)
 {
 
-	(void)fprintf(stderr, usage:	ranlib [-t] archive ...\n);
+	(void)fprintf(stderr, usage:	ranlib [-DtU] archive ...\n);
 	(void)fprintf(stderr, \tranlib -V\n);
 	exit(EX_USAGE);
 }

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

[Differential] [Closed] D2338: readelf: avoid division by zero for files with invalid sh_entsize

[emaste (Ed Maste)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rS285845: readelf: avoid division by zero on section entry 
size (authored by emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D2338?vs=7069id=7269#toc

REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D2338?vs=7069id=7269

REVISION DETAIL
  https://reviews.freebsd.org/D2338

AFFECTED FILES
  head/contrib/elftoolchain/readelf/readelf.c

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks
Cc: brooks, freebsd-toolchain-list
diff --git a/head/contrib/elftoolchain/readelf/readelf.c b/head/contrib/elftoolchain/readelf/readelf.c
--- a/head/contrib/elftoolchain/readelf/readelf.c
+++ b/head/contrib/elftoolchain/readelf/readelf.c
@@ -27,6 +27,7 @@
 #include sys/param.h
 #include sys/queue.h
 #include ar.h
+#include assert.h
 #include ctype.h
 #include dwarf.h
 #include err.h
@@ -314,6 +315,7 @@
 static const char *dwarf_regname(struct readelf *re, unsigned int num);
 static struct dumpop *find_dumpop(struct readelf *re, size_t si,
 const char *sn, int op, int t);
+static int get_ent_count(struct section *s, int *ent_count);
 static char *get_regoff_str(struct readelf *re, Dwarf_Half reg,
 Dwarf_Addr off);
 static const char *get_string(struct readelf *re, int strtab, size_t off);
@@ -2901,6 +2903,24 @@
 #undef	ST_CTL
 }
 
+/*
+ * Return number of entries in the given section. We'd prefer ent_count be a
+ * size_t *, but libelf APIs already use int for section indices.
+ */
+static int
+get_ent_count(struct section *s, int *ent_count)
+{
+	if (s-entsize == 0) {
+		warnx(section %s has entry size 0, s-name);
+		return (0);
+	} else if (s-sz / s-entsize  INT_MAX) {
+		warnx(section %s has invalid section count, s-name);
+		return (0);
+	}
+	*ent_count = (int)(s-sz / s-entsize);
+	return (1);
+}
+
 static void
 dump_dynamic(struct readelf *re)
 {
@@ -2929,8 +2949,8 @@
 
 		/* Determine the actual number of table entries. */
 		nentries = 0;
-		jmax = (int) (s-sz / s-entsize);
-
+		if (!get_ent_count(s, jmax))
+			continue;
 		for (j = 0; j  jmax; j++) {
 			if (gelf_getdyn(d, j, dyn) != dyn) {
 warnx(gelf_getdyn failed: %s,
@@ -3176,7 +3196,9 @@
 		else
 			printf(%-12s %-12s %-19s %-16s %s\n, REL_HDR);
 	}
-	len = d-d_size / s-entsize;
+	assert(d-d_size == s-sz);
+	if (!get_ent_count(s, len))
+		return;
 	for (i = 0; i  len; i++) {
 		if (gelf_getrel(d, i, r) != r) {
 			warnx(gelf_getrel failed: %s, elf_errmsg(-1));
@@ -3232,7 +3254,9 @@
 		else
 			printf(%-12s %-12s %-19s %-16s %s\n, RELA_HDR);
 	}
-	len = d-d_size / s-entsize;
+	assert(d-d_size == s-sz);
+	if (!get_ent_count(s, len))
+		return;
 	for (i = 0; i  len; i++) {
 		if (gelf_getrela(d, i, r) != r) {
 			warnx(gelf_getrel failed: %s, elf_errmsg(-1));
@@ -3297,7 +3321,7 @@
 	Elf_Data *d;
 	GElf_Sym sym;
 	const char *name;
-	int elferr, stab, j;
+	int elferr, stab, j, len;
 
 	s = re-sl[i];
 	stab = s-link;
@@ -3310,12 +3334,14 @@
 	}
 	if (d-d_size = 0)
 		return;
+	if (!get_ent_count(s, len))
+		return;
 	printf(Symbol table (%s), s-name);
-	printf( contains %ju entries:\n, s-sz / s-entsize);
+	printf( contains %d entries:\n, len);
 	printf(%7s%9s%14s%5s%8s%6s%9s%5s\n, Num:, Value, Size, Type,
 	Bind, Vis, Ndx, Name);
 
-	for (j = 0; (uint64_t)j  s-sz / s-entsize; j++) {
+	for (j = 0; j  len; j++) {
 		if (gelf_getsym(d, j, sym) != sym) {
 			warnx(gelf_getsym failed: %s, elf_errmsg(-1));
 			continue;
@@ -3353,7 +3379,7 @@
 	Elf_Data *d;
 	struct section *s;
 	uint64_t dyn_off;
-	int elferr, i;
+	int elferr, i, len;
 
 	/*
 	 * If -D is specified, only dump the symbol table specified by
@@ -3378,8 +3404,10 @@
 		}
 		if (d-d_size = 0)
 			return;
+		if (!get_ent_count(s, len))
+			return;
 
-		for (i = 0; (uint64_t)i  s-sz / s-entsize; i++) {
+		for (i = 0; i  len; i++) {
 			if (gelf_getdyn(d, i, dyn) != dyn) {
 warnx(gelf_getdyn failed: %s, elf_errmsg(-1));
 continue;
@@ -3567,7 +3595,8 @@
 	maskwords = buf[2];
 	buf += 4;
 	ds = re-sl[s-link];
-	dynsymcount = ds-sz / ds-entsize;
+	if (!get_ent_count(ds, dynsymcount))
+		return;
 	nchain = dynsymcount - symndx;
 	if (d-d_size != 4 * sizeof(uint32_t) + maskwords *
 	(re-ec == ELFCLASS32 ? sizeof(uint32_t) : sizeof(uint64_t)) +
@@ -3996,7 +4025,7 @@
 	char tbuf[20];
 	Elf_Data *d;
 	Elf_Lib *lib;
-	int i, j, k, elferr, first;
+	int i, j, k, elferr, first, len;
 
 	for (i = 0; (size_t) i  re-shnum; i++) {
 		s = re-sl[i];
@@ -4013,8 +4042,10 @@
 		if (d-d_size = 0)
 			continue;
 		lib = d-d_buf;
+		if (!get_ent_count(s, len))
+			continue;
 		printf(\nLibrary list section '%s' , s-name);
-		printf(contains %ju entries:\n, s-sz / s-entsize);
+		printf(contains %d entries:\n, len);
 		printf(%12s%24s%18s%10s%6s\n, Library, Time Stamp,
 		Checksum, Version, Flags);
 		for (j = 0; (uint64_t) j  s-sz / s-entsize; j++) {
@@ -4399,7 +4430,7 @@
 dump_mips_reginfo(struct readelf 

[Differential] [Request, 2 lines] D3190: ar: enable deterministic mode by default

[emaste (Ed Maste)]

emaste created this revision.
emaste added reviewers: bapt, brooks.
emaste added a subscriber: freebsd-toolchain-list.

REVISION SUMMARY
  Ar cannot handle UIDs with more than 6 digits, and there's little value in 
storing the mtime, uid, gid and mode anyhow.  Turn on deterministic (-D) mode 
by default; it can be disabled by the user with -U.
  
  PR: 196929
  Relnotes:   Yes
  Sponsored by:   The FreeBSD Foundation

REVISION DETAIL
  https://reviews.freebsd.org/D3190

AFFECTED FILES
  usr.bin/ar/ar.c

CHANGE DETAILS
  diff --git a/usr.bin/ar/ar.c b/usr.bin/ar/ar.c
  --- a/usr.bin/ar/ar.c
  +++ b/usr.bin/ar/ar.c
  @@ -104,6 +104,8 @@
   
bsdar = bsdar_storage;
memset(bsdar, 0, sizeof(*bsdar));
  + /* Enable deterministic mode by default. */
  + bsdar-options |= AR_D;
   
if ((bsdar-progname = getprogname()) == NULL)
bsdar-progname = ar;

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, bapt, brooks
Cc: freebsd-toolchain-list
diff --git a/usr.bin/ar/ar.c b/usr.bin/ar/ar.c
--- a/usr.bin/ar/ar.c
+++ b/usr.bin/ar/ar.c
@@ -104,6 +104,8 @@
 
 	bsdar = bsdar_storage;
 	memset(bsdar, 0, sizeof(*bsdar));
+	/* Enable deterministic mode by default. */
+	bsdar-options |= AR_D;
 
 	if ((bsdar-progname = getprogname()) == NULL)
 		bsdar-progname = ar;

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

[Differential] [Updated, 3 lines] D3190: ar: enable deterministic mode by default

[emaste (Ed Maste)]

emaste updated this revision to Diff 7272.
emaste added a comment.

Add note of -D default in man page.


CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D3190?vs=7271id=7272

REVISION DETAIL
  https://reviews.freebsd.org/D3190

AFFECTED FILES
  usr.bin/ar/ar.1
  usr.bin/ar/ar.c

CHANGE DETAILS
  diff --git a/usr.bin/ar/ar.c b/usr.bin/ar/ar.c
  --- a/usr.bin/ar/ar.c
  +++ b/usr.bin/ar/ar.c
  @@ -104,6 +104,8 @@
   
bsdar = bsdar_storage;
memset(bsdar, 0, sizeof(*bsdar));
  + /* Enable deterministic mode by default. */
  + bsdar-options |= AR_D;
   
if ((bsdar-progname = getprogname()) == NULL)
bsdar-progname = ar;
  diff --git a/usr.bin/ar/ar.1 b/usr.bin/ar/ar.1
  --- a/usr.bin/ar/ar.1
  +++ b/usr.bin/ar/ar.1
  @@ -210,6 +210,7 @@
   .Ar .
   This ensures that checksums on the resulting archives are reproducible
   when member contents are identical.
  +This option is enabled by default.
   If multiple
   .Fl D
   and

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, bapt, brooks
Cc: freebsd-toolchain-list
diff --git a/usr.bin/ar/ar.c b/usr.bin/ar/ar.c
--- a/usr.bin/ar/ar.c
+++ b/usr.bin/ar/ar.c
@@ -104,6 +104,8 @@
 
 	bsdar = bsdar_storage;
 	memset(bsdar, 0, sizeof(*bsdar));
+	/* Enable deterministic mode by default. */
+	bsdar-options |= AR_D;
 
 	if ((bsdar-progname = getprogname()) == NULL)
 		bsdar-progname = ar;
diff --git a/usr.bin/ar/ar.1 b/usr.bin/ar/ar.1
--- a/usr.bin/ar/ar.1
+++ b/usr.bin/ar/ar.1
@@ -210,6 +210,7 @@
 .Ar .
 This ensures that checksums on the resulting archives are reproducible
 when member contents are identical.
+This option is enabled by default.
 If multiple
 .Fl D
 and

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

[Differential] [Request, 39 lines] D3175: ar: add -U (unique) option to disable -D (deterministic) mode

[emaste (Ed Maste)]

emaste created this revision.
emaste added reviewers: brooks, bapt.
emaste added a subscriber: freebsd-toolchain-list.

REVISION SUMMARY
  I'd like to make ar(1) produce deterministic output by default. In order to 
do so we'll first need an option to turn off deterministic mode.
  
  Note that this is against upstream ELF Tool Chain ar(1), which is a little 
different from the one in the FreeBSD tree. I plan to migrate to ELF Tool 
Chain's eventually, but this change should apply (perhaps with trivial 
modification) to FreeBSD's.

REVISION DETAIL
  https://reviews.freebsd.org/D3175

AFFECTED FILES
  ar/ar.1
  ar/ar.c

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks, bapt
Cc: freebsd-toolchain-list
diff --git a/ar/ar.c b/ar/ar.c
--- a/ar/ar.c
+++ b/ar/ar.c
@@ -123,15 +123,18 @@
 	len = strlen(bsdar-progname);
 	if (len = strlen(ranlib) 
 	strcmp(bsdar-progname + len - strlen(ranlib), ranlib) == 0) {
-		while ((opt = getopt_long(argc, argv, tDV, longopts,
+		while ((opt = getopt_long(argc, argv, tDUV, longopts,
 		NULL)) != -1) {
 			switch(opt) {
 			case 't':
 /* Ignored. */
 break;
 			case 'D':
 bsdar-options |= AR_D;
 break;
+			case 'U':
+bsdar-options = ~AR_D;
+break;
 			case 'V':
 bsdar_version();
 break;
@@ -169,7 +172,7 @@
 		}
 	}
 
-	while ((opt = getopt_long(argc, argv, abCcdDfF:ijlMmopqrSsTtuVvxz,
+	while ((opt = getopt_long(argc, argv, abCcdDfF:ijlMmopqrSsTtUuVvxz,
 	longopts, NULL)) != -1) {
 		switch(opt) {
 		case 'a':
@@ -237,6 +240,9 @@
 		case 't':
 			set_mode(bsdar, opt);
 			break;
+		case 'U':
+			bsdar-options = ~AR_D;
+			break;
 		case 'u':
 			bsdar-options |= AR_U;
 			break;
@@ -400,7 +406,8 @@
   -DUse fixed metadata, for consistent archive checksums.\n\
   -F FORMAT | --flavor=FORMAT\n\
 Create archives with the specified format.\n\
-  -SDo not generate an archive symbol table.\n
+  -SDo not generate an archive symbol table.\n\
+  -UUse original metadata, for unique archive checksums.\n
 
 static void
 bsdar_usage(void)
@@ -415,6 +422,7 @@
   Options:\n\
   -t  (This option is accepted, but ignored).\n\
   -D  Use fixed metadata, for consistent archive checksums.\n\
+  -U  Use original metadata, for unique archive checksums.\n\
   -V  Print a version identifier and exit.\n
 
 static void
diff --git a/ar/ar.1 b/ar/ar.1
--- a/ar/ar.1
+++ b/ar/ar.1
@@ -23,7 +23,7 @@
 .\
 .\ $Id$
 .\
-.Dd December 10, 2012
+.Dd July 23, 2015
 .Os
 .Dt AR 1
 .Sh NAME
@@ -66,6 +66,7 @@
 .Op Fl f
 .Op Fl F Ar flavor | Fl -flavor Ar flavor
 .Op Fl s | Fl S
+.Op Fl U
 .Op Fl v
 .Op Fl z
 .Ar archive
@@ -83,14 +84,16 @@
 .Op Fl j
 .Op Fl s | Fl S
 .Op Fl u
+.Op Fl U
 .Op Fl v
 .Op Fl z
 .Ar archive
 .Ar
 .Nm
 .Fl s
 .Op Fl D
 .Op Fl j
+.Op Fl U
 .Op Fl z
 .Ar archive
 .Nm
@@ -203,6 +206,12 @@
 .Ar .
 This ensures that checksums on the resulting archives are reproducible
 when member contents are identical.
+If the
+.It Fl D
+and
+.It Fl U
+options are both specified, the one specified later in the command line
+takes effect.
 .It Fl f
 Synonymous with option
 .Fl T .
@@ -335,6 +344,20 @@
 .Ar
 will be extracted only if they are newer than the corresponding
 files in the file system.
+.It Fl U
+When used in combination with the
+.Fl r
+or
+.Fl q
+option, insert the real mtime, uid and gid, and file mode values
+from the members named by arguments
+.Ar .
+If the
+.It Fl D
+and
+.It Fl U
+options are both specified, the one specified later in the command line
+takes effect.
 .It Fl v
 Provide verbose output.
 When used with the

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

[Differential] [Commented On] D2338: readelf: avoid division by zero for files with invalid sh_entsize

[emaste (Ed Maste)]

emaste added a comment.

Yes - sorry for the delay. I realized I had a newer implementation that 
factored the divide-by-zero checks into a  helper function, and uploaded the 
new diff a few days ago.


REVISION DETAIL
  https://reviews.freebsd.org/D2338

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks
Cc: brooks, freebsd-toolchain-list
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 20 lines] D2933: Significantly speed up ar(1) on UFS file systems

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: kib.
emaste added subscribers: davide, dim, freebsd-toolchain-list, kib.

REVISION SUMMARY
  Fault in the buffer prior to writing as a workaround for poor performance due 
to interaction with kernel fs deadlock avoidance code. See the comment prior to 
vn_io_fault_doio() in vfs_vnops.c for details of the issue.
  
  Thanks @kib for diagnosing, providing an explanation of the issue and 
workaround.

TEST PLAN
  ```
  % truncate -s 16M obj.o
  % ar r out.a obj.o
  ```
  
  Total time with stock and patched ar(1):
  ```
  x ar.r284891
  + ar.patched
  +--+   
  |+ |   
  |+x|   
  |+   xx|   
  |A   |A|   
  +--+   
  N Min  MaxMedian   AvgStddev   
  x   3   1.3071.321 1.315 1.314  0.0070237692   
  +   30.020.023 0.022   0.02167  0.0015275252   
  Difference at 95.0% confidence
  -1.29267 +/- 0.0115203
  -98.3515% +/- 0.876513%
  (Student's t, pooled s = 0.00508265)
  ```

REVISION DETAIL
  https://reviews.freebsd.org/D2933

AFFECTED FILES
  usr.bin/ar/write.c

CHANGE DETAILS
  diff --git a/usr.bin/ar/write.c b/usr.bin/ar/write.c
  --- a/usr.bin/ar/write.c
  +++ b/usr.bin/ar/write.c
  @@ -41,6 +41,7 @@
   #include stdlib.h
   #include string.h
   #include sysexits.h
  +#include unistd.h
   
   #include ar.h
   
  @@ -61,6 +62,7 @@
   static void  free_obj(struct bsdar *bsdar, struct ar_obj *obj);
   static void  insert_obj(struct bsdar *bsdar, struct ar_obj *obj,
struct ar_obj *pos);
  +static void  prefault_buffer(const char *buf, size_t s);
   static void  read_objs(struct bsdar *bsdar, const char *archive,
int checkargv);
   static void  write_archive(struct bsdar *bsdar, char mode);
  @@ -551,11 +553,29 @@
   }
   
   /*
  + * Fault in the buffer prior to writing as a workaround for poor performance
  + * due to interaction with kernel fs deadlock avoidance code. See the comment
  + * prior to vn_io_fault_doio() in vfs_vnops.c for details of the issue.
  + */
  +static void
  +prefault_buffer(const char *buf, size_t s)
  +{
  + volatile const char *p;
  + size_t page_size;
  +
  + page_size = sysconf(_SC_PAGESIZE);
  + for (p = buf; p  buf + s;
  + p += page_size - ((uintptr_t)p  page_size - 1))
  + *p;
  +}
  +
  +/*
* Wrapper for archive_write_data().
*/
   static void
   write_data(struct bsdar *bsdar, struct archive *a, const void *buf, size_t s)
   {
  + prefault_buffer(buf, s);
if (archive_write_data(a, buf, s) != (ssize_t)s)
bsdar_errc(bsdar, EX_SOFTWARE, 0, %s,
archive_error_string(a));

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, kib
Cc: kib, freebsd-toolchain-list, dim, davide
diff --git a/usr.bin/ar/write.c b/usr.bin/ar/write.c
--- a/usr.bin/ar/write.c
+++ b/usr.bin/ar/write.c
@@ -41,6 +41,7 @@
 #include stdlib.h
 #include string.h
 #include sysexits.h
+#include unistd.h
 
 #include ar.h
 
@@ -61,6 +62,7 @@
 static void	free_obj(struct bsdar *bsdar, struct ar_obj *obj);
 static void	insert_obj(struct bsdar *bsdar, struct ar_obj *obj,
 		struct ar_obj *pos);
+static void	prefault_buffer(const char *buf, size_t s);
 static void	read_objs(struct bsdar *bsdar, const char *archive,
 		int checkargv);
 static void	write_archive(struct bsdar *bsdar, char mode);
@@ -551,11 +553,29 @@
 }
 
 /*
+ * Fault in the buffer prior to writing as a workaround for poor performance
+ * due to interaction with kernel fs deadlock avoidance code. See the comment
+ * prior to vn_io_fault_doio() in vfs_vnops.c for details of the issue.
+ */
+static void
+prefault_buffer(const char *buf, size_t s)
+{
+	volatile const char *p;
+	size_t page_size;
+
+	page_size = sysconf(_SC_PAGESIZE);
+	for (p = buf; p  buf + s;
+	p += page_size - ((uintptr_t)p  page_size - 1))
+		*p;
+}
+
+/*
  * Wrapper for archive_write_data().
  */
 static void
 write_data(struct bsdar *bsdar, struct archive *a, const void *buf, size_t s)
 {
+	prefault_buffer(buf, s);
 	if (archive_write_data(a, buf, s) != (ssize_t)s)
 		bsdar_errc(bsdar, EX_SOFTWARE, 0, %s,
 		archive_error_string(a));

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

[Differential] [Request, 31 lines] D2887: Allow ELF Tool Chain elfcopy to be installed as objcopy

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: andrew.
emaste added a subscriber: freebsd-toolchain-list.
Herald added subscribers: emaste, bdrewery.

REVISION SUMMARY
  ELF Tool Chain elfcopy is nearly a drop-in replacement for GNU objcopy (but 
does not currently support PE output, needed for building x86 UEFI bits). Add a 
make.conf knob to allow installing it as objcopy and set it by default for 
aarch64 only, where we don't have a native binutils.
  
  This is WIP for comment and testing.

REVISION DETAIL
  https://reviews.freebsd.org/D2887

AFFECTED FILES
  gnu/usr.bin/binutils/Makefile
  share/mk/src.opts.mk
  tools/build/mk/OptionalObsoleteFiles.inc
  tools/build/options/WITH_ELFCOPY_AS_OBJCOPY
  usr.bin/elfcopy/Makefile

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, andrew
Cc: bdrewery, freebsd-toolchain-list, emaste
diff --git a/usr.bin/elfcopy/Makefile b/usr.bin/elfcopy/Makefile
--- a/usr.bin/elfcopy/Makefile
+++ b/usr.bin/elfcopy/Makefile
@@ -7,7 +7,15 @@
 
 .PATH: ${ELFCOPYDIR}
 
+.if ${MK_ELFCOPY_AS_OBJCOPY} != no
+PROG=	objcopy
+objcopy.1: elfcopy.1
+	sed -e 's/\.Dt ELFCOPY 1/.Dt OBJCOPY 1/' \
+	-e 's/\.Nm elfcopy/.Nm objcopy/'  ${.ALLSRC}  ${.TARGET}
+CLEANFILES+= objcopy.1
+.else
 PROG=	elfcopy
+.endif
 
 SRCS=	archive.c ascii.c binary.c main.c sections.c segments.c symbols.c
 
@@ -17,8 +25,8 @@
 
 CFLAGS+=-I${ELFTCDIR}/libelftc -I${ELFTCDIR}/common
 
-MAN=	elfcopy.1 strip.1
+MAN=	${PROG}.1 strip.1
 
-LINKS=	${BINDIR}/elfcopy ${BINDIR}/strip
+LINKS=	${BINDIR}/${PROG} ${BINDIR}/strip
 
 .include bsd.prog.mk
diff --git a/tools/build/options/WITH_ELFCOPY_AS_OBJCOPY b/tools/build/options/WITH_ELFCOPY_AS_OBJCOPY
new file mode 100644
--- /dev/null
+++ b/tools/build/options/WITH_ELFCOPY_AS_OBJCOPY
@@ -0,0 +1,4 @@
+.\ $FreeBSD$
+Set to build and install ELF Tool Chain's elfcopy as
+.Xr objcopy 1 ,
+instead of the one from GNU Binutils.
diff --git a/tools/build/mk/OptionalObsoleteFiles.inc b/tools/build/mk/OptionalObsoleteFiles.inc
--- a/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/tools/build/mk/OptionalObsoleteFiles.inc
@@ -184,7 +184,9 @@
 .if ${MK_BINUTILS} == no
 OLD_FILES+=usr/bin/as
 OLD_FILES+=usr/bin/ld
+.if ${MK_ELFTOOLCHAIN_TOOLS} != no  ${MK_ELFCOPY_AS_OBJCOPY} == no
 OLD_FILES+=usr/bin/objcopy
+.endif
 OLD_FILES+=usr/bin/objdump
 OLD_FILES+=usr/bin/readelf
 OLD_FILES+=usr/libdata/ldscripts/elf_x86_64_fbsd.x
@@ -202,7 +204,9 @@
 OLD_FILES+=usr/libdata/ldscripts/elf_x86_64_fbsd.xw
 OLD_FILES+=usr/share/man/man1/as.1.gz
 OLD_FILES+=usr/share/man/man1/ld.1.gz
+.if ${MK_ELFTOOLCHAIN_TOOLS} != no  ${MK_ELFCOPY_AS_OBJCOPY} == no
 OLD_FILES+=usr/share/man/man1/objcopy.1.gz
+.endif
 OLD_FILES+=usr/share/man/man1/objdump.1.gz
 OLD_FILES+=usr/share/man/man1/readelf.1.gz
 OLD_FILES+=usr/share/man/man7/as.7.gz
@@ -1648,7 +1652,8 @@
 OLD_FILES+=usr/share/nls/uk_UA.KOI8-U/ee.cat
 .endif
 
-.if ${MK_ELFTOOLCHAIN_TOOLS} == no
+.if ${MK_ELFTOOLCHAIN_TOOLS} == no || \
+(${MK_ELFTOOLCHAIN_TOOLS} != no  MK_ELFCOPY_AS_OBJCOPY == no)
 OLD_FILES+=usr/bin/elfcopy
 OLD_FILES+=usr/share/man/man1/elfcopy.1.gz
 .endif
diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -234,6 +234,9 @@
 .endif
 .if ${__T} == aarch64
 BROKEN_OPTIONS+=BINUTILS BINUTILS_BOOTSTRAP GCC GCC_BOOTSTRAP GDB
+__DEFAULT_YES_OPTIONS+=ELFCOPY_AS_OBJCOPY
+.else
+__DEFAULT_NO_OPTIONS+=ELFCOPY_AS_OBJCOPY
 .endif
 # LLVM lacks support for FreeBSD 64-bit atomic operations for ARMv4/ARMv5
 .if ${__T} == arm || ${__T} == armeb
diff --git a/gnu/usr.bin/binutils/Makefile b/gnu/usr.bin/binutils/Makefile
--- a/gnu/usr.bin/binutils/Makefile
+++ b/gnu/usr.bin/binutils/Makefile
@@ -11,7 +11,7 @@
 	as \
 	ld \
 	${_nm} \
-	objcopy \
+	${_objcopy} \
 	objdump \
 	${_readelf} \
 	${_size} \
@@ -26,5 +26,8 @@
 _strings=	strings
 _strip=		strip
 .endif
+.if ${MK_ELFTOOLCHAIN_TOOLS} == no || ${MK_ELFCOPY_AS_OBJCOPY} == no
+_objcopy=	objcopy
+.endif
 
 .include bsd.subdir.mk

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

[Differential] [Commented On] D2887: Allow ELF Tool Chain elfcopy to be installed as objcopy

[emaste (Ed Maste)]

emaste added a comment.

In https://reviews.freebsd.org/D2887#56056, @bapt wrote:

 Why not always build elfcopy and just make a hardlink objcopy if 
 MK_ELFCOPY_AS_OBJCOPY is set?

 That will make elfcopy always available to users


That's a possibility, although I think I'd prefer to (eventually) just install 
elfcopy as objcopy on all platforms, ensuring that it supports all of the 
options we care about. We haven't yet shipped elfcopy in a release.


REVISION DETAIL
  https://reviews.freebsd.org/D2887

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, andrew
Cc: bapt, bdrewery, freebsd-toolchain-list, emaste
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Accepted] D1932: Remove the non-standard CC alias for c++

[emaste (Ed Maste)]

emaste accepted this revision.

REPOSITORY
  rS FreeBSD src repository

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D1932

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, theraven, emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

[emaste (Ed Maste)]

emaste added a comment.

In https://reviews.freebsd.org/D1932#49686, @imp wrote:

 it is a very de-facto standard that many ports rely on.


Many ports will choose CC if it exists, but I'm not sure they rely on it. 
Autoconf and cmake builds will try a list and if they pick c++ next they'll be 
fine.
exp-run requested in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200475


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1932

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, theraven, imp
Cc: imp, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Closed] D2576: Update crunch bootstrapping test

[emaste (Ed Maste)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rS283108: Update crunch bootstrapping test for recent fixes 
(authored by emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D2576?vs=5456id=5476#toc

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D2576

AFFECTED FILES
  head/Makefile.inc1

CHANGE DETAILS
  diff --git a/head/Makefile.inc1 b/head/Makefile.inc1
  --- a/head/Makefile.inc1
  +++ b/head/Makefile.inc1
  @@ -1297,7 +1297,9 @@
   _lex=usr.bin/lex
   .endif
   
  -.if ${BOOTSTRAPPING}  1001507
  +# r277259 crunchide: Correct 64-bit section header offset
  +# r281674 crunchide: always include both 32- and 64-bit ELF support
  +.if ${BOOTSTRAPPING}  1100071
   _crunch= usr.sbin/crunch
   .endif
   
  @@ -1466,11 +1468,6 @@
   _btxld=  usr.sbin/btxld
   .endif
   .endif
  -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
  -.if ${MK_RESCUE} != no
  -_crunchide=  usr.sbin/crunch/crunchide
  -.endif
  -.endif
   
   # If we're given an XAS, don't build binutils.
   .if ${XAS:M/*} == 

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, imp
Cc: freebsd-toolchain
diff --git a/head/Makefile.inc1 b/head/Makefile.inc1
--- a/head/Makefile.inc1
+++ b/head/Makefile.inc1
@@ -1297,7 +1297,9 @@
 _lex=		usr.bin/lex
 .endif
 
-.if ${BOOTSTRAPPING}  1001507
+# r277259 crunchide: Correct 64-bit section header offset
+# r281674 crunchide: always include both 32- and 64-bit ELF support
+.if ${BOOTSTRAPPING}  1100071
 _crunch=	usr.sbin/crunch
 .endif
 
@@ -1466,11 +1468,6 @@
 _btxld=		usr.sbin/btxld
 .endif
 .endif
-.if ${TARGET_ARCH} != ${MACHINE_ARCH}
-.if ${MK_RESCUE} != no
-_crunchide=	usr.sbin/crunch/crunchide
-.endif
-.endif
 
 # If we're given an XAS, don't build binutils.
 .if ${XAS:M/*} == 

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

[Differential] [Request, 9 lines] D2576: Update crunch bootstrapping test

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: imp.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  - r277259 crunchide: Correct 64-bit section header offset
  - r281674 crunchide: always include both 32- and 64-bit ELF support
  
  With built-in cross-size support we also no longer need a special case for 
cross-build crunchide.

REVISION DETAIL
  https://reviews.freebsd.org/D2576

AFFECTED FILES
  Makefile.inc1

CHANGE DETAILS
  diff --git a/Makefile.inc1 b/Makefile.inc1
  --- a/Makefile.inc1
  +++ b/Makefile.inc1
  @@ -1297,7 +1297,9 @@
   _lex=usr.bin/lex
   .endif
   
  -.if ${BOOTSTRAPPING}  1001507
  +# r277259 crunchide: Correct 64-bit section header offset
  +# r281674 crunchide: always include both 32- and 64-bit ELF support
  +.if ${BOOTSTRAPPING}  1100071
   _crunch= usr.sbin/crunch
   .endif
   
  @@ -1466,11 +1468,6 @@
   _btxld=  usr.sbin/btxld
   .endif
   .endif
  -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
  -.if ${MK_RESCUE} != no
  -_crunchide=  usr.sbin/crunch/crunchide
  -.endif
  -.endif
   
   # If we're given an XAS, don't build binutils.
   .if ${XAS:M/*} == 

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, imp
Cc: freebsd-toolchain
diff --git a/Makefile.inc1 b/Makefile.inc1
--- a/Makefile.inc1
+++ b/Makefile.inc1
@@ -1297,7 +1297,9 @@
 _lex=		usr.bin/lex
 .endif
 
-.if ${BOOTSTRAPPING}  1001507
+# r277259 crunchide: Correct 64-bit section header offset
+# r281674 crunchide: always include both 32- and 64-bit ELF support
+.if ${BOOTSTRAPPING}  1100071
 _crunch=	usr.sbin/crunch
 .endif
 
@@ -1466,11 +1468,6 @@
 _btxld=		usr.sbin/btxld
 .endif
 .endif
-.if ${TARGET_ARCH} != ${MACHINE_ARCH}
-.if ${MK_RESCUE} != no
-_crunchide=	usr.sbin/crunch/crunchide
-.endif
-.endif
 
 # If we're given an XAS, don't build binutils.
 .if ${XAS:M/*} == 

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

[Differential] [Request, 19 lines] D2408: Add ELF Tool Chain's c++filt to the build

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: brooks.
emaste added a subscriber: freebsd-toolchain.

REVISION DETAIL
  https://reviews.freebsd.org/D2408

AFFECTED FILES
  usr.bin/Makefile
  usr.bin/cxxfilt/Makefile

CHANGE DETAILS
  diff --git a/usr.bin/cxxfilt/Makefile b/usr.bin/cxxfilt/Makefile
  new file mode 100644
  --- /dev/null
  +++ b/usr.bin/cxxfilt/Makefile
  @@ -0,0 +1,17 @@
  +# $FreeBSD$
  +
  +.include src.opts.mk
  +
  +ELFTCDIR=${.CURDIR}/../../contrib/elftoolchain
  +SRCDIR=  ${ELFTCDIR}/cxxfilt
  +
  +.PATH: ${SRCDIR}
  +
  +PROG=c++filt
  +SRCS=cxxfilt.c
  +
  +LIBADD=  elftc
  +
  +CFLAGS+=-I${ELFTCDIR}/libelftc -I${ELFTCDIR}/common
  +
  +.include bsd.prog.mk
  diff --git a/usr.bin/Makefile b/usr.bin/Makefile
  --- a/usr.bin/Makefile
  +++ b/usr.bin/Makefile
  @@ -36,6 +36,7 @@
csplit \
ctlstat \
cut \
  + ${_cxxfilt} \
demandoc \
dirname \
dpv \
  @@ -237,6 +238,7 @@
   
   .if ${MK_ELFTOOLCHAIN_TOOLS} != no
   _addr2line=  addr2line
  +_cxxfilt=cxxfilt
   _elfcopy=elfcopy
   _nm= nm
   _readelf=readelf

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks
Cc: freebsd-toolchain
diff --git a/usr.bin/cxxfilt/Makefile b/usr.bin/cxxfilt/Makefile
new file mode 100644
--- /dev/null
+++ b/usr.bin/cxxfilt/Makefile
@@ -0,0 +1,17 @@
+# $FreeBSD$
+
+.include src.opts.mk
+
+ELFTCDIR=	${.CURDIR}/../../contrib/elftoolchain
+SRCDIR=		${ELFTCDIR}/cxxfilt
+
+.PATH: ${SRCDIR}
+
+PROG=	c++filt
+SRCS=	cxxfilt.c
+
+LIBADD=	elftc
+
+CFLAGS+=-I${ELFTCDIR}/libelftc -I${ELFTCDIR}/common
+
+.include bsd.prog.mk
diff --git a/usr.bin/Makefile b/usr.bin/Makefile
--- a/usr.bin/Makefile
+++ b/usr.bin/Makefile
@@ -36,6 +36,7 @@
 	csplit \
 	ctlstat \
 	cut \
+	${_cxxfilt} \
 	demandoc \
 	dirname \
 	dpv \
@@ -237,6 +238,7 @@
 
 .if ${MK_ELFTOOLCHAIN_TOOLS} != no
 _addr2line=	addr2line
+_cxxfilt=	cxxfilt
 _elfcopy=	elfcopy
 _nm=		nm
 _readelf=	readelf

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

[Differential] [Commented On] D2408: Add ELF Tool Chain's c++filt to the build

[emaste (Ed Maste)]

emaste added a comment.

Oh - we also need either:

  diff --git a/gnu/usr.bin/cc/Makefile b/gnu/usr.bin/cc/Makefile
  index abc9876..12ee7f8 100644
  --- a/gnu/usr.bin/cc/Makefile
  +++ b/gnu/usr.bin/cc/Makefile
  @@ -12,7 +12,10 @@ SUBDIR+= cpp
   .endif
   
   .if ${MK_CXX} != no
  -SUBDIR+= cc1plus c++ c++filt
  +SUBDIR+= cc1plus c++
  +.if ${MK_ELFTOOLCHAIN_TOLOLS} != no
  +SUBDIR+= c++filt
  +.endif
   .endif
   
   .if ${MK_GCOV} != no

or

  --- a/usr.bin/Makefile
  +++ b/usr.bin/Makefile
  @@ -238,7 +238,9 @@ SUBDIR+=ee
   
   .if ${MK_ELFTOOLCHAIN_TOOLS} != no
   _addr2line=addr2line
  +.if ${MK_GCC} != no  ${MK_CXX} != no
   _cxxfilt=  cxxfilt
  +.endif
   _elfcopy=  elfcopy
   _nm=   nm
   _readelf=  readelf


REVISION DETAIL
  https://reviews.freebsd.org/D2408

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Closed] D2408: Add ELF Tool Chain's c++filt to the build

[emaste (Ed Maste)]

This revision was automatically updated to reflect the committed changes.
Closed by commit rS282285: Add ELF Tool Chain's c++filt to the build (authored 
by emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D2408?vs=5108id=5123#toc

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D2408

AFFECTED FILES
  head/gnu/usr.bin/cc/Makefile
  head/tools/build/mk/OptionalObsoleteFiles.inc
  head/usr.bin/Makefile

CHANGE DETAILS
  diff --git a/head/tools/build/mk/OptionalObsoleteFiles.inc 
b/head/tools/build/mk/OptionalObsoleteFiles.inc
  --- a/head/tools/build/mk/OptionalObsoleteFiles.inc
  +++ b/head/tools/build/mk/OptionalObsoleteFiles.inc
  @@ -1004,7 +1004,9 @@
   .if ${MK_CXX} == no
   OLD_FILES+=usr/bin/CC
   OLD_FILES+=usr/bin/c++
  +.if ${MK_ELFTOOLCHAIN_TOOLS} == no
   OLD_FILES+=usr/bin/c++filt
  +.endif
   OLD_FILES+=usr/bin/g++
   OLD_FILES+=usr/libexec/cc1plus
   .if ${MK_GCC} == no
  diff --git a/head/gnu/usr.bin/cc/Makefile b/head/gnu/usr.bin/cc/Makefile
  --- a/head/gnu/usr.bin/cc/Makefile
  +++ b/head/gnu/usr.bin/cc/Makefile
  @@ -12,7 +12,10 @@
   .endif
   
   .if ${MK_CXX} != no
  -SUBDIR+= cc1plus c++ c++filt
  +SUBDIR+= cc1plus c++
  +.if ${MK_ELFTOOLCHAIN_TOOLS} == no
  +SUBDIR+= c++filt
  +.endif
   .endif
   
   .if ${MK_GCOV} != no
  diff --git a/head/usr.bin/Makefile b/head/usr.bin/Makefile
  --- a/head/usr.bin/Makefile
  +++ b/head/usr.bin/Makefile
  @@ -36,6 +36,7 @@
csplit \
ctlstat \
cut \
  + ${_cxxfilt} \
demandoc \
dirname \
dpv \
  @@ -237,6 +238,7 @@
   
   .if ${MK_ELFTOOLCHAIN_TOOLS} != no
   _addr2line=  addr2line
  +_cxxfilt=cxxfilt
   _elfcopy=elfcopy
   _nm= nm
   _readelf=readelf

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks, imp
Cc: imp, freebsd-toolchain
diff --git a/head/tools/build/mk/OptionalObsoleteFiles.inc b/head/tools/build/mk/OptionalObsoleteFiles.inc
--- a/head/tools/build/mk/OptionalObsoleteFiles.inc
+++ b/head/tools/build/mk/OptionalObsoleteFiles.inc
@@ -1004,7 +1004,9 @@
 .if ${MK_CXX} == no
 OLD_FILES+=usr/bin/CC
 OLD_FILES+=usr/bin/c++
+.if ${MK_ELFTOOLCHAIN_TOOLS} == no
 OLD_FILES+=usr/bin/c++filt
+.endif
 OLD_FILES+=usr/bin/g++
 OLD_FILES+=usr/libexec/cc1plus
 .if ${MK_GCC} == no
diff --git a/head/gnu/usr.bin/cc/Makefile b/head/gnu/usr.bin/cc/Makefile
--- a/head/gnu/usr.bin/cc/Makefile
+++ b/head/gnu/usr.bin/cc/Makefile
@@ -12,7 +12,10 @@
 .endif
 
 .if ${MK_CXX} != no
-SUBDIR+= cc1plus c++ c++filt
+SUBDIR+= cc1plus c++
+.if ${MK_ELFTOOLCHAIN_TOOLS} == no
+SUBDIR+= c++filt
+.endif
 .endif
 
 .if ${MK_GCOV} != no
diff --git a/head/usr.bin/Makefile b/head/usr.bin/Makefile
--- a/head/usr.bin/Makefile
+++ b/head/usr.bin/Makefile
@@ -36,6 +36,7 @@
 	csplit \
 	ctlstat \
 	cut \
+	${_cxxfilt} \
 	demandoc \
 	dirname \
 	dpv \
@@ -237,6 +238,7 @@
 
 .if ${MK_ELFTOOLCHAIN_TOOLS} != no
 _addr2line=	addr2line
+_cxxfilt=	cxxfilt
 _elfcopy=	elfcopy
 _nm=		nm
 _readelf=	readelf

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

[Differential] [Commented On] D2408: Add ELF Tool Chain's c++filt to the build

[emaste (Ed Maste)]

emaste added inline comments.

INLINE COMMENTS
  gnu/usr.bin/cc/Makefile:16 Sigh, this is backwards.
  Will update to `== no` - i.e., build GCC's c++filt in the 
`WITHOUT_ELFTOOLCHAIN_TOOLS` case.

REVISION DETAIL
  https://reviews.freebsd.org/D2408

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: emaste, brooks
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 32 lines] D2338: readelf: avoid division by zero for files with invalid sh_entsize

[emaste (Ed Maste)]

emaste created this revision.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  Variations reported in:
  https://sourceforge.net/p/elftoolchain/tickets/439
  https://sourceforge.net/p/elftoolchain/tickets/444
  https://sourceforge.net/p/elftoolchain/tickets/445
  https://sourceforge.net/p/elftoolchain/tickets/467

REVISION DETAIL
  https://reviews.freebsd.org/D2338

AFFECTED FILES
  readelf/readelf.c

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

[Differential] [Commented On] D2305: Fix bootstraping of crunchide

[emaste (Ed Maste)]

emaste added inline comments.

INLINE COMMENTS
  Makefile.inc1:1469 I believe @imp suggested we still need it unconditionally 
when crossbuilding, and also note that usr.sbin/crunch is added for 
`${BOOTSTRAPPING}  114` in bootstrap-tools. I wonder if we can just 
promote usr.sbin/crunch to an unconditional build tool?

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, emaste, imp
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Updated] D2305: Fix bootstraping of crunchide

[emaste (Ed Maste)]

emaste added a comment.

! In D2305#4, @emaste wrote:
 I believe @imp suggested we still need it unconditionally when crossbuilding, 
 and also note that usr.sbin/crunch is added for `${BOOTSTRAPPING}  114` 
 in bootstrap-tools. I wonder if we can just promote usr.sbin/crunch to an 
 unconditional build tool?

Indeed, crunchide is built with only 32- or 64-bit ELF support depending on the 
target. I'll see about always compiling in both instead. If that works we can 
drop this part and change the `${BOOTSTRAPPING}` test below. Or just make it 
unconditional below.

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, imp, emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 13 lines] D2317: readelf: Validate MIPS option header

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: imp.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  Reported by antiAgainst in ELF Tool Chain ticket 442
  https://sourceforge.net/p/elftoolchain/tickets/442/

REVISION DETAIL
  https://reviews.freebsd.org/D2317

AFFECTED FILES
  readelf/readelf.c

To: emaste, imp
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Requested Changes To] D2305: Fix bootstraping of crunchide

[emaste (Ed Maste)]

emaste requested changes to this revision.
emaste added a comment.
This revision now requires changes to proceed.

`_crunchide` here is still needed for cross-builds (but should be addressed by 
D2314).
`_crunch` in the context not provided in this diff is the one that needs to be 
updated
I updated it in rS281659

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, imp, emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D2305: Fix bootstraping of crunchide

[emaste (Ed Maste)]

emaste added a comment.

This review can be abandoned - the original issue is now fixed.
We can open another review for a future change to make it unconditional.

REVISION DETAIL
  https://reviews.freebsd.org/D2305

To: rodrigc, imp, emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Closed] D2317: readelf: Validate MIPS option header

[emaste (Ed Maste)]

emaste closed this revision.
emaste added a comment.

Committed here: https://sourceforge.net/p/elftoolchain/code/3187, will come 
into FreeBSD with the next ELF Tool Chain import

REVISION DETAIL
  https://reviews.freebsd.org/D2317

To: emaste, imp
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D2302: Add arm64 to universe if binutils is available

[emaste (Ed Maste)]

emaste added a comment.

! In D2302#4, @andrew wrote:
 Would it be difficult to have a warning if the package is not installed?

Perhaps
```
.else   
@echo  arm64 skipped - install aarch64-binutils port or package to build
```

REVISION DETAIL
  https://reviews.freebsd.org/D2302

To: emaste, imp, andrew
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 6 lines] D2302: Add arm64 to universe if binutils is available

[emaste (Ed Maste)]

emaste created this revision.
emaste added reviewers: imp, andrew.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  arm64 relies on an external binutils port or package because the in-tree 
linker from binutils 2.17.50 does not support arm64. Add arm64 to universe if 
the linker is available.
  
  buildworld and buildkernel use the external binutils automatically, so `pkg 
install aarch64-binutils` is sufficient for building FreeBSD/arm64.

REVISION DETAIL
  https://reviews.freebsd.org/D2302

AFFECTED FILES
  Makefile

To: emaste, imp, andrew
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D2302: Add arm64 to universe if binutils is available

[emaste (Ed Maste)]

emaste added inline comments.

INLINE COMMENTS
  Makefile:383 Also add
  ```
  universe_epilogue: universe_arm64_skip
  ```

REVISION DETAIL
  https://reviews.freebsd.org/D2302

To: emaste, imp, andrew
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Updated, 10 lines] D2302: Add arm64 to universe if binutils is available

[emaste (Ed Maste)]

emaste updated this revision to Diff 4849.
emaste added a comment.

Add a message if we skip arm64 because we don't have binutils

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D2302?vs=4846id=4849

REVISION DETAIL
  https://reviews.freebsd.org/D2302

AFFECTED FILES
  Makefile

To: emaste, imp, andrew
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Closed] D2302: Add arm64 to universe if binutils is available

[emaste (Ed Maste)]

emaste closed this revision.
emaste updated this revision to Diff 4865.
emaste added a comment.

Closed by commit rS281629 (authored by @emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D2302?vs=4849id=4865#toc

REVISION DETAIL
  https://reviews.freebsd.org/D2302

AFFECTED FILES
  head/Makefile

To: emaste, imp, andrew
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Changed Subscribers] D2285: gcc 4.9.1 compilation fixes for aesni

[emaste (Ed Maste)]

emaste added a subscriber: emaste.

REVISION DETAIL
  https://reviews.freebsd.org/D2285

To: rodrigc, jmg
Cc: emaste, dim, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Accepted] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

[emaste (Ed Maste)]

emaste accepted this revision.
emaste added a comment.
This revision is now accepted and ready to land.

LGTM

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D2187

To: dim, rodrigc, imp, bapt, emaste
Cc: emaste, imp, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

Re: profile_rt from llvm folks?

[Ed Maste]

On 1 April 2015 at 16:35, Dimitry Andric d...@freebsd.org wrote:
 On 01 Apr 2015, at 02:03, NGie Cooper yaneurab...@gmail.com wrote:

 Hi all,
We've recently integrated a version of profile_rt from the llvm
 folks internally to replace gcov for code coverage. I was wondering if
 there was a plan to replace the copy of gcov in FreeBSD with the same
 (either in the base system, ports, or both).

 I personally have no plans to do so, but the build of libprofile_rt.a
 was added in r276857, at least.

Yes, as of that change one can compile with --coverage, and .gcda and
.gcno files will be produced via the functionality in libprofile_rt.a.

gcov(1) is able to use them, but when I tried llvm-cov it didn't work
correctly; in any case, llvm-cov is now on the roadmap for our
toolchain.

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

Re: Compiling LLDB

[Ed Maste]

On 30 March 2015 at 19:18, Kenan Ali k...@sandvine.com wrote:
 Hi,

 I would like to see if I could get involved with contributing to the kernel 
 core support for LLDB under FreeBSD. I'm running a FreeBSD-head build (on a 
 VM) from a week or two ago, and I'm following the instructions from here: 
 https://wiki.freebsd.org/lldb

 Once I get to the 'ninja lldb' step, it seems that I always end up with the 
 following error:

 CC: error: unable to execute command: Killed
 CC: error: linker command failed due to signal (use -v to see invocation)
 Ninja: build stopped: subcommand failed.

 I've tried passing the '-v' flag to ninja, which lists a large invocation 
 before spewing out the errors above. However, I cannot seem to figure out how 
 to get the '-v' command passed to LLVM's linker. Neither ninja's help output 
 or some basic Googling seem to be helping me diagnose this issue, so I was 
 wondering if anyone here could help?

I'd suggest checking /var/log/messages for further information. Is
this i386 or amd64, how much memory does your build host have, and are
you compiling with debug information or no? If had to guess, you're
running out of memory (or running into ulimit) during linking, and the
process is being killed as a result.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 5 lines] D2156: Switch to ELF toolchain readelf

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: imp.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  ELF toolchain readelf lacked some functionality at the time other tools (like 
size, strip, nm, etc.) were switched over to the ELF toolchain versions. This 
has been addressed as of the latest update, so we should be able to use it as 
well.

TEST PLAN
- Ports exp-run
- ad-hoc comparison of output against in-tree binutils readelf

REVISION DETAIL
  https://reviews.freebsd.org/D2156

AFFECTED FILES
  gnu/usr.bin/binutils/Makefile
  usr.bin/Makefile

To: emaste, imp
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D2156: Switch to ELF toolchain readelf

[emaste (Ed Maste)]

emaste added a comment.

exp-run is here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198950

REVISION DETAIL
  https://reviews.freebsd.org/D2156

To: emaste, imp, bapt
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 11 lines] D2003: Do not strip crunched binary; it will be done by install

[emaste (Ed Maste)]

emaste created this revision.
emaste added reviewers: andrew, imp.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  In cross-build cases it is possible we won't have a cross-strip during the 
the rescue build. Binaries are already stripped on install anyhow, so there is 
no need to strip during the build.

REVISION DETAIL
  https://reviews.freebsd.org/D2003

AFFECTED FILES
  Makefile.inc1
  sys/sys/param.h
  usr.sbin/crunch/crunchgen/crunchgen.c

To: emaste, andrew, imp
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D1974: Support out-of-tree binutils with in-tree compiler

[emaste (Ed Maste)]

emaste added a comment.

This supports aarch64 builds by installing the aarch64-binutils port and adding 
`CROSS_BINUTILS_PREFIX=/usr/local/aarch64-freebsd/bin/` to the make command 
line.

REVISION DETAIL
  https://reviews.freebsd.org/D1974

To: emaste, bapt
Cc: andrew, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Changed Subscribers] D1974: Support out-of-tree binutils with in-tree compiler

[emaste (Ed Maste)]

emaste added a subscriber: andrew.

REVISION DETAIL
  https://reviews.freebsd.org/D1974

To: emaste, bapt
Cc: andrew, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Closed] D1974: Support out-of-tree binutils with in-tree compiler

[emaste (Ed Maste)]

emaste closed this revision.
emaste updated this revision to Diff 3999.
emaste added a comment.

Closed by commit rS279328 (authored by @emaste).

CHANGED PRIOR TO COMMIT
  https://reviews.freebsd.org/D1974?vs=3998id=3999#toc

REVISION DETAIL
  https://reviews.freebsd.org/D1974

AFFECTED FILES
  head/Makefile.inc1

To: emaste, bapt, imp
Cc: imp, andrew, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Request, 6 lines] D1974: Support out-of-tree binutils with in-tree compiler

[emaste (Ed Maste)]

emaste created this revision.
emaste added a reviewer: bapt.
emaste added a subscriber: freebsd-toolchain.

REVISION SUMMARY
  Right now `CROSS_BINUTILS_PATH` is honoured only when `XCC` is set, i.e. an 
out-of-tree compiler. Allow `CROSS_BINUTILS_PATH` to pass through to a -B 
option also when using the in-tree compiler.
  
  I think this could be named just `BINUTILS_PATH`, but the existing 
`CROSS_BINUTILS_PATH` could as well. Since they have the same meaning I used 
the existing, if somewhat confusing, name.

REVISION DETAIL
  https://reviews.freebsd.org/D1974

AFFECTED FILES
  Makefile.inc1

To: emaste, bapt
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org

[Differential] [Commented On] D1826: libdwarf: Add symbol value when processing .rela relocations

[emaste (Ed Maste)]

emaste added a comment.

See also D1819

REVISION DETAIL
  https://reviews.freebsd.org/D1826

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