On 7 January 2014 03:54, David Chisnall wrote:
> On 7 Jan 2014, at 06:49, Rui Paulo wrote:
>> Our libdwarf was a from scratch implementation and we never used the LGPL
>> libdwarf. I don't know if it's worth investing time upgrading our BSD
>> licenced libdwarf or importing the LGPL libdwarf.
On 5 January 2014 08:00, Dimitry Andric wrote:
>
> Second, the shipped version of gdb in our tree is very old, and is
> basically unmaintained. Nobody in their right mind should ever use it
> for debugging, unless they have no other choice. As soon as the in-tree
> version of lldb is in workable
On 9 June 2014 21:48, Ryan Stone wrote:
> abi::__cxa_demangle is giving me an invalid result if I pass it a
> symbol that is not mangled. This is causing me problems as in my
> application, I'm getting symbol names from libelf and have no way of
> know a priori whether a symbol is mangled or not.
On 11 June 2014 14:53, Craig Rodrigues wrote:
>
> Is anyone working on a kernel lldb? When is it expected to be ready?
Kernel LLDB support is an ongoing Summer of Code project this year.
I'm not sure it's feasible for 10.1 though.
___
freebsd-toolchain
On 10 June 2014 02:38, David Chisnall wrote:
>
> If you know that the thing that you are demangling is a symbol name, then you
> can use the _Z check, which isn't really a hack - it's a marker added to
> identify C++ symbols. Note that, if you're writing portable code, you need
> to remember t
On 23 November 2014 at 19:09, Baptiste Daroussin wrote:
> Hi all,
>
> From what I can see on the elftoolchain website, they do have working
> replacement for:
> - size(1)
> - addr2line(1)
> - strings(1)
> - nm(1)
> - strip(1)
>
> Does anyone knows if there are known issues with those? or if they a
One of goals for the toolchain prior to the FreeBSD 11 branch is to
create a libllvm.so and libclang.so for use by all of the LLVM family
tools installed in the base system. This message is just a heads-up in
case anyone has questions or comments on the idea.
We currently build a large number of s
On 16 December 2014 at 11:15, David Chisnall wrote:
>
> Upstream doesn't call it libclang (that's the name of the library with a
> stable C ABI, which is why I'd like us not to confuse it with something with
> a library with an unstable C++ API). They do produce a libLLVM.so from the
> LLVM bui
On 16 December 2014 at 12:39, Warner Losh wrote:
>
> We should defer testing until after that import :)
Indeed. I have an early WIP patch in a local branch, but any new work
before 3.5.x lands will be wasted, so it will be in the new year that
I'll have something to start testing.
___
On 16 December 2014 at 14:47, Warner Losh wrote:
>
> My comment was
> more to Ed’s notion that these numbers will be dropping any time soon.
To be clear, I don't expect we'll be dropping knobs soon. We should
keep that as a goal to aim for.
___
freebsd-
We have a rather outdated version of binutils in the base system. As
part of a project to update our toolchain I've started working on
using some of the tools from the elftoolchain project. There is now a
build knob to enable the use of the following tools:
* addr2line
* elfcopy (strip)
* nm
* s
On 8 January 2015 at 08:45, Craig Rodrigues wrote:
> I just tried to build CURRENT with WITH_LLDB=yes
> in /etc/make.conf. I got this error:
>
> ...
Thanks for the report Craig, I'm looking at it.
___
freebsd-toolchain@freebsd.org mailing list
http://l
On 30 March 2015 at 19:18, Kenan Ali 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://w
On 1 April 2015 at 16:35, Dimitry Andric wrote:
> On 01 Apr 2015, at 02:03, NGie Cooper 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 g
On 3 April 2015 at 13:02, Warner Losh wrote:
> That shows that something in the list is needed. Likely only crunchhide.
>
> It doesn’t tell us why we need it, or when we started needing it, or what
> other conditions we might need it. This information is critical to document
> so we know when we c
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
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 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 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 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
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
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
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
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
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.
A quick update: most of the required changes have n
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
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 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
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 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 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 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 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 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 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
>&
[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
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
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_
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 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 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
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 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
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 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 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 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
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 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
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 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
(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 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
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 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 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
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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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, 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 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
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 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
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 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
emaste updated the summary for this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1327
To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe,
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.
REVISION SUMMARY
When asked to strip a specific symbol (-N) strip still defaulted to
STRIP_ALL. In this case binutils defaults to stripping nothing (other than the
requested symbol(s), of course), which makes a lot mor
emaste closed this revision.
emaste updated this revision to Diff 2778.
emaste added a comment.
Closed by commit rS275862 (authored by @emaste).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1327?vs=2767&id=2778#toc
REVISION DETAIL
https://reviews.freebsd.org/D1327
AFFECTED FILES
h
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.
REVISION SUMMARY
If we use -R to remove all sections we still need a .shstrtab (which will
itself be the only section entry). Do not wait until the addition of the first
non-default entry to create the default ones.
emaste updated the test plan for this revision.
REVISION DETAIL
https://reviews.freebsd.org/D1341
To: emaste
Cc: freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscrib
emaste closed this revision.
emaste updated this revision to Diff 2813.
emaste added a comment.
Closed by commit rS276061 (authored by @emaste).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1341?vs=2791&id=2813#toc
REVISION DETAIL
https://reviews.freebsd.org/D1341
AFFECTED FILES
h
emaste created this revision.
emaste added a subscriber: freebsd-toolchain.
REVISION SUMMARY
Previously elftoolchain readelf(1) only displayed correct names for Linux
note types.
Upstream elftoolchain ticket #473
https://sourceforge.net/p/elftoolchain/tickets/473/
REVISION DETAIL
https://
emaste added a comment.
>>! In D1428#3, @rpaulo wrote:
> This looks odd. Why are we relying on magic numbers instead of
> constants/enums like before?
Some of the constants in the previous version are Linux-specific, and don't
exist in our ELF headers.
We could make up our own constants (e.g.
emaste added a comment.
>>! In D1428#6, @rpaulo wrote:
>
> The Linux note types are Linux specific. Are you saying that FreeBSD reuses
> them ?
Not quite, just that the note types are vendor-specific and in a namespace
specific to the note name (vendor). `NT_PRSTATUS`, `NT_FPREGSET`, and
`NT_
emaste closed this revision.
emaste updated this revision to Diff 3002.
emaste added a comment.
Closed by commit rS276705 (authored by @emaste).
CHANGED PRIOR TO COMMIT
https://reviews.freebsd.org/D1428?vs=2980&id=3002#toc
REVISION DETAIL
https://reviews.freebsd.org/D1428
AFFECTED FILES
h
emaste added a subscriber: freebsd-toolchain.
REVISION DETAIL
https://reviews.freebsd.org/D1446
To: andrew, emaste, dim
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-tool
emaste accepted this revision.
This revision is now accepted and ready to land.
BRANCH
/head
INLINE COMMENTS
lib/clang/include/AArch64GenAsmMatcher.inc:1 Please unexpand these before
checkin.
SVN does the expansion on checkout. I'm not sure if they're collapsed on
checkin, or stored ve
emaste added a comment.
>>! In D1446#10, @andrew wrote:
> We will also need llvm r92 to build the kernel without using floating
> point registers.
Can we bring this one directly into HEAD?
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1446
To: andrew, emaste, dim
Cc: freeb
emaste added a comment.
I imported this change then merged to my arm64 branch and it looks fine to me.
REVISION DETAIL
https://reviews.freebsd.org/D1446
To: dim, andrew, emaste
Cc: freebsd-toolchain, emaste
___
freebsd-toolchain@freebsd.org mailing l
emaste added a subscriber: emaste.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1468
To: andrew, loos, sbruno, rpaulo, ian, dim, imp
Cc: emaste, freebsd-toolchain
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/
emaste added a comment.
> Apart from the bit of ugliness in lib/Makefile
Perhaps the ugliness needs a comment, at least.
Also a BSD.debug.mk entry for `WITH_DEBUG_FILES=yes`?
REVISION DETAIL
https://reviews.freebsd.org/D1505
To: dim, andrew, bapt, imp, emaste
Cc: freebsd-toolchain
___
1 - 100 of 171 matches
Mail list logo
