Page MenuHomePhabricator

hjl.tools (H.J Lu)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 11 2015, 7:59 AM (380 w, 2 d)

Recent Activity

Thu, May 5

hjl.tools committed rGb226894d475b: [sanitizer] Correct GetTls for x32 (authored by hjl.tools).
[sanitizer] Correct GetTls for x32
Thu, May 5, 1:56 PM · Restricted Project, Restricted Project
hjl.tools closed D125025: [sanitizer] Correct GetTls for x32.
Thu, May 5, 1:56 PM · Restricted Project, Restricted Project
hjl.tools requested review of D125025: [sanitizer] Correct GetTls for x32.
Thu, May 5, 10:46 AM · Restricted Project, Restricted Project

Wed, May 4

hjl.tools committed rGf52e365092aa: [sanitizer] Use newfstatat for x32 (authored by hjl.tools).
[sanitizer] Use newfstatat for x32
Wed, May 4, 3:56 PM · Restricted Project, Restricted Project
hjl.tools closed D124968: [sanitizer] Use newfstatat for x32.
Wed, May 4, 3:56 PM · Restricted Project, Restricted Project
hjl.tools requested review of D124968: [sanitizer] Use newfstatat for x32.
Wed, May 4, 3:08 PM · Restricted Project, Restricted Project

Apr 14 2022

hjl.tools added a comment to D122789: [compiler-rt] [scudo] Use -mcrc32 on x86 when available.

To kurly (original Gentoo reporter):

printf '#include <smmintrin.h>\n#include <stdint.h>\nuint32_t computeHardwareCRC32(uint32_t Crc, uint32_t Data) { return _mm_crc32_u32(Crc, Data); }' > a.c
% clang -m32 -march=i686 -msse4.2 -c a.c  # seems to compile fine
% gcc -m32 -march=i686 -msse4.2 -c a.c
% gcc -m32 -march=i686 -mcrc32 -c a.c
In file included from a.c:1:
a.c: In function ‘computeHardwareCRC32’:
/usr/lib/gcc/x86_64-linux-gnu/11/include/smmintrin.h:839:1: error: inlining failed in call to ‘always_inline’ ‘_mm_crc32_u32’: target specific option mismatch
  839 | _mm_crc32_u32 (unsigned int __C, unsigned int __V)
      | ^~~~~~~~~~~~~
a.c:3:69: note: called from here
    3 | uint32_t computeHardwareCRC32(uint32_t Crc, uint32_t Data) { return _mm_crc32_u32(Crc, Data); }
      |                                                                     ^~~~~~~~~~~~~~~~~~~~~~~~

I have some older GCC and latest GCC (2022-04, multilib), gcc -m32 -march=i686 -msse4.2 -c a.c builds while -mcrc32 doesn't.

I suspect we should revert the -mcrc32 change. The __CRC32__ macro may be fine.

Thanks for the infromation. I got the same result. That's weird. I believe at some point, GCC supported -mcrc32. @hjl.tools, did GCC intentionally remove the support for -mcrc32?

Apr 14 2022, 8:31 AM · Restricted Project, Restricted Project

Nov 3 2021

hjl.tools added inline comments to D112588: [sanitizer] Switch dlsym hack to internal_allocator.
Nov 3 2021, 12:45 PM · Restricted Project

Oct 27 2021

hjl.tools added reviewers for D112588: [sanitizer] Switch dlsym hack to internal_allocator: xiongji90, MaskRay.
Oct 27 2021, 9:05 PM · Restricted Project
hjl.tools updated the diff for D112588: [sanitizer] Switch dlsym hack to internal_allocator.
Oct 27 2021, 4:42 AM · Restricted Project

Oct 26 2021

hjl.tools requested review of D112588: [sanitizer] Switch dlsym hack to internal_allocator.
Oct 26 2021, 6:03 PM · Restricted Project

Oct 8 2021

hjl.tools added inline comments to D111185: Reland [sanitizer] Support Intel CET.
Oct 8 2021, 10:25 AM · Restricted Project
hjl.tools committed rGc960c8c33997: Reland [sanitizer] Support Intel CET (authored by hjl.tools).
Reland [sanitizer] Support Intel CET
Oct 8 2021, 10:23 AM
hjl.tools closed D111185: Reland [sanitizer] Support Intel CET.
Oct 8 2021, 10:23 AM · Restricted Project
hjl.tools updated the diff for D111185: Reland [sanitizer] Support Intel CET.
Oct 8 2021, 6:05 AM · Restricted Project

Oct 7 2021

hjl.tools added inline comments to D111185: Reland [sanitizer] Support Intel CET.
Oct 7 2021, 9:12 PM · Restricted Project

Oct 6 2021

hjl.tools added a comment to D111185: Reland [sanitizer] Support Intel CET.

This is causing problems with gcc versions that don't have cet.h yet. I think cet.h wasn't added until gcc 8.

Please try this:

Thank you. Are you planning to push this patch to main? This is affecting one of our internal bots that's building the main branch, so either maskray's solution or yours would work if it goes into main.

Oct 6 2021, 4:35 PM · Restricted Project
hjl.tools added a comment to D111185: Reland [sanitizer] Support Intel CET.

This is causing problems with gcc versions that don't have cet.h yet. I think cet.h wasn't added until gcc 8.

Oct 6 2021, 4:24 PM · Restricted Project
hjl.tools added a comment to D111185: Reland [sanitizer] Support Intel CET.

Thanks!

Instead of creating a new diff, you may change the local git description, then run arc diff --verbatim --head=head 'HEAD^' to update the Differential's subject.

Some intro to arc (https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-command-line)

Oct 6 2021, 10:38 AM · Restricted Project
hjl.tools committed rGfdf4c035225d: [sanitizer] Support Intel CET (authored by hjl.tools).
[sanitizer] Support Intel CET
Oct 6 2021, 10:14 AM
hjl.tools closed D111185: Reland [sanitizer] Support Intel CET.
Oct 6 2021, 10:14 AM · Restricted Project

Oct 5 2021

hjl.tools abandoned D110999: [compiler-rt] Support Intel CET.

[compiler-rt] Support Intel CET

compiler-rt consists of sanitizers, builtins (similar to libgcc), xray, orc (for JIT), and a bunch of other things.
If this is for sanitizer functions which may be called indirectly, using a [sanitizer] tag may be better.

Oct 5 2021, 3:00 PM
hjl.tools requested review of D111185: Reland [sanitizer] Support Intel CET.
Oct 5 2021, 2:57 PM · Restricted Project

Oct 4 2021

hjl.tools abandoned D110998: [HWASan] Apply kTagMask on kFallbackFreeTag.

I deliberately chose not to mask the fallback tag.

It's never valid to access freed memory anyway, so we can keep a full 8 bit tag to reduce the chance of a false negative.

Oct 4 2021, 6:37 AM

Oct 2 2021

hjl.tools requested review of D110999: [compiler-rt] Support Intel CET.
Oct 2 2021, 10:58 AM
hjl.tools requested review of D110998: [HWASan] Apply kTagMask on kFallbackFreeTag.
Oct 2 2021, 10:52 AM

Sep 14 2021

hjl.tools added a comment to D108643: Introduce _BitInt, deprecate _ExtInt.

The choice that high bits are unspecified rather than extended is an interesting one. Can you speak to that? That's good for +, -, *, &, |, ^, <<, and narrowing conversions, but bad for ==, <, /, >>, and widening conversions.

I've added @hjl.tools to the review for his opinions, as he was the primary driver for the x64 ABI proposal. HJ, can you help me out here?

Please follow up x86-64 psABI proposal with any feedbacks:

https://groups.google.com/g/x86-64-abi/c/XQiSj-zU3w8

We don't have feedback yet, @hjl.tools; we're asking for rationale on the behavior of unused bits in the proposed psABI for x86-64. Can you help us understand why the bits are unspecified rather than extended and whether there are potential performance concerns from this decision (before it gets solidified)? Thanks!

Sep 14 2021, 7:55 AM · Restricted Project, Restricted Project

Sep 9 2021

hjl.tools added a comment to D108643: Introduce _BitInt, deprecate _ExtInt.

The choice that high bits are unspecified rather than extended is an interesting one. Can you speak to that? That's good for +, -, *, &, |, ^, <<, and narrowing conversions, but bad for ==, <, /, >>, and widening conversions.

I've added @hjl.tools to the review for his opinions, as he was the primary driver for the x64 ABI proposal. HJ, can you help me out here?

Sep 9 2021, 9:33 AM · Restricted Project, Restricted Project

Aug 25 2021

hjl.tools added inline comments to D105462: [X86] Add CRC32 feature..
Aug 25 2021, 7:46 AM · Restricted Project, Restricted Project

Jul 29 2021

hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 29 2021, 7:56 AM · Restricted Project, Restricted Project

Jul 28 2021

hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 28 2021, 6:29 AM · Restricted Project, Restricted Project

Jul 27 2021

hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 27 2021, 6:30 PM · Restricted Project, Restricted Project

Jul 21 2021

hjl.tools added inline comments to D105462: [X86] Add CRC32 feature..
Jul 21 2021, 10:11 AM · Restricted Project, Restricted Project
hjl.tools added inline comments to D105462: [X86] Add CRC32 feature..
Jul 21 2021, 5:24 AM · Restricted Project, Restricted Project

Jul 15 2021

hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 15 2021, 6:02 AM · Restricted Project, Restricted Project
hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 15 2021, 5:56 AM · Restricted Project, Restricted Project

Jul 14 2021

hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 14 2021, 7:19 AM · Restricted Project, Restricted Project
hjl.tools added inline comments to D105968: [libunwind][CET] Support exception handling stack unwind in CET environment.
Jul 14 2021, 5:23 AM · Restricted Project, Restricted Project

Jul 6 2021

hjl.tools added inline comments to D105462: [X86] Add CRC32 feature..
Jul 6 2021, 8:19 AM · Restricted Project, Restricted Project
hjl.tools added inline comments to D105462: [X86] Add CRC32 feature..
Jul 6 2021, 8:15 AM · Restricted Project, Restricted Project

Jun 30 2021

hjl.tools added a comment to D104230: [gold] Release input files in claim_file.

Please open a binutils bug with a testcase and CC me. I will take a look.

Jun 30 2021, 10:29 AM · Restricted Project

May 13 2021

hjl.tools added a comment to D102446: [PATCH] [sanitizer] Use size_t on g_tls_size.

LGTM.

May 13 2021, 4:30 PM · Restricted Project
hjl.tools requested review of D102446: [PATCH] [sanitizer] Use size_t on g_tls_size.
May 13 2021, 2:52 PM · Restricted Project

Apr 1 2021

hjl.tools added a comment to D99708: [X86] Enable compilation of user interrupt handlers..

A user interrupt is different than a regular interrupt right? It doesn't make sense that we would change the behavior of the interrupt calling convention just because the the user interrupt instructions are enabled. That would occur just from passing a -march for a newer CPU wouldn't it?

Maybe need support another attribute "attribute ((user_interrupt))" for functions? However this is what gcc does (https://gcc.godbolt.org/z/8ojTMG6bT).

Since there won't be both user interrupt handler and kernel interrupt handler in the source, there is no need for another
attribute. We discussed that kernel might need to use UINTR instructions. We decided that kernel could use inline asm
statements if needed.

So if write kernel code and compile with -march=haswell today, I get IRET. If tomorrow I change my command line to -march=sapphirerapids, now my kernel interrupt code generates user interrupt instructions. That seems surprising.

-mcmodel=kernel should disable uiret.:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99870

That makes sense. Can we put that in this patch?

Apr 1 2021, 2:15 PM · Restricted Project, Restricted Project
hjl.tools added a comment to D99708: [X86] Enable compilation of user interrupt handlers..

A user interrupt is different than a regular interrupt right? It doesn't make sense that we would change the behavior of the interrupt calling convention just because the the user interrupt instructions are enabled. That would occur just from passing a -march for a newer CPU wouldn't it?

Maybe need support another attribute "attribute ((user_interrupt))" for functions? However this is what gcc does (https://gcc.godbolt.org/z/8ojTMG6bT).

Since there won't be both user interrupt handler and kernel interrupt handler in the source, there is no need for another
attribute. We discussed that kernel might need to use UINTR instructions. We decided that kernel could use inline asm
statements if needed.

So if write kernel code and compile with -march=haswell today, I get IRET. If tomorrow I change my command line to -march=sapphirerapids, now my kernel interrupt code generates user interrupt instructions. That seems surprising.

Apr 1 2021, 9:31 AM · Restricted Project, Restricted Project
hjl.tools added a comment to D99708: [X86] Enable compilation of user interrupt handlers..

A user interrupt is different than a regular interrupt right? It doesn't make sense that we would change the behavior of the interrupt calling convention just because the the user interrupt instructions are enabled. That would occur just from passing a -march for a newer CPU wouldn't it?

Maybe need support another attribute "attribute ((user_interrupt))" for functions? However this is what gcc does (https://gcc.godbolt.org/z/8ojTMG6bT).

Apr 1 2021, 8:54 AM · Restricted Project, Restricted Project

Dec 16 2020

hjl.tools added a comment to D78564: [i386] Modify the alignment of __m128/__m256/__m512 vector type according i386 abi..

No. I think this patch can only fix part of the issue.

Dec 16 2020, 10:38 PM · Restricted Project
hjl.tools added a comment to D78564: [i386] Modify the alignment of __m128/__m256/__m512 vector type according i386 abi..

Does this fix https://github.com/golang/go/issues/42440?

Dec 16 2020, 7:08 AM · Restricted Project

Nov 29 2020

hjl.tools added a comment to D16474: Use PC-relative address for x32 TLS address.

LLVM ERROR: Cannot select: 0x29507a0: ch,glue = X86ISD::TLSADDR 0x28fc140, TargetGlobalTLSAddress:i32<i32* @x> 0 [TF=7]

This still happens with current LLVM. If we can push the fix for that first (presumably you fixed this already on your old branch), we could then include your test case in this diff.

Nov 29 2020, 6:08 AM · Restricted Project

Nov 28 2020

hjl.tools added a comment to D16474: Use PC-relative address for x32 TLS address.

My old x32 patches are at https://github.com/hjl-tools/llvm-x32-old/tree/hjl/x32/2016-09-01

Nov 28 2020, 7:48 AM · Restricted Project

Nov 14 2020

hjl.tools added a comment to D91338: [X86] Zero-extend pointers to i64 for x86_64.

It is required for ILP32 since many system calls are shared between ILP32 and LP64.
Here is my x32 port from 2016.

Thanks H.J. It's amazing you already did many works on x32 support. But these patches seem not been merged to mainline. What's the reason for not merging them? Does that mean the trunk code still has some flaws on x32 ABI supporting?

Nov 14 2020, 6:51 PM · Restricted Project
hjl.tools added a comment to D91338: [X86] Zero-extend pointers to i64 for x86_64.

Hi Harald, thanks for thoroughly answering my questions. I still have doubts intention of this patch. Is there any bug related to it?

I run an x32 system. Things work well for things built with GCC, but break badly when using LLVM, because the ABI as implemented is incompatible between GCC and LLVM, as GCC-generated code will sometimes assume that the high bits of pointer parameters have been zeroed out as required by the ABI. This is especially visible when using Rust applications, as the Rust compiler is LLVM-based but most of the rest of my system is built with GCC. Pretty much any non-trivial Rust application crashes, for instance ripgrep, or the Rust compiler itself.

IMHO, the ILP32 mode is designed for performance which always assumes the address bit 63~32 all zero and uses 32 bits register to reduce code size.

Nov 14 2020, 7:04 AM · Restricted Project

May 19 2020

hjl.tools added a comment to D79617: Add cet.h for writing CET-enabled assembly code.

I would like a specification for this header to be added somewhere. We shouldn't be implementing random things with no specification. (Suppose someone claims that our <cet.h> is wrong in some way. How would we know whether they're right?)

Ideally, I'd also like this header to be installed somewhere where we look for assembler-with-cpp preprocessing but not for regular compilation; it doesn't make sense to me to pollute the header namespace for all C and C++ compilations with a header that is not meaningful in C and C++. But knowing whether that change is correct depends on having, you know, a specification.

May 19 2020, 6:43 PM · Restricted Project

May 11 2020

hjl.tools added a comment to D79617: Add cet.h for writing CET-enabled assembly code.

Refine the Macro _CET_ENDBR

May 11 2020, 5:19 AM · Restricted Project

May 10 2020

hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 10 2020, 9:17 PM · Restricted Project
hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 10 2020, 7:09 PM · Restricted Project

May 9 2020

hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 9 2020, 4:45 AM · Restricted Project

May 8 2020

hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 8 2020, 6:49 PM · Restricted Project
hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 8 2020, 4:15 AM · Restricted Project
hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 8 2020, 4:15 AM · Restricted Project

Apr 21 2020

hjl.tools added a comment to D78564: [i386] Modify the alignment of __m128/__m256/__m512 vector type according i386 abi..

I'm not sure this is right. _m512 is just a typedef to a 64 byte vector_size attribute. This patch changes the behavior of using 64 byte vector_size on an sse/avx target. Prior to avx512 existing an avx target would pass a 512 bit vector 32 byte aligned. It does't make sense to me to change the alignment on an avx target just because avx512 exists, but isn't enabled.

If we use an library function which passing __m512 on stack(such as variadic function) compiled with avx512 but the caller compiled without avx512, this will cause run fail. But actually, when parameters passed by registers, it will cause run fail too because caller and callee use different register. Therefore, it is hard to say whether it is reasonable to align to 64 bytes.

Apr 21 2020, 6:57 PM · Restricted Project

Apr 9 2020

hjl.tools added inline comments to D77124: Handle CET for -exception-model sjlj.
Apr 9 2020, 4:51 AM · Restricted Project

Apr 2 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Look good to me.

Apr 2 2020, 6:27 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

It looks very confusing. Can you create a diff against master branch, not your last change?

Apr 2 2020, 10:17 AM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
  1. Sync with HJ's large code changes in https://github.com/hjl-tools/llvm-project/commit/6a85ba472143c91e5686e1f0faf7fea7b4f0e350
  2. Add Eli's test in https://bugs.llvm.org/show_bug.cgi?id=45364 to llc test and JIT test.

For Large code model:
The compiler is required to use the movabs instruction, as in the medium code model, even for dealing with addresses inside the text section.
Additionally, indirect branches are needed when branching to addresses whose offset from the current instruction pointer is unknown.

Apr 2 2020, 8:06 AM · Restricted Project

Mar 31 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

I find your patch will not deal with internal function.
I tested GCC, It really will generate endbr for static functions:

gcc version 9.3.1 20200317 (Red Hat 9.3.1-1) (GCC)
 [xiangzh1@gnu-tgl-1 ~/tmp]$cat t.c
extern int foo2(int a);

extern int foo2(int a)
{
  return a*6;
}

static int foo3(int a)
{
  return a*7;
}

int foo(int a){
//  int (*pf3)(int) = foo;
//  int b = foo2(a) +foo3(a) + pf3(a);
  int b = foo2(a) +foo3(a);
  return b;
}
 [xiangzh1@gnu-tgl-1 ~/tmp]$
[xiangzh1@gnu-tgl-1 ~/tmp]$gcc -fcf-protection t.c -S -o t.s
Mar 31 2020, 8:55 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

@efriedma Put the https://bugs.llvm.org/show_bug.cgi?id=45364 test into X86/indirect-branch-tracking.ll @test5

Mar 31 2020, 10:33 AM · Restricted Project

Mar 30 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

If "1 Check CET in JIT instead of checking -fcf-protection-branch" can't let VNC passed. The crash must happen at "Take address of a internal function."

This is not a IBT problem only for JIT, but also the static llvm compiler, e.g. llc.
And it may unable to track these calling through function address, because these function address may be calculated out in runtime or written in a big table.

Mar 30 2020, 4:50 AM · Restricted Project

Mar 29 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

My changes fixed the VNC crash. But there is no testcase to show why my patches are needed.

Your tests failed on CET machine
and the existing llvm unit tests also failed the on the CET machine
They are the same reason for lack of endbr* in JIT.
So I think the existing llvm unit tests is enough for this patch.

Mar 29 2020, 8:52 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Please take a look at

https://gitlab.freedesktop.org/mesa/mesa

to see how LLVM JIT is used and extract a testcase from it.

1, Does it in your commits? I find 2 your commits without the JIT tests.

Mar 29 2020, 7:15 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Please take a look at

Mar 29 2020, 4:46 AM · Restricted Project

Mar 28 2020

hjl.tools added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Mar 28 2020, 4:08 PM · Restricted Project
hjl.tools added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Mar 28 2020, 3:46 AM · Restricted Project

Feb 5 2020

hjl.tools added a comment to D74006: [MC][ELF] Make linked-to symbol name part of ELFSectionKey.
.section .foo,"o",@progbits,foo  # first in the output section .foo due to stable sort
.byte 0

.section .foo,"o",@progbits,bar  # second
.byte 1

This is what lld currently does. It will be nice to get a sign-up from GNU ld. An alternative choice is that users should not rely on the order. I'm inclined to define an order here.

Feb 5 2020, 10:15 AM · Restricted Project

Mar 7 2019

hjl.tools added a comment to D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD.

@xiangzhangllvm, a question for you not directly related to the patch but I suspect you might be best suited to find an answer: how do we test CET support today? We started trying to add CET to FreeBSD some time ago but have no way to test any work that we do.

Mar 7 2019, 7:48 PM · Restricted Project, lld

Mar 1 2019

hjl.tools added a comment to D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD.

Add -z force-cet option to force enable CET.
But if we do not use this option, CET will also try to work unless meet the conditions of no satisfaction.

Mar 1 2019, 4:41 AM · Restricted Project, lld

Feb 28 2019

hjl.tools committed rGfadb22f4e2d6: Revert "Revert "[sanitizers] Restore internal_readlink for x32"" (authored by hjl.tools).
Revert "Revert "[sanitizers] Restore internal_readlink for x32""
Feb 28 2019, 11:34 AM
hjl.tools created D58788: Revert "Revert "[sanitizers] Restore internal_readlink for x32"".
Feb 28 2019, 9:54 AM · Restricted Project, Restricted Project

Feb 27 2019

hjl.tools added a comment to D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD.

Thanks for putting this feature forward. I've not had a chance to go through everything in detail but I thought it would be important to mention that AArch64 has a similar set of features (Pointer Authentication PAC and Branch Target Identification BTI) that are going to use .note.gnu.property sections with GNU_PROPERTY_AARCH64_FEATURE_1_AND (same meaning as GNU_PROPERTY_X86_FEATURE_1_AND), with two associated feature bits GNU_PROPERTY_AARCH64_FEATURE_1_BTI and GNU_PROPERTY_AARCH64_FEATURE_1_PAC. AArch64 does need a modified PLT entry to make this work but it doesn't use a .splt, in effect an extra instruction at the top of the PLT if BTI is used and one at the end if PAC is used, or both if both BTI and PAC are needed. Given that we will have at least two targets implementing a similar mechanism but with target specific details then we'll either need to make it my responsibility to generalise the .note.gnu.property implementation so that it can support both AArch64 and X86, or we make it generic from the start. The main difference for AArch64 is that there are two independent feature bits to track.

In the case of AArch64 it is important for the program loader to only enable the BTI/PAC feature for the process if the whole program has been compiled/assembled to support it. Our prior experience with assembler files in particular is that it is very easy to get a single .s file added to a build that is harmless but doesn't have the .note.gnu.property set properly and a single one of these would be enough to clear all the features. Our thoughts were to add a command line option to force generation of the appropriate PLTs and the .note.gnu.property in the output file but to warn if an input file doesn't have the .note.gnu.property flag.

Feb 27 2019, 9:58 AM · Restricted Project, lld

Feb 21 2019

hjl.tools added a comment to D58413: [sanitizers] Restore internal_readlink for x32.
In D58413#1406201, @rnk wrote:

Of course the test fails, this always returns 0. Recommitting with the test disabled on Windows seems reasonable.

Feb 21 2019, 11:57 AM · Restricted Project, Restricted Project
hjl.tools added a comment to D58413: [sanitizers] Restore internal_readlink for x32.

It looks like that ReadBinaryNameCached doesn't work on Windows.
Someone who is familiar with Windows should take a look.

Feb 21 2019, 9:19 AM · Restricted Project, Restricted Project

Feb 20 2019

hjl.tools committed rG6716f4af81f6: [sanitizers] Restore internal_readlink for x32 (authored by hjl.tools).
[sanitizers] Restore internal_readlink for x32
Feb 20 2019, 3:43 AM

Feb 19 2019

hjl.tools updated the diff for D58413: [sanitizers] Restore internal_readlink for x32.
Feb 19 2019, 5:58 PM · Restricted Project, Restricted Project
hjl.tools added a comment to D58413: [sanitizers] Restore internal_readlink for x32.

See:

Feb 19 2019, 3:47 PM · Restricted Project, Restricted Project
hjl.tools created D58413: [sanitizers] Restore internal_readlink for x32.
Feb 19 2019, 3:38 PM · Restricted Project, Restricted Project

Nov 5 2018

hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

With both 3.3 and trunk (I don't have a 7.0 handy; I can build it if it would be helpful):

Please try clang 2.6 on both testcases.

From the releases:

23 Oct 2009 2.6

... why would you care about a 9 year old version of clang?

Nov 5 2018, 9:45 AM

Oct 31 2018

hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

With both 3.3 and trunk (I don't have a 7.0 handy; I can build it if it would be helpful):

Oct 31 2018, 3:30 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

No, AVX512 wasn't even announced when clang 3.3 came out.

Oct 31 2018, 1:27 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

I just tried clang 3.3, and as far as I can tell it behaves the same way as trunk.

If the argument is that we should be compatible with gcc on Linux, that's fine, but we should explicitly state that in a comment.

Oct 31 2018, 1:17 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

The ABI document before AVX was introduced didn't say anything at all about 256-bit vectors. So we're talking about compatibility with some other compiler. Which compiler?

Oct 31 2018, 12:46 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

Whatever you call it, the question remains; what specification and/or compiler are we trying to be compatible with?

Oct 31 2018, 12:24 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

As far as I know, according to the ABI docs, it's impossible to return a 256-bit vector from a function if AVX is disabled.

Given that we aren't rejecting the testcase, we're effectively implementing a new "no-AVX" ABI variant. That variant is not defined anywhere, so we might as well pick the fastest convention, returning the value in registers. I'm not sure why you would want to return the vector in memory instead.

Oct 31 2018, 12:17 PM
hjl.tools added inline comments to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..
Oct 31 2018, 2:56 AM

Jul 20 2018

hjl.tools updated the diff for D49608: Mark REAL(swapcontext) with indirect_return attribute on x86.

Remove the extra ")".

Jul 20 2018, 12:17 PM
hjl.tools updated the diff for D49608: Mark REAL(swapcontext) with indirect_return attribute on x86.

Added a __ has_attribute compatibility definition.

Jul 20 2018, 11:54 AM
hjl.tools created D49608: Mark REAL(swapcontext) with indirect_return attribute on x86.
Jul 20 2018, 10:33 AM

May 23 2018

hjl.tools added a comment to D47281: sanitizer: Use pre-computed size of struct ustat for Linux.

Can you check it in for me? Thanks.

May 23 2018, 3:57 PM
hjl.tools abandoned D47165: sanitizer: Don't intercept ustat for Linux.

Replaced by

May 23 2018, 2:02 PM
hjl.tools created D47281: sanitizer: Use pre-computed size of struct ustat for Linux.
May 23 2018, 2:00 PM
hjl.tools added a comment to D47165: sanitizer: Don't intercept ustat for Linux.

I tested it on Fedora 28 which has glibc 2.27. There is no regression, probably because there is no test.
We can a definition of sizeof(struct ustat) to sanitizer_common/sanitizer_platform_limits_posix.cc, which
doesn't depend on <sys/ustat.h>.

May 23 2018, 9:15 AM