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 (226 w, 5 d)

Recent Activity

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

May 22 2018

hjl.tools retitled D47165: sanitizer: Don't intercept ustat for Linux from [PATCH] sanitizer: Don't intercept ustat for Linux to sanitizer: Don't intercept ustat for Linux.
May 22 2018, 6:20 AM

May 21 2018

hjl.tools created D47165: sanitizer: Don't intercept ustat for Linux.
May 21 2018, 3:29 PM

Apr 30 2018

hjl.tools added inline comments to D46181: [X86][CET] Shadow stack fix for setjmp/longjmp.
Apr 30 2018, 6:12 AM

Feb 17 2018

hjl.tools added a comment to D43383: [llvm-mc] - Produce R_X86_64_PLT32 for "call/jmp foo"..

Does this change add reference to _GLOBAL_OFFSET_TABLE_?

Feb 17 2018, 6:43 AM

Oct 15 2017

hjl.tools added a comment to D38907: Give .note.gnu.build-id section alignment 4.

See:

Oct 15 2017, 6:17 PM · lld

Mar 13 2017

hjl.tools added a comment to D30049: x86 interrupt calling convention: re-align stack pointer on 64-bit if an error code was pushed.

No, there is no need to realign stack in 64-bit mode.

I'm not sure if I understand you correctly. Yes, there is no need to dynamically realign the stack in 64-bit mode since the CPU aligns the stack on a 16 byte boundary on interrupt entry. However, for some exceptions, the CPU pushes an 8 byte error code afterwards. In that case it is necessary to subtract another 8 bytes from RSP to restore the 16-byte alignment.

Mar 13 2017, 11:23 AM

Feb 21 2017

hjl.tools added a comment to D30049: x86 interrupt calling convention: re-align stack pointer on 64-bit if an error code was pushed.

No, there is no need to realign stack in 64-bit mode.

Feb 21 2017, 8:45 AM

Aug 16 2016

hjl.tools updated the diff for D23575: Preserve BasePtr for LEA64_32r .

Updated with comments from Michael.

Aug 16 2016, 1:01 PM
hjl.tools retitled D23575: Preserve BasePtr for LEA64_32r from to Preserve BasePtr for LEA64_32r .
Aug 16 2016, 12:10 PM

Aug 8 2016

hjl.tools added a comment to D22045: [X86] Support of no_caller_saved_registers attribute (Clang part).

For what it is worth, this certainly seems to be misnamed. By nature, if it doesn't preserve at least the stack pointer, there is no way to recover on return, right?

This is the best name we came up with and has been implemented in GCC.

What version of GCC supports this attribute? I tried 6.1.0 and it is unknown there.

Aug 8 2016, 8:50 AM
hjl.tools added a comment to D22045: [X86] Support of no_caller_saved_registers attribute (Clang part).

For what it is worth, this certainly seems to be misnamed. By nature, if it doesn't preserve at least the stack pointer, there is no way to recover on return, right?

Aug 8 2016, 8:37 AM

Aug 3 2016

hjl.tools added a comment to D23126: lld: Add EM_IAMCU support .
In D23126#504970, @ruiu wrote:

LGTM

Aug 3 2016, 11:25 AM · lld
hjl.tools retitled D23126: lld: Add EM_IAMCU support from to lld: Add EM_IAMCU support .
Aug 3 2016, 11:13 AM · lld

Jul 26 2016

hjl.tools added inline comments to D22827: [test/gold] Add gold test subdirectory tests needing v1.12 (or higher).
Jul 26 2016, 1:36 PM

Jul 25 2016

hjl.tools added a comment to D22045: [X86] Support of no_caller_saved_registers attribute (Clang part).

no_caller_saved_registers attribute can be used with any calling conventions.

Jul 25 2016, 8:15 AM
hjl.tools added inline comments to D22044: [X86] Support of no_caller_saved_registers attribute (LLVM part).
Jul 25 2016, 8:12 AM

Jul 12 2016

hjl.tools added inline comments to D22288: ldd: Add GotEntrySize/GotPltEntrySize to ELF target .
Jul 12 2016, 5:40 PM · lld
hjl.tools updated D22268: lld: Add -m elf32_x86_64 .
Jul 12 2016, 4:13 PM · lld
hjl.tools retitled D22288: ldd: Add GotEntrySize/GotPltEntrySize to ELF target from to ldd: Add GotEntrySize/GotPltEntrySize to ELF target .
Jul 12 2016, 4:07 PM · lld
hjl.tools retitled D22287: lld: Add ILP32 support to X86_64TargetInfo from to lld: Add ILP32 support to X86_64TargetInfo .
Jul 12 2016, 4:05 PM · lld
hjl.tools updated the diff for D22268: lld: Add -m elf32_x86_64 .

This patches fixes PLTREL. But it doesn't generate working x32 binaries.

Jul 12 2016, 4:02 PM · lld
hjl.tools retitled D22268: lld: Add -m elf32_x86_64 from to lld: Add -m elf32_x86_64 .
Jul 12 2016, 10:22 AM · lld

May 15 2016

hjl.tools added a comment to D20272: [ELF] - Support of compressed input sections implemented..

Until the content is copied to the output, I think we don't have to uncompress inputs. Do you think you can do it lazily?

May 15 2016, 8:15 AM

May 6 2016

hjl.tools updated the diff for D16474: Use PC-relative address for x32 TLS address .
May 6 2016, 1:55 PM
hjl.tools added a comment to D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE.

Is this still a problem with linkers which can convert load via GOT slot into load
immediate?

May 6 2016, 5:54 AM

Apr 27 2016

hjl.tools added a comment to D19528: [ELF] - Implemented -z combrelocs/nocombreloc..

I have found -z nocombreloc useful to debug ld and ld.so.

This can be really one-line-easy to add in lld, if restoring the original
order of relocations can be useful for something.
But again, gold does ignore that option, so it seems usecase
is very specific.

Apr 27 2016, 5:30 AM
hjl.tools added a comment to D19528: [ELF] - Implemented -z combrelocs/nocombreloc..

I have found -z nocombreloc useful to debug ld and ld.so.

Apr 27 2016, 5:01 AM

Apr 26 2016

hjl.tools added a comment to D19125: Enable __float128 on X86 and SystemZ.

Should it be handled similar to int128? Only targets which support float128
override hasFloat128Type without adding HasFloat128.

Apr 26 2016, 5:33 AM

Apr 14 2016

hjl.tools added a comment to D19040: Remove unnecessary load via GOT when accessing globals with PIE in x86_64.

Does it fix

Apr 14 2016, 3:59 PM
hjl.tools added a comment to D19125: Enable __float128 on X86 and SystemZ.

The current x86 psABIs are available from

Apr 14 2016, 10:51 AM
hjl.tools added a comment to D19125: Enable __float128 on X86 and SystemZ.

Why not enable __float128 on Linux/i386, which is defined in
the current i386 psABI?

Apr 14 2016, 10:43 AM

Mar 29 2016

hjl.tools added a comment to D18566: [x86] use SSE/AVX ops for non-zero memsets (PR27100).

Oops. I meant

Mar 29 2016, 1:19 PM
hjl.tools added a comment to D18566: [x86] use SSE/AVX ops for non-zero memsets (PR27100).

For 16-byte memset, we can generate

Mar 29 2016, 1:16 PM

Mar 11 2016

hjl.tools added a comment to D18091: ELF: Implement --build-id..

FYI, here is the spec for .note.gnu.build-id section:

Mar 11 2016, 12:02 PM

Feb 4 2016

hjl.tools added a comment to D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union.

Empty struct/union should be passed and returned as void for all IA psABs.

Feb 4 2016, 10:26 AM
hjl.tools added a comment to D16886: Fix struct __emutls_control to match GCC.

Can you check it in for me? Thanks.

Feb 4 2016, 9:58 AM
hjl.tools retitled D16886: Fix struct __emutls_control to match GCC from to Fix struct __emutls_control to match GCC.
Feb 4 2016, 7:43 AM

Feb 3 2016

hjl.tools added a comment to D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union.

I am planning to update i386, x86-64 and IA MCU psABIs to address how to
pass and return C++ empty class after resolving:

Feb 3 2016, 12:49 PM

Feb 2 2016

hjl.tools added a comment to D16805: Cast the fifth arg to mremap to void * .

Please check it in for me. Thanks.

Feb 2 2016, 10:19 AM
hjl.tools added a comment to D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union.

Why should empty structs and unions) be return in memory? I don't remember
I called for it in MCU psABI.

Feb 2 2016, 9:13 AM
hjl.tools retitled D16805: Cast the fifth arg to mremap to void * from to Cast the fifth arg to mremap to void * .
Feb 2 2016, 7:44 AM

Feb 1 2016

hjl.tools added a comment to D16779: Fix attribute((mode([word|unwind_word]))) for x32 .

Yes, please. Thanks.

Feb 1 2016, 10:40 AM
hjl.tools retitled D16779: Fix attribute((mode([word|unwind_word]))) for x32 from to Fix attribute((mode([word|unwind_word]))) for x32 .
Feb 1 2016, 10:28 AM

Jan 25 2016

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

Since llvm doesn't support TLS for x32:

Jan 25 2016, 1:07 PM
hjl.tools added a comment to D16469: Pass --wrap=pthread_create to linker for -fsplit-stack.

Can you check it in for me? Thanks.

Jan 25 2016, 10:09 AM

Jan 22 2016

hjl.tools updated the diff for D16469: Pass --wrap=pthread_create to linker for -fsplit-stack.

Add a testcase.

Jan 22 2016, 1:26 PM
hjl.tools updated the diff for D16474: Use PC-relative address for x32 TLS address .

Use Subtarget->is32Bit()) instead. The full function now is:

Jan 22 2016, 12:27 PM
hjl.tools retitled D16474: Use PC-relative address for x32 TLS address from to Use PC-relative address for x32 TLS address .
Jan 22 2016, 10:45 AM
hjl.tools retitled D16469: Pass --wrap=pthread_create to linker for -fsplit-stack from to Pass --wrap=pthread_create to linker for -fsplit-stack.
Jan 22 2016, 10:36 AM

Nov 18 2015

hjl.tools added a comment to D12498: X86: add an interrupt calling convention.

The current interrupt spec is

Nov 18 2015, 1:51 PM

Oct 29 2015

hjl.tools added a comment to D13481: [X86] Call locally defined function directly for PIE .

This seems to work:

Oct 29 2015, 7:19 AM
hjl.tools updated the diff for D13481: [X86] Call locally defined function directly for PIE .

I added a helper function, ClassifyGlobalFunctionReference, and used
it in both places. I was looking for a predicate to tell me if a symbol is
defined. The symbol can be weak or linkonce. Should I use
!isDeclarationForLinker instead?

Oct 29 2015, 6:24 AM

Oct 27 2015

hjl.tools added a comment to D14112: Fixed : rL251291: Loop Vectorizer - skipping "bitcast" before GEP.

Does this fix

Oct 27 2015, 12:01 PM

Oct 9 2015

hjl.tools set the repository for D13481: [X86] Call locally defined function directly for PIE to rL LLVM.
Oct 9 2015, 9:29 AM
hjl.tools updated the diff for D13481: [X86] Call locally defined function directly for PIE .

Update to a single testcase with

Oct 9 2015, 9:28 AM

Oct 8 2015

hjl.tools added a comment to D13481: [X86] Call locally defined function directly for PIE .

I tried putting

Oct 8 2015, 10:09 AM

Oct 7 2015

hjl.tools added a reviewer for D13481: [X86] Call locally defined function directly for PIE : DavidKreitzer.
Oct 7 2015, 3:54 AM

Oct 6 2015

hjl.tools added reviewers for D13481: [X86] Call locally defined function directly for PIE : echristo, dexonsmith.
Oct 6 2015, 2:30 PM
hjl.tools retitled D13481: [X86] Call locally defined function directly for PIE from to [X86] Call locally defined function directly for PIE .
Oct 6 2015, 1:07 PM

Sep 8 2015

hjl.tools added a comment to D12346: x32. Fixes a bug in how struct va_list is initialized in x32.

I just wanted to point it out the related x32 issue. I opened those x32 bugs
which should be easy to fix:

Sep 8 2015, 10:17 AM

Sep 3 2015

hjl.tools added a comment to D12498: X86: add an interrupt calling convention.

I proposed a different approach:

Sep 3 2015, 10:40 AM

Aug 31 2015

hjl.tools added a comment to D12346: x32. Fixes a bug in how struct va_list is initialized in x32.

You missed:

Aug 31 2015, 6:57 PM

Apr 10 2015

hjl.tools added inline comments to D8970: Split Mprotect into MmapNoAccess and MprotectNoAccess to be more portable.
Apr 10 2015, 2:50 PM

Mar 12 2015

hjl.tools added a comment to D8233: Fix the remainder of PR22762 (GDB is crashing on DW_OP_piece being used inside of DW_AT_frame_base) .

[Just noticed that I forgot to rename MayUsePieceForSubRegMask in DwarfCompileUnit.]

The problem is that the TargetRegisterInfo tells us that the frame register is ebp, for which there is no separate register number, so it must be constructed from rbp. The DWARF backend doesn't know about what is in the upper half of rbp so it must mask out the upper bits.

Mar 12 2015, 2:48 PM
hjl.tools added a comment to D8233: Fix the remainder of PR22762 (GDB is crashing on DW_OP_piece being used inside of DW_AT_frame_base) .

Maybe it is specific to x32. When a register is used as frame register,
the upper 32 bits are guaranteed to zero by hardware. We don't need
DW_OP_piece to describe the lower 32 bits of a frame register.

Mar 12 2015, 2:19 PM