User Details
- User Since
- Aug 30 2015, 11:51 AM (181 w, 1 d)
Today
<strings.h> should be included unconditionally.
Please enable the tests for NetBSD as well.
bcmp is BSD and it first appeard in 4.2BSD... it's not specific to GNU source but compat layer for BSD software.
Yesterday
Fri, Feb 15
@mgorny let's go through tech-kern@ and later checking FreeBSD/Darwin/OpenBSD. I think it's worth to clarify this in the documentation.
Thu, Feb 14
It looks good to me.
'attaching a debugger produces an observable side-effect (EINTR) in the debugged process is considered a bug by the linux kernel folks'
For EINTR we shall use llvm::sys::RetryAfterSignal
Tue, Feb 12
Short term this looks fine.
Sat, Feb 9
Fri, Feb 8
@labath our short-term goal is to enable execution of LLDB tests on the NetBSD buildbot. We are stuck temporarily with an older release of NetBSD on the machine for some time (1-2 months) so we need to live with it for now. No need to make it better than sufficient as of now.
I think that sigemptyset(2) is unsupported on Windows.
Thu, Feb 7
Tue, Feb 5
Sun, Feb 3
The NetBSD buildbot breaks in these tests now:
Sat, Feb 2
Fri, Feb 1
The NetBSD buildbot is affected and red for some time now.
Wed, Jan 30
chandlerc added a comment.
There was a long discussion between two NetBSD maintainers about this (both already in the reviewers list of this patch). I'm not sure if there is an existing thread that would be better to follow up on as opposed to starting a fresh thread.
If we pass flags from clang, we sacrifice:
@rui we need some resolution here. We have stronger feelings from the community to customize the linker directly based on detected triple.
Tue, Jan 29
I have got a scudo support patch for NetBSD locally.. but the original tests are havily prepared against GNU malloc. This makes me uncertain whether scudo really works. Are there plans to make the tests more generic?
Sun, Jan 27
Can we fix it for everybody? It's certainly not restricted to NetBSD.
Thu, Jan 24
NetBSD is affected in the same way.
Mon, Jan 21
Sun, Jan 20
Jan 18 2019
Jan 17 2019
Jan 15 2019
Jan 14 2019
Jan 11 2019
Actually probably Linux MIPS used it and some proprietary OSes.. but we skip them for now. Only FreeBSD sets OSABI in lld and uses an emulation name detection hack. Once we will get merged TripleTarget detection we can switch it to use proper Triple check.
@mgorny could you check if we can get crossbuilding functional for:
Please check these options in regression test-suite. There are also some missing entries and please add them too.
Jan 10 2019
What do you think about this new logic:
I understand the concerns, but lld is biased with being a Linux linker. We need to customize it (restore defaults?) for NetBSD.
Shouldn't the logic of emitting/not-emitting be based on findSection(".note.GNU-stack")? @mgorny can you please investigate it?
Actually looking at GNU ld(1) source code, the logic is a little bit more complex and it depends on more aspects like relocations.
Looks good, we don't GNU STACK on NetBSD.
@joerg if you think that this patch is OK, please click accept so we can be aware that this is what you want.
Jan 9 2019
Jan 8 2019
Jan 7 2019
On NetBSD the 'new' semantics was already implemented with 'old' RPATH. I don't know the timing whether there already existed RUNPATH, but the result is that we never implemented it and never needed it. The core of NetBSD was convinced to add an alias as it was very difficult in some examples (probably due to Rust) to rollback to 'old' RPATH.
Jan 6 2019
Jan 5 2019
I've grepped FreeBSD, OpenBSD and pkgsrc.
Reverted in r350477.
I'm going to revert it soon and see what happens. Please keep an eye on http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd8
Jan 4 2019
Jan 3 2019
Actually I think that we can handle two cases witch a combination of proposals:
- native mode
- cross mode
On 03.01.2019 23:15, Joerg Sonnenberger wrote: > On Thu, Jan 03, 2019 at 09:38:49PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote: >> I think that this place is not the right place to bash GNU ld for performance issues. > > I didn't. > >> I will refer just to slides and paper from Ian Lance Taylor to get overview why it is unacceptably slow: >> >> https://www.airs.com/ian/gold-slides.pdf >> https://ai.google/research/pubs/pub34417.pdf > > We all know that gold and lld are faster. It's a huge step from > "somewhat faster" to "unacceptably slow". But that's again a completely > separate topic.
On Thu, Jan 03, 2019 at 08:31:53PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:
krytarowski added a comment.
On 03.01.2019 21:19, Joerg Sonnenberger wrote:
On Thu, Jan 03, 2019 at 06:34:22PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:
krytarowski added a comment.
Actually I find it frustrating and unfair as GNU ld doesn't have builtin
knowledge either.. it's passed with gross 'super hack' comments from build scripts... but we are forced to push it to lld in order to move on.I'm puzzled. Seriously, when was the last time you actually checked how
much customization contains on a per-OS base in GNU ld? Yes, I'm including the various build scripts because GNU ld is generally build by a mix of hard-coded logic in the tool itself and various adjustments in the linker scripts it is shipped with. But they are all a builtin part of GNU ld as far as the end user is concerned. It is pretty much irrelevant from a point of functionality where that logic is, but skipping is a serious usability issue.Joerg
I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':
I think that ifdefining the linker options with __NetBSD__ is no-go.
We want to keep it disabled by default on NetBSD.. but it would be to keep dynamic detection of target NetBSD rather than hardcoded ifdef.
On 03.01.2019 21:19, Joerg Sonnenberger wrote:
On Thu, Jan 03, 2019 at 06:34:22PM +0000, Kamil Rytarowski via Phabricator via cfe-commits wrote:
krytarowski added a comment.
Actually I find it frustrating and unfair as GNU ld doesn't have builtin
knowledge either.. it's passed with gross 'super hack' comments from build scripts... but we are forced to push it to lld in order to move on.I'm puzzled. Seriously, when was the last time you actually checked how
much customization contains on a per-OS base in GNU ld? Yes, I'm
including the various build scripts because GNU ld is generally build by
a mix of hard-coded logic in the tool itself and various adjustments in
the linker scripts it is shipped with. But they are all a builtin part
of GNU ld as far as the end user is concerned. It is pretty much
irrelevant from a point of functionality where that logic is, but
skipping is a serious usability issue.Joerg
I'm referring to code '/usr/src/external/gpl3/binutils/usr.bin/ld/Makefile':