Re: clang options for load segments

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

Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

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

Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

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

Removing obsolete GDB 6.1.1 for FreeBSD 13

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

Re: add linker option for LIB32 step on PowerPC64

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

Re: Optimization bug with floating-point?

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

Re: Linking problem with lld

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

Re: GNU binutils 2.17.50 retirement planning

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

Re: GNU binutils 2.17.50 retirement planning

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.

GNU binutils 2.17.50 retirement planning

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,

Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

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

Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

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

Re: aarch64 head -r338921 vs. man ld vs. ld -v : man ld describes GNU when ld is lld

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

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

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 %

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

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

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

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?

Re: Broken arm support in clang now?

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

Re: Broken arm support in clang now?

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

Re: Migrating arm(v7) to LLD_BOOTSTRAP

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. Thi

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

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 the

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

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.

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

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

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

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

Re: A head buildworld race visible in the ci.freebsd.org build history

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

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

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

Re: Heads-up: linker (lld) changes for amd64 coming soon

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

Re: Heads-up: linker (lld) changes for amd64 coming soon

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 >

Re: Heads-up: linker (lld) changes for amd64 coming soon

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 submi

Re: Heads-up: linker (lld) changes for amd64 coming soon

(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

Re: Heads-up: linker (lld) changes for amd64 coming soon

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

Re: Migrating arm(v7) to LLD_BOOTSTRAP

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

Migrating arm(v7) to LLD_BOOTSTRAP

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

Re: Ports and LLVM's lld linker

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 t

Re: Ports and LLVM's lld linker

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 (r326

Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]

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

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

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, LL

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

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

Re: svn commit: r317159 - head/contrib/libstdc++/config/abi/pre

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

Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?

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).

Re: FYI: amd64 built with WITH_LLD_IS_LD= vs. devel/libunwind : cannot preempt symbol (for various symbols)

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: > > > ---

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

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

Re: clang 4.0.0 with_lld_is_ld build

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 sy

Re: clang 4.0.0 with_lld_is_ld build

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

Re: elfdump doesn't support .a files?

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

Re: clang on armv6 incorrectly emits call to sincos()

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

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

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`? ___

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

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 >

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

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

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

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 c

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

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 feat

Re: Time to enable partial relro

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

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

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. > > Ag

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

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: *

Re: clang confuses kgdb on static symbols

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

Re: clang confuses kgdb on static symbols

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.

Re: clang confuses kgdb on static symbols

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 thi

Re: clang confuses kgdb on static symbols

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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+=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ```

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

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

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

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 ___

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

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:

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

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

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

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

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

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 ___

Re: profile_rt from llvm folks?

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

Re: Compiling LLDB

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1   2   >