Page MenuHomePhabricator
Feed Advanced Search

Today

MaskRay added a comment to D92241: [compiler-rt] [builtins] Use _Float16 on extendhfsf2, truncdfhf2 __truncsfhf2 if available.

Is https://reviews.llvm.org/D91733#2407055 resolved?

Sat, Nov 28, 1:43 PM · Restricted Project
MaskRay accepted D92271: Implement computeHostNumHardwareThreads() for FreeBSD.

Looks great!

Sat, Nov 28, 12:51 PM · Restricted Project
MaskRay committed rGf502b14d40e7: [ARMAttributeParser] Correctly parse and print Tag_THUMB_ISA_use=3 (authored by LemonBoy).
[ARMAttributeParser] Correctly parse and print Tag_THUMB_ISA_use=3
Sat, Nov 28, 12:28 PM
MaskRay closed D90305: Correctly parse and print Tag_THUMB_ISA_use=3.
Sat, Nov 28, 12:28 PM · Restricted Project
MaskRay added inline comments to D92271: Implement computeHostNumHardwareThreads() for FreeBSD.
Sat, Nov 28, 12:24 PM · Restricted Project
MaskRay retitled D92259: [ELF] Make foo@@v1 resolve undefined foo@v1 from [ELF] Make foo@@v1 resolved undefined foo@v1 to [ELF] Make foo@@v1 resolve undefined foo@v1.
Sat, Nov 28, 1:02 AM · Restricted Project

Yesterday

MaskRay added a comment to D92259: [ELF] Make foo@@v1 resolve undefined foo@v1.

(FWIW I have made some notes about symbol versioning at https://translate.google.com/translate?sl=zh-CN&tl=en&u=https%3A%2F%2Fmaskray.me%2Fblog%2F2020-11-26-all-about-symbol-versioning)
(Apparently people are annoyed by lack of symbol versioning documentation https://invisible-island.net/ncurses/ncurses-mapsyms.html :) )
(We may need one document under docs/ELF/ describing the LLD behavior)

Fri, Nov 27, 10:42 PM · Restricted Project
MaskRay updated the summary of D92260: [ELF] Error for undefined foo@v1.
Fri, Nov 27, 10:37 PM · Restricted Project
MaskRay requested review of D92260: [ELF] Error for undefined foo@v1.
Fri, Nov 27, 10:29 PM · Restricted Project
MaskRay requested review of D92259: [ELF] Make foo@@v1 resolve undefined foo@v1.
Fri, Nov 27, 9:31 PM · Restricted Project
MaskRay requested review of D92258: [ELF][test] Add some tests for versioned symbols in object files.
Fri, Nov 27, 9:30 PM · Restricted Project
MaskRay updated the diff for D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

comments

Fri, Nov 27, 9:49 AM · Restricted Project
MaskRay updated the diff for D92114: [X86] Don't emit R_X86_64_[REX_]GOTPCRELX for a GOT load with an offset.

Add a comment

Fri, Nov 27, 9:42 AM · Restricted Project

Thu, Nov 26

MaskRay updated the diff for D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

Improve tests and comments

Thu, Nov 26, 9:49 AM · Restricted Project
MaskRay added a comment to D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

Note, R_X86_64_GOTPCRELX already does not guarantee ensured relaxation, e.g. when the symbol is preemptible the linker cannot relax the instruction, when the instruction is not one of call,jmp,adc,add,and,cmp,or,sbb,sub,test,xor, etc.

Seems that, e.g., R_X86_64_GOTPCREL should give a guarantee that relaxation will not be performed though. As far I understand GNU linkers can relax R_X86_64_GOTPCREL too? It looks like a violation of ABI?
The suggested change (for ABI) about addend then seems only needed to support this behavior of GNU linkers. In LLVM we probably should just not emit a potentially relaxable relocation from the begining.

Thu, Nov 26, 9:28 AM · Restricted Project
MaskRay added inline comments to D92114: [X86] Don't emit R_X86_64_[REX_]GOTPCRELX for a GOT load with an offset.
Thu, Nov 26, 9:20 AM · Restricted Project
MaskRay updated the diff for D92114: [X86] Don't emit R_X86_64_[REX_]GOTPCRELX for a GOT load with an offset.

Address comments

Thu, Nov 26, 9:20 AM · Restricted Project
MaskRay committed rG668da8c361fe: [MC] Set the unique id of .stack_sizes to the associated .text section's (authored by MaskRay).
[MC] Set the unique id of .stack_sizes to the associated .text section's
Thu, Nov 26, 9:13 AM
MaskRay closed D92151: [MC] Set the unique id of .stack_sizes to the associated .text section's.
Thu, Nov 26, 9:13 AM · Restricted Project
MaskRay added a comment to D92151: [MC] Set the unique id of .stack_sizes to the associated .text section's.

Thanks, LGTM too. Honestly, I'm slightly surprised this wasn't already the case. I guess no-unique-section-names hasn't been widely used in practice.

Thu, Nov 26, 9:12 AM · Restricted Project

Wed, Nov 25

MaskRay updated the summary of D92151: [MC] Set the unique id of .stack_sizes to the associated .text section's.
Wed, Nov 25, 9:14 PM · Restricted Project
MaskRay requested review of D92151: [MC] Set the unique id of .stack_sizes to the associated .text section's.
Wed, Nov 25, 9:13 PM · Restricted Project
MaskRay accepted D92147: [RISCV] Add support for printing pcrel immediates as absolute addresses in llvm-objdump.
Wed, Nov 25, 8:59 PM · Restricted Project
MaskRay added a comment to D91611: [PowerPC][LLD] Detecting and fixing missing TLS relocation on __tls_get_addr.

I have done some testing with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 and GNU ld (GNU Binutils for Ubuntu) 2.30.

It appears that ld.bfd by default fixes up the relocation if it is missing and then does the relaxation correctly. I don't need to specify any options for this to be done.
As a simple example:

Test1:
.LCF0:
  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  .localentry     Test1,.-Test1
  addis 3,2,x@got@tlsgd@ha
  addi 3,3,x@got@tlsgd@l
  bl __tls_get_addr
  nop

The bl __tls_get_addr is missing the relocation ld.bfd still relaxes it correctly.
However, with a more complex example that I wrote by hand:

Test1:
.LCF0:
  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  .localentry     Test1,.-Test1
  addis 3,2,x@got@tlsgd@ha
  addi 3,3,x@got@tlsgd@l
  addis 3,2,x@got@tlsgd@ha
  addi 3,3,x@got@tlsgd@l
  bl __tls_get_addr
  nop

in the above case ld.bfd does not recognize the pattern for the TLS and so it turns off TLS relaxations completely.
The reason I brought up these examples is because I feel that detecting the difference between the two cases in lld would be unreasonably complicated an probably not worth it. As a result I feel that it may not be feasible to do the same thing that ld.bfd is doing.

Here is my new proposal:
We can add an option to lld. Unfortunately this option will not exist in ld.bfd because they wouldn't need it.
The option is off by default.
If the option is off then lld will behave exactly the same way that it always has. No error detection for missing relocations.
If the option is on then lld will check all calls to __get_tls_addr and if it finds a missing relocation it will turn off TLS relaxations. It won't try to add the missing relocation and it won't throw an error.
This design will not cause problems to default behaviour (and it shouldn't add overhead to the default link either) but it will also allow linking with code that was generated with the legacy compiler if the user specifies the option.

How does this new idea sound?
If everyone agrees on this idea (or a variant of this idea) I will rework the patch like this.

Wed, Nov 25, 8:30 PM · Restricted Project
MaskRay added a comment to D91611: [PowerPC][LLD] Detecting and fixing missing TLS relocation on __tls_get_addr.

I have done some testing with gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 and GNU ld (GNU Binutils for Ubuntu) 2.30.

It appears that ld.bfd by default fixes up the relocation if it is missing and then does the relaxation correctly. I don't need to specify any options for this to be done.
As a simple example:

Test1:
.LCF0:
  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  .localentry     Test1,.-Test1
  addis 3,2,x@got@tlsgd@ha
  addi 3,3,x@got@tlsgd@l
  bl __tls_get_addr
  nop

The bl __tls_get_addr is missing the relocation ld.bfd still relaxes it correctly.
However, with a more complex example that I wrote by hand:

Test1:
.LCF0:
  addis 2,12,.TOC.-.LCF0@ha
  addi 2,2,.TOC.-.LCF0@l
  .localentry     Test1,.-Test1
  addis 3,2,x@got@tlsgd@ha
  addi 3,3,x@got@tlsgd@l
  addis 3,2,x@got@tlsgd@ha
  addi 3,3,x@got@tlsgd@l
  bl __tls_get_addr
  nop

in the above case ld.bfd does not recognize the pattern for the TLS and so it turns off TLS relaxations completely.
The reason I brought up these examples is because I feel that detecting the difference between the two cases in lld would be unreasonably complicated an probably not worth it. As a result I feel that it may not be feasible to do the same thing that ld.bfd is doing.

Wed, Nov 25, 8:28 PM · Restricted Project
MaskRay added inline comments to D92100: [clang] do not limit -fstack-clash-protection to Linux.
Wed, Nov 25, 6:42 PM
MaskRay added inline comments to D91816: [Inline] prevent inlining on stack protector mismatch.
Wed, Nov 25, 2:39 PM · Restricted Project
MaskRay added inline comments to D91816: [Inline] prevent inlining on stack protector mismatch.
Wed, Nov 25, 2:09 PM · Restricted Project
MaskRay accepted D92135: [libc++] Remove sysctl-based implementation of thread::hardware_concurrency().

I confirm that sysconf(_SC_NPROCESSORS_ONLN) works on musl. Thanks

Wed, Nov 25, 1:59 PM · Restricted Project
MaskRay added inline comments to D92073: [CodeGen] Add text section prefix for COFF object file.
Wed, Nov 25, 1:56 PM · Restricted Project
MaskRay accepted D92098: [obj2yaml] - Dump the `EShNum` key in some cases..
Wed, Nov 25, 11:54 AM · Restricted Project
MaskRay added inline comments to D92100: [clang] do not limit -fstack-clash-protection to Linux.
Wed, Nov 25, 11:46 AM
MaskRay added a comment to D92113: Let .llvm_bb_addr_map section use the same unique id as its associated .text section..

Yes that .stack_sizes needs a similar fix. @grimar or I can fix it.

Wed, Nov 25, 11:15 AM · Restricted Project
MaskRay added inline comments to D92113: Let .llvm_bb_addr_map section use the same unique id as its associated .text section..
Wed, Nov 25, 11:14 AM · Restricted Project
MaskRay added inline comments to D92113: Let .llvm_bb_addr_map section use the same unique id as its associated .text section..
Wed, Nov 25, 11:13 AM · Restricted Project
MaskRay accepted D92087: [llvm-readelf/obj] - Report a warning when the value of the DT_PLTREL dynamic tag is invalid..

Thanks!

Wed, Nov 25, 11:01 AM · Restricted Project
MaskRay added a comment to D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

If we want to support clang -fno-integrated-as + LLD, we still need this.

Wed, Nov 25, 10:15 AM · Restricted Project
MaskRay requested review of D92114: [X86] Don't emit R_X86_64_[REX_]GOTPCRELX for a GOT load with an offset.
Wed, Nov 25, 10:13 AM · Restricted Project
MaskRay added inline comments to D92052: [MC][ELF] Accept abbreviated form with sh_flags and sh_entsize.
Wed, Nov 25, 9:04 AM · Restricted Project
MaskRay committed rG50564ca07543: [ELF] Rename adjustRelaxExpr to adjustTlsExpr and delete the unused `data`… (authored by MaskRay).
[ELF] Rename adjustRelaxExpr to adjustTlsExpr and delete the unused `data`…
Wed, Nov 25, 9:01 AM
MaskRay closed D91995: [ELF] Rename adjustRelaxExpr to adjustTlsExpr and delete the unused `data` parameter.
Wed, Nov 25, 9:01 AM · Restricted Project
MaskRay added inline comments to D91836: [PowerPC] Delete remnant Darwin code in PPCAsmParser.
Wed, Nov 25, 8:52 AM · Restricted Project
MaskRay added a comment to D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

FWIW, I'm with @grimar in the sense that I think this is poor and unnecessary behaviour provided for by the psABI. Why emit the relocation type in this context, when the primary purpose (assuming I'm not mistaken) of this relocation type is to enable relaxations? Why not emit the generic GOTPCREL relocation?

Wed, Nov 25, 8:49 AM · Restricted Project
MaskRay committed rG572d18397cf0: [ELF] Add TargetInfo::adjustGotPcExpr for `R_GOT_PC` relaxations. NFC (authored by MaskRay).
[ELF] Add TargetInfo::adjustGotPcExpr for `R_GOT_PC` relaxations. NFC
Wed, Nov 25, 8:43 AM
MaskRay closed D92079: [ELF] Add TargetInfo::adjustGotPcExpr for `R_GOT_PC` relaxations. NFC.
Wed, Nov 25, 8:43 AM · Restricted Project
MaskRay added inline comments to D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.
Wed, Nov 25, 12:29 AM · Restricted Project
MaskRay updated the diff for D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

Extract refactoring part

Wed, Nov 25, 12:29 AM · Restricted Project
MaskRay requested review of D92079: [ELF] Add TargetInfo::adjustGotPcExpr for `R_GOT_PC` relaxations. NFC.
Wed, Nov 25, 12:25 AM · Restricted Project
MaskRay accepted D91152: [obj2yaml] - Dump section offsets in some cases..
Wed, Nov 25, 12:20 AM · Restricted Project
MaskRay requested review of D92078: [asan] Default to -asan-use-private-alias=1.
Wed, Nov 25, 12:19 AM · Restricted Project, Restricted Project

Tue, Nov 24

MaskRay added inline comments to D91605: [sanitizers] Implement GetTls on Solaris.
Tue, Nov 24, 5:30 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay added a comment to D91189: Add support for Intel's umonitor/umwait.

LGTM

Tue, Nov 24, 4:43 PM · Restricted Project
MaskRay added a comment to D91223: Support struct annotations in FuchsiaHandleChecker..

@haowei https://llvm.org/docs/DeveloperPolicy.html#commit-messages Please use git commit --amend --author for future patches where the majority of the work is done by others.

Tue, Nov 24, 4:41 PM · Restricted Project
MaskRay added inline comments to D91605: [sanitizers] Implement GetTls on Solaris.
Tue, Nov 24, 3:35 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay accepted D92018: [llvm-readelf/obj] - Deduplicate the logic that prints notes. NFCI..
Tue, Nov 24, 3:20 PM · Restricted Project
MaskRay accepted D92060: [lld] Add --no-lto-whole-program-visibility.

Looks great!

Tue, Nov 24, 3:17 PM · Restricted Project
MaskRay added a comment to D92060: [lld] Add --no-lto-whole-program-visibility.

This looks good.

Tue, Nov 24, 3:01 PM · Restricted Project
MaskRay added a comment to D91611: [PowerPC][LLD] Detecting and fixing missing TLS relocation on __tls_get_addr.

I don't think adding an option to GNU ld is appropriate because it does the slow thing by default. Stefan is working on some test cases to illustrate GNU ld's behaviour so I think we should start with what it does and see whether we want to match behaviour and whether we want to do so under option control.

Tue, Nov 24, 2:57 PM · Restricted Project
MaskRay added inline comments to D91803: [lld] Use -1 as tombstone value for discarded code ranges.
Tue, Nov 24, 2:53 PM · Restricted Project
MaskRay added a comment to D92052: [MC][ELF] Accept abbreviated form with sh_flags and sh_entsize.

This is known. I'd like it to be an error but it is unfortunate that GCC uses it this way. Can you share a code snippet which can trigger the relevant GCC logic?

It looks as if one way to get it is requires the -ffunction-sections flag, example: https://godbolt.org/z/Yfveoh which creates:

  • .section .text.ULtod,"ax",@progbits
  • .section .text.ULtod

-ffunction-sections/-fdata-sections is described as: Place each function or data item into its own section in the output file if the target supports arbitrary sections. ... Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower.

As there is already a huge growth, avoiding the repetition of the flags/entsize helps a bit. Thus, the GCC and GNU assembler short variant makes kind of sense.

Tue, Nov 24, 2:33 PM · Restricted Project
MaskRay added a comment to D91611: [PowerPC][LLD] Detecting and fixing missing TLS relocation on __tls_get_addr.

I am still questioning the motivation behind this change. If there are indeed ABI issues from older compilers,
can they add a wrapper around the linker if the check is deemed useful?

I don't really see it as an improvement in usability to have to post-process object files, potentially introducing another possible point of failure vs. providing an option to the linker.

(In addition, binutils does not have --add-missing-tls-reloc.)

I think that a departure from option compatibility is reasonable here if we can provide an option that will:

  • Allow us to handle the missing relocation when the option is specified
  • Not introduce any performance overhead when the option is not specified (i.e. the default behaviour)

Note that I am not saying this option achieves both of those goals.
It would appear to me that we really have 3 situations here that are kind of at odds with each other:

  1. Typical compiler-introduced calls to __tls_get_addr with the necessary relocations for the symbol
  2. The weird usage in ld.so with a missing relocation that does not require a relocation as there is no symbol
  3. A non-ABI compliant compiler-introduced call with a value associated with a symbol in the parameter register but a missing relocation

The current state is that the linker does not produce errors on any of those but produces incorrect code for 3. Adding this patch introduces performance overhead by default and handles 3. by either emitting an error or fixing up the relocation to avoid producing incorrect code. It has the further issue that it assumes the immediately preceding relocation was for setting up the parameter to __tls_get_addr which may not be the case as @sfertile pointed out.
So can we do something like this:

  • Leave default behaviour as it is now
  • Provide an option to search for and fix up missing relocations and error out if it cannot

Case 2. above would not work with this option, but that really doesn't seem like a problem as builds that do that will never specify the option. Furthermore, we will continue to emit incorrect code for case 3. above by default, but that is also not a problem as the documentation can suggest using the option whenever some objects are produced by older versions of the XL compiler.

Tue, Nov 24, 1:44 PM · Restricted Project
MaskRay added a comment to D92052: [MC][ELF] Accept abbreviated form with sh_flags and sh_entsize.

This is known. I'd like it to be an error but it is unfortunate that GCC uses it this way. Can you share a code snippet which can trigger the relevant GCC logic?

Tue, Nov 24, 12:14 PM · Restricted Project
MaskRay updated the summary of D92052: [MC][ELF] Accept abbreviated form with sh_flags and sh_entsize.
Tue, Nov 24, 12:07 PM · Restricted Project
MaskRay requested review of D92054: [Driver] Default Generic_GCC ppc/ppc64/ppc64le to -fasynchronous-unwind-tables.
Tue, Nov 24, 12:03 PM · Restricted Project
MaskRay committed rG8f8bbf98dae1: [test] Clean up ppc-features.cpp and improve tests (authored by MaskRay).
[test] Clean up ppc-features.cpp and improve tests
Tue, Nov 24, 11:59 AM
MaskRay added a comment to D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

My understanding is that R_X86_64_*RELX relocation should never be emitted when a relaxation is not possible.
ABI doesn't say anything about addends I think ("B.2 Optimize GOTPCRELX Relocations", p151, https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf).
So, why should this be handled on linker side and not on the compiler side?

There are two questions:

  • Whether movl x@GOTPCREL+4(%rip), %eax is valid?
  • Whether the expression should assemble to R_X86_64_GOTPCRELX?

For the first, I tend to think it is valid - this allows the compiler generates an instruction to load the half part of the GOT entry.
For the second, my understanding is that R_X86_64_GOTPCREL can be entirely replaced by R_X86_64_[REX_]GOTPCRELX. If so, it is certainly reasonable to assemble to R_X86_64_GOTPCRELX. I can send a clarification on binutils, though.

Tue, Nov 24, 10:11 AM · Restricted Project
MaskRay committed rGf96fef89b5ec: [Driver] Default Generic_GCC aarch64 to -fasynchronous-unwind-tables (authored by MaskRay).
[Driver] Default Generic_GCC aarch64 to -fasynchronous-unwind-tables
Tue, Nov 24, 9:51 AM
MaskRay closed D91760: [Driver] Default Generic_GCC aarch64 to use -fasynchronous-unwind-tables.
Tue, Nov 24, 9:51 AM · Restricted Project
MaskRay added a comment to D91760: [Driver] Default Generic_GCC aarch64 to use -fasynchronous-unwind-tables.

Radio silence so far; I think no news is good news applies in this case. I'm happy to say no objections.

Tue, Nov 24, 9:48 AM · Restricted Project
MaskRay added a comment to D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.

My understanding is that R_X86_64_*RELX relocation should never be emitted when a relaxation is not possible.
ABI doesn't say anything about addends I think ("B.2 Optimize GOTPCRELX Relocations", p151, https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf).
So, why should this be handled on linker side and not on the compiler side?

Tue, Nov 24, 9:31 AM · Restricted Project

Mon, Nov 23

MaskRay added a comment to D92002: Modify the comment of ErrorHandlerTraits in llvm/Support/Error.h.

The fix is correct but do you think the code self explains?

Mon, Nov 23, 10:53 PM · Restricted Project
MaskRay added a comment to D88712: [CGBuiltin] Respect asm labels and redefine_extname for builtins with specialized emitting.

For your example:

extern double log (double) asm ("" "log_finite") __attribute__ ((nothrow));

double mylog (double d) { return log(d); }

The intention is to emit log_finite, no matter the -ffast-math. Both GCC and Clang (after this patch) emit jmp log_finite.

The previous behavior (according to your comment, with an older glibc) was undesired. So I think the right suggestion is to upgrade glibc.

Then there optimizations like vectorization, inst combine which works on the LLVM intrinsics. But they will be not happening now with log_finite calls.
is it possible to add an option to disable this feature, in case anyone who wants to avail these optimization?

Mon, Nov 23, 10:03 PM · Restricted Project
MaskRay committed rG51994f90b618: [CMake] Unify LLVM_LINKER_IS_GOLD -Wl,--gc-sections setting with GNU ld and LLD (authored by MaskRay).
[CMake] Unify LLVM_LINKER_IS_GOLD -Wl,--gc-sections setting with GNU ld and LLD
Mon, Nov 23, 7:47 PM
MaskRay added inline comments to D91605: [sanitizers] Implement GetTls on Solaris.
Mon, Nov 23, 7:30 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay committed rGc2fb114475d1: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux (authored by glaubitz).
[Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux
Mon, Nov 23, 7:26 PM
MaskRay closed D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.
Mon, Nov 23, 7:25 PM · Restricted Project
MaskRay accepted D90524: [Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux.
Mon, Nov 23, 7:20 PM · Restricted Project
MaskRay committed rGbb1341161478: [libunwind] Multiple preprocessor fixes on PowerPC* (authored by Bdragon28).
[libunwind] Multiple preprocessor fixes on PowerPC*
Mon, Nov 23, 7:07 PM
MaskRay closed D91906: Multiple preprocessor fixes for libunwind on PowerPC*..
Mon, Nov 23, 7:07 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay accepted D91906: Multiple preprocessor fixes for libunwind on PowerPC*..

OK, patch updated with the typo fix.

The !__ALTIVEC__ case has been tested on an AmigaONE X5000. I will test the __NO_FPRS__ case on my RB800 later tonight. (Test to verify that it resolves the SIGILL, that is. The actual SPE bits will come later.)

Note: I do not have commit access.

Mon, Nov 23, 7:03 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay accepted D91964: [llvm-readelf/obj] - Refine the implementation of `printGNUVersionSectionProlog`.

LGTM. binutils/readelf.c:process_version_sections uses sh_link as well.

Mon, Nov 23, 5:53 PM · Restricted Project
MaskRay added a comment to D91611: [PowerPC][LLD] Detecting and fixing missing TLS relocation on __tls_get_addr.

Both forms are technically not valid according to the ABI. No new code should be producing either of the two forms.

Mon, Nov 23, 5:02 PM · Restricted Project
MaskRay added a comment to D91760: [Driver] Default Generic_GCC aarch64 to use -fasynchronous-unwind-tables.

@psmith Do they have concerns? :)

Mon, Nov 23, 4:08 PM · Restricted Project
MaskRay added a comment to D91884: clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle.

Will wait until EOD to see if maskray is happy.

Mon, Nov 23, 2:29 PM · Restricted Project, Restricted Project
MaskRay added inline comments to D91884: clang+lld: Improve clang+ld.darwinnew.lld interaction, pass -demangle.
Mon, Nov 23, 2:27 PM · Restricted Project, Restricted Project
MaskRay added a comment to D88712: [CGBuiltin] Respect asm labels and redefine_extname for builtins with specialized emitting.
Mon, Nov 23, 1:24 PM · Restricted Project
MaskRay requested review of D91995: [ELF] Rename adjustRelaxExpr to adjustTlsExpr and delete the unused `data` parameter.
Mon, Nov 23, 1:13 PM · Restricted Project
MaskRay updated the summary of D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.
Mon, Nov 23, 1:07 PM · Restricted Project
MaskRay added a comment to D91965: Revert "[X86] Produce R_X86_64_GOTPCRELX for test/binop instructions (MOV32rm/TEST32rm/...) when -Wa,-mrelax-relocations=yes is enabled".

Superseded by D91965

Mon, Nov 23, 1:06 PM · Restricted Project
MaskRay requested review of D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4.
Mon, Nov 23, 1:06 PM · Restricted Project
MaskRay added a comment to D91965: Revert "[X86] Produce R_X86_64_GOTPCRELX for test/binop instructions (MOV32rm/TEST32rm/...) when -Wa,-mrelax-relocations=yes is enabled".

This a pre-existing problem with GNU as:

Mon, Nov 23, 11:36 AM · Restricted Project
MaskRay added a comment to D91965: Revert "[X86] Produce R_X86_64_GOTPCRELX for test/binop instructions (MOV32rm/TEST32rm/...) when -Wa,-mrelax-relocations=yes is enabled".

Thanks for reporting the issue. The problem is that clang produces incorrect GOTPCREL+offset fixup. I will try providing a better fix.

Mon, Nov 23, 9:57 AM · Restricted Project

Sat, Nov 21

MaskRay updated subscribers of D91906: Multiple preprocessor fixes for libunwind on PowerPC*..

Looks good to me. (+@luporl who added PPC64_HAS_VMX)

Sat, Nov 21, 9:26 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay committed rG1756d67934bb: [llvm][clang][mlir] Add checks for the return values from Target::createXXX to… (authored by OikawaKirie).
[llvm][clang][mlir] Add checks for the return values from Target::createXXX to…
Sat, Nov 21, 9:04 PM
MaskRay closed D91410: [llvm][clang][mlir] Add checks for the return values from Target::createXXX to prevent protential null deref.
Sat, Nov 21, 9:04 PM · Restricted Project, Restricted Project, Restricted Project
MaskRay committed rG3324fd8a7b1a: [libunwind] Delete unused handlerNotFound in unwind_phase1 (authored by MaskRay).
[libunwind] Delete unused handlerNotFound in unwind_phase1
Sat, Nov 21, 12:38 PM
MaskRay committed rG4629afa101d4: [X86] Include %rip for 32-bit RIP-relative relocs for x32 (authored by hvdijk).
[X86] Include %rip for 32-bit RIP-relative relocs for x32
Sat, Nov 21, 9:20 AM
MaskRay closed D91339: [X86] Include %rip for 32-bit RIP-relative relocs for x32.
Sat, Nov 21, 9:20 AM · Restricted Project

Fri, Nov 20

MaskRay added inline comments to D91803: [lld] Use -1 as tombstone value for discarded code ranges.
Fri, Nov 20, 1:26 PM · Restricted Project
MaskRay added inline comments to D91836: [PowerPC] Delete remnant Darwin code in PPCAsmParser.
Fri, Nov 20, 1:22 PM · Restricted Project