[llvm-branch-commits] [lld] ELF: Introduce R_AARCH64_FUNCINIT64 relocation type. (PR #133531)

@@ -0,0 +1,19 @@ +# REQUIRES: aarch64 + +# RUN: llvm-mc -filetype=obj -triple=aarch64 %s -o %t.o +# RUN: ld.lld %t.o -o %t +# RUN: llvm-readelf -s -r %t | FileCheck %s +# RUN: ld.lld %t.o -o %t -pie +# RUN: llvm-readelf -s -r %t | FileCheck %s +# RUN: not ld.lld %t.o -o %t -shared

[llvm-branch-commits] [lld] ELF: Introduce R_AARCH64_FUNCINIT64 relocation type. (PR #133531)

https://github.com/smithp35 commented: I don't have any more significant comments and no objections to the patch. Going back to my previous comments I was most concerned when the target was an ifunc symbol and that is now not supported. https://github.com/llvm/llvm-project/pull/133531

[llvm-branch-commits] [lld] ELF: Introduce R_AARCH64_FUNCINIT64 relocation type. (PR #133531)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/133531 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] ELF: Introduce R_AARCH64_PATCHINST relocation type. (PR #133534)

@@ -0,0 +1,41 @@ +# RUN: rm -rf %t && split-file %s %t +# RUN: llvm-mc -filetype=obj -triple=aarch64 %t/use.s -o %t/use-le.o +# RUN: llvm-mc -filetype=obj -triple=aarch64 %t/def.s -o %t/def-le.o + +## Deactivation symbol used without being defined: instruction emitted as usual. +

[llvm-branch-commits] ELF: Introduce R_AARCH64_PATCHINST relocation type. (PR #133534)

@@ -137,6 +137,7 @@ RelExpr AArch64::getRelExpr(RelType type, const Symbol &s, switch (type) { case R_AARCH64_ABS16: case R_AARCH64_ABS32: + case R_AARCH64_PATCHINST: smithp35 wrote: If the relocation is used as described in the RFC, with the target sym

[llvm-branch-commits] [lld] ELF: Introduce R_AARCH64_FUNCINIT64 relocation type. (PR #133531)

smithp35 wrote: > @smithp35 @MaskRay ping. I've got it on my list, will aim to get you some comments on this and https://github.com/llvm/llvm-project/pull/133534 by tomorrow. Unlikely to make it today. https://github.com/llvm/llvm-project/pull/133531 __

[llvm-branch-commits] [llvm] ARM: Avoid using isTarget wrappers around Triple predicates (PR #144705)

https://github.com/smithp35 commented: This looks reasonable to me. I can't see a way of changing those properties on a subtarget level with attributes. Added the ARM backend maintainers to see if they have anything to add. Would it be worth adding a comment to the function definitions in Sub

[llvm-branch-commits] [lld] ELF: Add branch-to-branch optimization. (PR #138366)

smithp35 wrote: Thanks for the updates. I don't have any more comments. https://github.com/llvm/llvm-project/pull/138366 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch

[llvm-branch-commits] [lld] ELF: Add branch-to-branch optimization. (PR #138366)

@@ -975,6 +977,62 @@ void AArch64::relocateAlloc(InputSectionBase &sec, uint8_t *buf) const { } } +static std::optional getControlTransferAddend(InputSection &is, +Relocation &r) { + // Identify a control transfer rel

[llvm-branch-commits] [lld] ELF: Add branch-to-branch optimization. (PR #138366)

@@ -0,0 +1,92 @@ +//===- TargetImpl.h -*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apa

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

smithp35 wrote: As a FYI, I'll be out of office till after Easter, so I may not be able to respond next week. https://github.com/llvm/llvm-project/pull/133531 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.o

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

smithp35 wrote: I had been assuming that this patch didn't change lld behaviour from the comment in handleNonPreemptibleIfunc() I've had some time to build and run lld on my example with this change and I notice that with this change I'm seeing the dynamic symbol table use the ifunc resolver.

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

smithp35 wrote: I have some small reservations about using ifunc resolvers like this. Mostly in that we are using a mechanism invented for a different purpose, and relying on some specific linker behaviour to make this case work. This is similar to comments made in the Discourse post https://

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

https://github.com/smithp35 commented: How does this work in the non-PIE (PDE) case when we take the address of an ifunc and pass it to a function in a shared library, which then compares the argument with its own global address take of the ifunc? For example: shared lib ``` typedef void Fptr(

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/133531 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

@@ -1964,6 +1979,26 @@ void elf::postScanRelocations(Ctx &ctx) { for (ELFFileBase *file : ctx.objectFiles) for (Symbol *sym : file->getLocalSymbols()) fn(*sym); + + // Now that we have checked all ifunc symbols for demotion to regular function + // symbols, move

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

@@ -42,6 +42,8 @@ void printTraceSymbol(const Symbol &sym, StringRef name); enum { NEEDS_GOT = 1 << 0, NEEDS_PLT = 1 << 1, + // True if this is an ifunc with a direct relocation that cannot be smithp35 wrote: Although not new, could be worth expanding on

[llvm-branch-commits] [lld] ELF: Only rewrite non-preemptible IFUNCs to IPLT functions if a non-IRELATIVE relocation is needed. (PR #133531)

@@ -1761,6 +1761,9 @@ void RelocationBaseSection::computeRels() { llvm::sort(nonRelative, irelative, [&](auto &a, auto &b) { return std::tie(a.r_sym, a.r_offset) < std::tie(b.r_sym, b.r_offset); }); +llvm::sort(irelative, relocs.end(), [&](auto &a, auto &b) {

[llvm-branch-commits] ELF: Add support for R_AARCH64_INST32 relocation. (PR #133534)

smithp35 wrote: Apologies for the delay in responding, just come back from vacation. Not had a chance to look through the Discourse posts yet, will do so this week. While it may seem a bit premature, would you be able to open an issue in the AArch64 ABI (https://github.com/ARM-software/abi-aa/

[llvm-branch-commits] [lld] release/20.x: [ELF] --package-metadata: support %[0-9a-fA-F][0-9a-fA-F] (PR #126549)

https://github.com/smithp35 approved this pull request. LGTM. This would be useful as it would be needed if Linux Distros start using this. https://github.com/llvm/llvm-project/pull/126549 ___ llvm-branch-commits mailing list llvm-branch-commits@lists

[llvm-branch-commits] [lld] [PAC][lld][AArch64][ELF] Support signed TLSDESC (PR #113817)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/113817 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] [PAC][lld][AArch64][ELF] Support signed TLSDESC (PR #113817)

https://github.com/smithp35 commented: A few small suggestions from me. https://github.com/llvm/llvm-project/pull/113817 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch

[llvm-branch-commits] [lld] [PAC][lld][AArch64][ELF] Support signed TLSDESC (PR #113817)

@@ -92,6 +92,10 @@ enum RelExpr { R_AARCH64_PAGE_PC, R_AARCH64_RELAX_TLS_GD_TO_IE_PAGE_PC, R_AARCH64_TLSDESC_PAGE, + R_AARCH64_AUTH_TLSDESC_PAGE, + // TODO: maybe it's better to rename this expression + // to avoid name conflict with dynamic reloc + R_AARCH64_AUTH_TLS

[llvm-branch-commits] [lld] [PAC][lld][AArch64][ELF] Support signed TLSDESC (PR #113817)

@@ -0,0 +1,134 @@ +// REQUIRES: aarch64 +// RUN: rm -rf %t && split-file %s %t && cd %t + +//--- a.s + +.section .tbss,"awT",@nobits +.global a +a: +.xword 0 + +//--- ok.s + +// RUN: llvm-mc -filetype=obj -triple=aarch64-pc-linux -mattr=+pauth ok.s -o ok.o +// RUN: ld.lld -shared

[llvm-branch-commits] [lld] [PAC][lld][AArch64][ELF] Support signed TLSDESC (PR #113817)

@@ -1352,6 +1352,36 @@ unsigned RelocationScanner::handleTlsRelocation(RelExpr expr, RelType type, return 1; } + auto fatalBothAuthAndNonAuth = [&sym]() { +fatal("both AUTH and non-AUTH TLSDESC entries for '" + sym.getName() + smithp35 wrote: Can

[llvm-branch-commits] [lld] [PAC][lld][AArch64][ELF] Support signed TLSDESC (PR #113817)

smithp35 wrote: Just got back from vacation today. I plan to create a PR for the ABI tomorrow. Will take a look at this patch tomorrow. https://github.com/llvm/llvm-project/pull/113817 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llv

[llvm-branch-commits] [lld] [PAC][lld] Use braa instr in PAC PLT sequence with valid PAuth core info (PR #113945)

@@ -1096,8 +1113,10 @@ void AArch64BtiPac::writePlt(uint8_t *buf, const Symbol &sym, relocateNoSym(buf + 4, R_AARCH64_LDST64_ABS_LO12_NC, gotPltEntryAddr); relocateNoSym(buf + 8, R_AARCH64_ADD_ABS_LO12_NC, gotPltEntryAddr); - if (pacEntry) -memcpy(buf + sizeof(addrIn

[llvm-branch-commits] [lld] [PAC][lld] Use braa instr in PAC PLT sequence with valid PAuth core info (PR #113945)

https://github.com/smithp35 commented: No objections from me. A small suggestion for the comment and a possible simplification. https://github.com/llvm/llvm-project/pull/113945 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org ht

[llvm-branch-commits] [lld] [PAC][lld] Use braa instr in PAC PLT sequence with valid PAuth core info (PR #113945)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/113945 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] [PAC][lld] Use braa instr in PAC PLT sequence with valid PAuth core info (PR #113945)

@@ -1014,9 +1018,18 @@ AArch64BtiPac::AArch64BtiPac(Ctx &ctx) : AArch64(ctx) { // relocations. // The PAC PLT entries require dynamic loader support and this isn't known // from properties in the objects, so we use the command line flag. - pacEntry = ctx.arg.zPacPlt; ---

[llvm-branch-commits] [Driver] Add -Wa, options -mmapsyms={default, implicit} (PR #104542)

https://github.com/smithp35 approved this pull request. Thanks for adding the help. LGTM. https://github.com/llvm/llvm-project/pull/104542 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/li

[llvm-branch-commits] [Driver] Add -Wa, options -mmapsyms={default, implicit} (PR #104542)

https://github.com/smithp35 commented: I think we could do with some help text. Otherwise code changes look good. https://github.com/llvm/llvm-project/pull/104542 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llv

[llvm-branch-commits] [Driver] Add -Wa, options -mmapsyms={default, implicit} (PR #104542)

@@ -7131,6 +7131,8 @@ def massembler_fatal_warnings : Flag<["-"], "massembler-fatal-warnings">, def crel : Flag<["--"], "crel">, HelpText<"Enable CREL relocation format (ELF only)">, MarshallingInfoFlag>; +def mmapsyms_implicit : Flag<["-"], "mmapsyms=implicit">, -

[llvm-branch-commits] [Driver] Add -Wa, options -mmapsyms={default, implicit} (PR #104542)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/104542 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] release/19.x: [ELF] Support relocatable files using CREL with explicit addends (PR #101532)

https://github.com/smithp35 approved this pull request. CREL is an experimental optional feature that we want to get feedback on, it would be good to get this into the 19 release. https://github.com/llvm/llvm-project/pull/101532 ___ llvm-branch-commit

[llvm-branch-commits] [lld] [llvm] release/19.x: [ARM] Create mapping symbols with non-unique names (PR #100171)

https://github.com/smithp35 approved this pull request. LGTM, this is a simple and safe change. https://github.com/llvm/llvm-project/pull/100171 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mail

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

https://github.com/smithp35 approved this pull request. LGTM too, thanks for the updates. https://github.com/llvm/llvm-project/pull/97382 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/lis

[llvm-branch-commits] [llvm] [llvm-objcopy] Support CREL (PR #97521)

https://github.com/smithp35 approved this pull request. Thanks for the updates LGTM too. I'm fine with committing the extracted code separately. https://github.com/llvm/llvm-project/pull/97521 ___ llvm-branch-commits mailing list llvm-branch-commits@l

[llvm-branch-commits] [llvm-objcopy] Support CREL (PR #97521)

@@ -1861,7 +1886,15 @@ template Error ELFBuilder::readSections(bool EnsureSymtab) { const typename ELFFile::Elf_Shdr *Shdr = Sections->begin() + RelSec->Index; - if (RelSec->Type == SHT_REL) { + if (RelSec->Type == SHT_CREL) { +auto Rels = E

[llvm-branch-commits] [llvm-objcopy] Support CREL (PR #97521)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/97521 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objcopy] Support CREL (PR #97521)

https://github.com/smithp35 commented: Only a couple of small comments from me. I'll be out of the office till Monday next week, I'm fine for others to progress this wihout me. https://github.com/llvm/llvm-project/pull/97521 ___ llvm-branch-commits ma

[llvm-branch-commits] [llvm-objcopy] Support CREL (PR #97521)

@@ -0,0 +1,60 @@ +//===- MCELFExtras.h - Extra functions for ELF --*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apa

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

@@ -207,6 +209,43 @@ bool isSectionInSegment(const typename ELFT::Phdr &Phdr, checkSectionVMA(Phdr, Sec); } +template +Error decodeCrel(ArrayRef Content, + function_ref HdrHandler, smithp35 wrote: could be worth ``` uint64_t /* relo

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

@@ -207,6 +209,43 @@ bool isSectionInSegment(const typename ELFT::Phdr &Phdr, checkSectionVMA(Phdr, Sec); } +template smithp35 wrote: Thanks for lifting this out. Possibly worth a comment describing HdrHandler and EntryHandler. For example: ``` //

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

https://github.com/smithp35 commented: Thanks for the updates. Only a couple of small suggestions. Will be out of office till Monday next week. I'm fine with others approving. https://github.com/llvm/llvm-project/pull/97382 ___ llvm-branch-commits ma

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/97382 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

https://github.com/smithp35 commented: I agree with jh7370 that it would be good to extract the decoding logic, it seems like each tool needs some way of passing in a way to step through the data, return the decoded data, and a way of storing errors. It is possible that this will end up being

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

@@ -2687,6 +2687,15 @@ void Dumper::printRelocations() { << "VALUE\n"; for (SectionRef Section : P.second) { + // CREL requires decoding and has its specific errors. smithp35 wrote: I recommend ``` // CREL sections require decoding, each s

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/97382 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

@@ -1453,6 +1525,15 @@ template bool ELFObjectFile::isRelocatableObject() const { return EF.getHeader().e_type == ELF::ET_REL; } +template +StringRef ELFObjectFile::getCrelError(DataRefImpl Sec) const { + uintptr_t SHT = reinterpret_cast(cantFail(EF.sections()).begin());

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

@@ -292,6 +295,11 @@ template class ELFObjectFile : public ELFObjectFileBase { const Elf_Shdr *DotSymtabSec = nullptr; // Symbol table section. const Elf_Shdr *DotSymtabShndxSec = nullptr; // SHT_SYMTAB_SHNDX section. + // Hold CREL relocations for SectionRef::relocatio

[llvm-branch-commits] [llvm-objdump] -r: support CREL (PR #97382)

@@ -2687,6 +2687,15 @@ void Dumper::printRelocations() { << "VALUE\n"; for (SectionRef Section : P.second) { + // CREL requires decoding and has its specific errors. + if (O.isELF() && ELFSectionRef(Section).getType() == ELF::SHT_CREL) { +const

[llvm-branch-commits] [lld] [ELF] Orphan placement: remove hasInputSections condition (PR #93761)

smithp35 wrote: I think https://github.com/llvm/llvm-project/pull/94519 looks good. Probably worth landing that first and rebasing this one. https://github.com/llvm/llvm-project/pull/93761 ___ llvm-branch-commits mailing list llvm-branch-commits@lists

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

https://github.com/smithp35 approved this pull request. Forgot to approve https://github.com/llvm/llvm-project/pull/82187 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branc

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

https://github.com/smithp35 commented: Thanks for the update, I'm happy with the changes. I would like to see more options for position independent code in embedded systems. The other related embedded position independent option for microcontrollers that I'm aware of is `-fropi` and `-frwpi` w

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

@@ -11358,6 +11361,37 @@ bool ARMAsmParser::parseDirectiveARM(SMLoc L) { return false; } +MCSymbolRefExpr::VariantKind +ARMAsmParser::getVariantKindForName(StringRef Name) const { + return StringSwitch(Name.lower()) + .Case("funcdesc", MCSymbolRefExpr::VK_FUNCDESC) +

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

@@ -11358,6 +11361,37 @@ bool ARMAsmParser::parseDirectiveARM(SMLoc L) { return false; } +MCSymbolRefExpr::VariantKind +ARMAsmParser::getVariantKindForName(StringRef Name) const { smithp35 wrote: I can see a design trade-off here. By implementing only the e

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

@@ -84,6 +84,11 @@ unsigned ARMELFObjectWriter::GetRelocTypeInner(const MCValue &Target, if (Kind >= FirstLiteralRelocationKind) return Kind - FirstLiteralRelocationKind; MCSymbolRefExpr::VariantKind Modifier = Target.getAccessVariant(); + auto CheckFDPIC = [&]() { +

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

https://github.com/smithp35 commented: I've checked over the implementation with binutils. Out of interest are you planning on implementing all of fdpic or just enough to get assembler/linker support working? If you are there are some other GNU options that may be useful to look at as possibl

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/82187 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [ARM, MC] Support FDPIC relocations (PR #82187)

@@ -223,6 +223,12 @@ class MCSymbolRefExpr : public MCExpr { VK_SECREL, VK_SIZE,// symbol@SIZE VK_WEAKREF, // The link between the symbols in .weakref foo, bar +VK_FUNCDESC, smithp35 wrote: While VK_TLSGD_FDPIC are somewhat self documenting

[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)

https://github.com/smithp35 commented: Matching GNU ld seems sensible to me, although best get this reviewed by someone with an X86_64 background. https://github.com/llvm/llvm-project/pull/81224 ___ llvm-branch-commits mailing list llvm-branch-commits

[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/81224 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [ELF] Place .lbss/.lrodata/.ldata after .bss (PR #81224)

@@ -1124,11 +1127,15 @@ template void Writer::setReservedSymbolSections() { } if (last) { -// _edata points to the end of the last mapped initialized section. +// _edata points to the end of the last mapped initialized section before smithp35 wro

[llvm-branch-commits] [lld] ReleaseNotes: add lld/ELF notes (PR #80393)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/80393 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] ReleaseNotes: add lld/ELF notes (PR #80393)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/80393 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] ReleaseNotes: add lld/ELF notes (PR #80393)

@@ -29,8 +29,42 @@ ELF Improvements * ``--fat-lto-objects`` option is added to support LLVM FatLTO. Without ``--fat-lto-objects``, LLD will link LLVM FatLTO objects using the relocatable object file. (`D146778 `_) +* ``-Bsymbolic-non-weak``

[llvm-branch-commits] [lld] ReleaseNotes: add lld/ELF notes (PR #80393)

https://github.com/smithp35 edited https://github.com/llvm/llvm-project/pull/80393 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] ReleaseNotes: add lld/ELF notes (PR #80393)

https://github.com/smithp35 commented: What's there LGTM too, I've suggested a couple of possible additions that you might want to consider. https://github.com/llvm/llvm-project/pull/80393 ___ llvm-branch-commits mailing list llvm-branch-commits@list

[llvm-branch-commits] [lld] ReleaseNotes: add lld/ELF notes (PR #80393)

@@ -29,8 +29,42 @@ ELF Improvements * ``--fat-lto-objects`` option is added to support LLVM FatLTO. Without ``--fat-lto-objects``, LLD will link LLVM FatLTO objects using the relocatable object file. (`D146778 `_) +* ``-Bsymbolic-non-weak``

[llvm-branch-commits] [lld] PR for llvm/llvm-project#79339 (PR #79357)

https://github.com/smithp35 approved this pull request. LGTM for merging https://github.com/llvm/llvm-project/pull/79357 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch

[llvm-branch-commits] [lld] PR for llvm/llvm-project#79339 (PR #79357)

smithp35 wrote: This is good to go for merging, a simple safe change. https://github.com/llvm/llvm-project/pull/79357 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-co