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 t
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
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 do
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 i
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
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.freeb
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 cma
On Mon, 26 Nov 2018 at 10:52, Ed Maste wrote:
>
> 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
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 ca
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
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, migrat
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
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
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-
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 % c
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 u
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
On 11 September 2018 at 14:11, Sid wrote:
> Hi,
> In src.conf, from 11.2 to 12-current, the elfcopy option was removed, but
> objcopy still in the documentation for binutils. I suspect this is about the
> toolchain too, and not only in the manpage for src.conf.
>
> Should objcopy be removed from
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 wa
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
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
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 happen
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. llv
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
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 he
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 repor
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 bui
On 26 March 2018 at 22:14, Ed Maste 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
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).
On 29 March 2018 at 13:14, Ed Maste wrote:
>
> There are now 14 PRs open for failures when lld is /usr/bin/ld.
Now down to 5:
PR 221800 - www/mod_jk
Appears to be an issue with libtool passing through linker flags. 0
dependent ports skipped.
PR 224673 - misc/seabios
Port maintainer has
On 27 March 2018 at 18:21, Ed Maste wrote:
> (Moved from -current to -ports)
>
> On 27 March 2018 at 13:15, Ed Maste 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 alre
(Moved from -current to -ports)
On 27 March 2018 at 13:15, Ed Maste 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 po
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
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.
1. Kostik (kib@) has a patch to start using kernel ifunc, with the
first use being Supervisor Mode
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 no
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 o
On 18 December 2017 at 22:10, Ed Maste 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 t
On 27 November 2017 at 15:39, Ed Maste 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
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 y
On 25 August 2017 at 14:07, Ryan Libby wrote:
> On Wed, Aug 23, 2017 at 4:30 PM, John Baldwin wrote:
>> Author: jhb
>> Date: Wed Aug 23 23:30:25 2017
>> New Revision: 322824
>> URL: https://svnweb.freebsd.org/changeset/base/322824
>>
>> Log:
>> Improve the coverage of debug symbols for MK_DEBUG
On 12 June 2017 at 17:21, Ed Maste 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
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 br
On 19 April 2017 at 15:06, Ed Maste 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 inconsiste
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 impl
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 ---
> lib
On 5 April 2017 at 16:09, Dimitry Andric wrote:
>
> Note that as of r316432, all of the above is also available in the
> stable/11 branch.
However some of the changes to FreeBSD haven't yet been merged to
stable/11, and it's probably not possible to build world + kernel with
LLD (via WITH_LLD_IS_
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 t
[redirected to freebsd-toolchain]
On 24 March 2017 at 08:21, Andre Albsmeier wrote:
>
> Interesting is also that libc.a grows(!):
>
> Before the strip:
> -r--r- 1 andre wheel 2622684 24 Mar 13:18 libc.a
>
> After:
> -r--r- 1 andre wheel 2713792 24 Mar 13:19 libc.a
It seems this is
On 8 February 2017 at 08:10, Shawn Webb wrote:
> On Tuesday, 07 February 2017 06:55:44 PM Ed Maste wrote:
>> 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
>&
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.
___
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
On 11 January 2017 at 21:06, Roman Divacky wrote:
> Looks like a progress :) Three questions...
>
> Is the readelf -a reasonable now?
FYI, I just committed an ELF Tool Chain fix (r311941) so readelf
should display the relocation types properly now.
> If you compile with -g, does the
> backtrace
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
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 m
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 )
Th
On 29 November 2016 at 16:46, Mark Millard wrote:
>
>
> Summary: Does using clang 3.9.0 as the system compiler imply one should or
> must (eventually?) use WITH_LLVM_LIBUNWIND to have C++ exceptions work?
>
> Do WITH_LLVM_LIBUNWIND and WITHOUT_LLVM_LIBUNWIND have the same criteria
> for what dwarf
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
On 17 October 2016 at 17:11, Shawn Webb wrote:
>
> When the kernel is compiled with clang 3.9.0, it seems to freeze after
> being loaded by the clang 3.8 boot1.efi/loader.efi. I'm unsure if it's
> actually frozen or if simply nothing is being outputted to the console.
> Either way, I don't see con
On 1 August 2016 at 17:40, Ed Maste 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 n
In FreeBSD 11 ELF Tool Chain's elfcopy is by default installed as
objcopy. The option to switch back to GNU objcopy is available by
setting WITHOUT_ELFCOPY_AS_OBJCOPY in make.conf.
As part of the plan to remove the outdated in-tree binutils in FreeBSD
12 I intend to remove the WITHOUT_ELFCOPY_AS_O
On 1 August 2016 at 17:40, Ed Maste 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
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
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.
&g
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:
* AArch
On 19 July 2016 at 13:40, Jonathan Anderson wrote:
> Hello toolchain@,
>
> When building a recent (r275944) LLDB on stable/11, I've encountered build
> failures in tools/lldb-mi (missing symbol llvm_regexec, need to link against
> LLVMSupport). This problem doesn't occur on (at least) OS X, so per
On 20 October 2015 at 17:18, Warner Losh wrote:
>
>> On Oct 20, 2015, at 3:07 PM, Ed Maste wrote:
>>
>> On 20 October 2015 at 16:30, Konstantin Belousov wrote:
>>>
>>> Wouldn't this cause another outburst of 'works by default' discussion
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-toolchai
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.
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
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
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/
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=7271&id=7272
REVISION DETAIL
https://reviews.freebsd.org/D3190
AFFECTED FILES
usr.bin/ar/ar.1
usr.bin/ar/ar.c
CHANGE DE
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 de
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=7069&id=7269#toc
REPOSITORY
rS FreeBSD src repository
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=7235&id=7268#toc
REPOSITORY
rS FreeBSD src rep
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 thi
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
emaste updated this revision to Diff 7069.
emaste added a comment.
This revision now requires review to proceed.
Add a `get_ent_count` helper to check for 0 entsize instead of expanding the
check inline everywhere.
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D2338?vs=4930&id=7069
R
This revision was automatically updated to reflect the committed changes.
Closed by commit rS284928: speed up ar(1) on UFS file systems (authored by
emaste).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D2933?vs=6543&id=6545#toc
REPOSITORY
rS FreeBSD src repository
CHANGES SINCE LAST
emaste updated this revision to Diff 6543.
emaste added a comment.
This revision now requires review to proceed.
- give full path to file with comment explaining the deadlock avoidance
- avoid confusing page mask manipulation and just touch the last byte explicitly
CHANGES SINCE LAST UPDATE
ht
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 p
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 (eventua
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
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
fi
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
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=5456&id=5476#toc
REPOSITORY
rS FreeBSD src repository
REV
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
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=5108&id=5123#toc
REPOSITORY
rS FreeBSD src repository
REVISION DE
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.or
emaste updated this revision to Diff 5108.
emaste added a comment.
- prefer ELF Tool Chain's c++filt
- exclude from make delete-old
- fix typo
CHANGES SINCE LAST UPDATE
https://reviews.freebsd.org/D2408?vs=5105&id=5108
REVISION DETAIL
https://reviews.freebsd.org/D2408
AFFECTED FILES
gnu/
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+= c
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/M
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://sourceforg
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
___
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 FIL
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
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 update
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
> unc
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
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=4849&id=4865#toc
REVISION DETAIL
https://reviews.freebsd.org/D2302
AFFECTED FILES
h
1 - 100 of 171 matches
Mail list logo
