[LLD]
Fixed interworking problem causing Thumb2 kernel not to
Some diagnosis of LLD problem when .ctor and .init_array initialisers are used.
[LLVM-MC]
Upstream reviews for some methods to avoid llvm-mc making symbols
inter-positionable that the code generator has assumed are not.
[Morello]
Buildbots, busy week that took up most of spare time
- deploying timezone fix to containers
- a couple of weekend patches that broke Arm and AArch64 bisected and
followed up.
- difficult to track down stage-2 failure that was difficult to work
out whether there was a bug in clang, or a code-gen
Morello
- Upstream LLD INPUT_SECTION_FLAGS that I implemented downstream.
Quite a few review comments to work through but I think I'm close to
getting something accepted. This will hopefully come in useful for LLD
with embedded systems.
- Wrote down some definitions for the new relocations.
LLD
-
Morello:
- Implemented INPUT_SECTION_FLAGS in LLD for the Morello toolchain,
now in review. Took most of spare engineering time this week. Will
attempt to upstream once committed in Morello
- Fixed pr44451 upstream, it was already fixed on Morello toolchain.
LLD:
- Made an attempt to fix the LLD
Morello:
- Updated clang driver to use lld with --image-base rather than a linker script.
- LLD changes merged.
- Fixed up a few problems spotted by CI and a test on the examples.
- Thoughts on code sequences for an experimental descriptor based ABI.
LLD:
- Committed changes to fix branch patch
Morello:
- Static linking patches committed to merge branch.
- Dynamic linking patches up for review.
- Agreed definition of what LLD for stage-1 looks like.
- Discussions on what linker and ABI work is likely to be needed for stage-2.
Linaro:
Some LLD thunk/patch generation problems
[Morello]
Rebase of LLD against September CUCL update complete
- Painful due to LLD changing address layout (every test expected
value shifted), and a naming convention change.
- No functional changes needed to patch.
- Submitted static linking patches for review. Will send the dynamic
ones after
[Morello]
- LLD finished pre-review refactoring and splitting up into reviewable chunks
- Implemented range-extension and interworking thunks to test
interaction with aligning .text to comply with Cheri Concentrate
- Answered some questions from Linaro tech-leads about Morello
Plans
- Rebase once
[Morello]
- Dynamic linking implementation complete and tests written based on
GNU ld output.
- Good progress on refactoring the work prior to breaking it down into
reviewable chunks. Have got a good idea of what I'd like the
implementation to look like.
TODO:
- Finish refactoring patches.
-
Morello
- Started to document the LLD implementation.
- Implemented CHERI concentrate alignment for the important sections.
- Dynamic linking is feature complete, but not finished yet, still Todo:
-- More test cases for the various different combinations.
-- Refactor to clean up the
Linaro
- On buildbot monitoring duty, relatively quiet week with just a
couple of fairly simple to diagnose problems to report.
Morello
- Dynamic linking progressing albeit slowly.
-- Trying to work out the requirements from existing documents and
implementation.
-- Have some simple cases doing
[Morello]
- Got static linking support to the point that I can successfully link
with LLD the coremark, dhrystone and EEMBC from the arran-toolchain.
Not got any outstanding failures to investigate.
- Altered LLD so a linker script is no longer necessary for newlib.
- Started the process of
On buildbot duty
- Several buildbot failures to investigate along with one linux kernel
regression
- Didn't manage to get the libcxx buildbot failures resolved on time.
I think the community are still trying to fix it (Script needs to be
Python2/Python3
Started work on LLD support for Morello
-
LLVM-579 Implement -fix-cortex-a8 in LLD. Keeping up with review
comments, I think this is getting close now.
Connect slides moving forwards. Now have 2 out of 3 presenters done.
Rest of the week taken up by investigations and LLD reviews.
___
[LLVM-579] Implement -fix-cortex-a8 in LLD.
- Spent the week writing tests, fixing problems and polishing up the
patch. Now sent upstream as D67284
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
- Reorganised buildbots to remove some of the duplication between v7
and v8 AArch32 to free up more v7 hardware.
- Got final code-size information and wrote my slides for Linaro Connect
- Track down an AArch64 specific LLD problem due to a recent change,
now resolved.
- Wrote worst case
- Fixed LLD segfault when exceptions.
- Implement large code model TLSLD relocations in LLD.
- More thoughts on MOVK prel relocations in the ABI as there looks to
be a use case for them in HWASAN that isn't covered by the existing
relocations.
- Some thoughts on how TCWG LLVM Jira initiatives
[PR42719] BasicAA UnitTest failure on AArch64 when compiled with GCC
- Patch submitted upstream
[PR42853] LLD support for TPREL_G0 relocations
- In theory a simple change, but llvm-mc seems to be deliberately
doing something strange with MOVZ encodings fixMOVZ and I haven't
worked out why it is
[ACTIVITY] On buildbot and Linux kernel CI duty
- One obscure alias analysis bug that only failed on GCC on AArch64
that suddenly started failing a unit test. Tracked down to an
unitialised variable when API called directly via unit-test. Test has
been reverted, but I've put enough information in
[LLVM-478] Clang and GCC code size comparison
- Looked at CMSIS-DSP, clang consistently produces smaller code than
GCC in contrast to Zephyr. Recorded some specific areas
- Tidied up scripts and build system patches to post for review
- Wrote up a readme for how to reproduce the results
[Misc]
-
[LLVM-583] LLVM Code Size reduction ideas from Zephyr and CMSIS
- Started a ticket to record areas of improvement where GCC does
better than LLVM.
- Upstream defaults to -mno-unaligned-access for clang which needs to
be corrected for.
- Much of the difference goes away when inlining is disabled,
[Code size investigation]
Results (clang 2% larger than gcc) replicated on cortex-m0 and
cortex-m4 on Zephyr.
- Clang optimisation to use BLX rather than BL when same function
called multiple times is a pessimisation on Zephyr, especially on M0.
- GCC register allocation seems to result in fewer
[LLVM-542] Build Zephyr with clang
- Spent quite a bit of time working out why a Clang built zephy hello
world wouldn't boot, tracked down to a missing clobber list in an
inline assembly block
- Wrote some scripts to collect code size information on the samples.
Some initial figures on mostly
[LLVM-571] Build GNU rmprofile toolchain with Linaro scripts (abe)
The existing build-system was only set up to build the A-profile bare
metal toolchain. Managed to find right combination of flags and
modifications to get a toolchain that zephyr can use.
[LLVM-158] Buildbot maintenance
An
[LLVM-122] BTI and PAC support
Committed the LLD work. Modulo bugs this should now be done.
[LLVM-542] LLVM/GCC code size investigation
- Revisited my Zephy build with clang patches and updated so that it
works with trunk.
- Work out next steps of work.
- Work out to build an embedded gcc
On Thu, 30 May 2019 at 11:28, Alex Bennée wrote:
>
>
> Hi,
>
> Food for thought for today's sync up. I've been writting QEMU plugins to
> exercise the plugin system and see what sort of useful information you
> can extract when you can control the instruction stream.
>
> For example I now have a
3 day week.
[LLVM-122] BTI and PAC support in lld, llvm-readobj, llvm-objdump
- Now in upstream review. Most of the week spent writing and updating tests.
Some time reviewing some asm goto patches patches.
Planned absences:
Holiday Friday 31st May.
[LLVM-122] BTI and PAC support in LLD
Implementation now working, have written BTI tests, next step is
finishing off PAC tests.
[Misc]
Helped out debugging an asm-goto problem on ARM targets.
Investigated a GNU ld LMA overlap when VMA and LMA got out of sync.
Helped out with CMSIS use of ld
[LLVM-158] buildbot maintenance
- Increased timeouts on some libfuzzer tests, aarch64 full bots should
fail less frequently under load.
[LLVM-534] -n -N support in LLD (needed for Linux kernel allyesconfig
CI with LLD on AArch64)
Rewrote using a different approach after upstream comments
[PR40542] Sent patch for -n and -N support in LLD for upstream review
[LTO]
Investigated problems when using -Os -Oz with LTO, raised 2 PRs
- error if clang linker invocation uses -Os and -Oz
- strange error message when .bc used as a file extension for a
separate compile and link step
Crash in
[Conferences]
Linaro connect and EuroLLVM. Please see trip reports already posted. A
bit of a gruelling week of Travel going from Bangkok straight to
Brussels, with just a short half a day in between at home in
Cambridge.
[Activity]
- A number of reviews whilst away
- Started looking at how to
[Activity]
[LLVM-542] Compiling zephyr with clang
- Prepared for presentation/discussion with colleagues at Connect next week.
- Made the installation process a bit more repeatable
- Added support for -Oz
[Intel-CET] patches to LLD (similar to BTI)
- Code-owner has redesigned the patches and they
Linaro connect preparation:
- Finished Linaro Connect presentation on cross compilation with clang
-- Hoping to do a dry-run at Doughnuts this week assuming we can
resolve a potential clash with the IPG hands-on.
- Draft agenda for the hack-room produced.
[LLVM-523] ARM.exidx redesign
- Got
[LLVM-542] Compiling zephyr with clang
- Shared patches with Zephyr team lead, who has integrated them into a
private branch and has locally fixed some of the
incompatibilities/warnings
- Went through the Zephyr samples to get build instructions for the
ones compatible with Arm dev-boards.
- Intel CET review (Related to BTI support in LLD), raised issue of
multiple PT_NOTE sections one per alignment
https://reviews.llvm.org/D59120 , commented on command line options.
- LLVM-523 redesigned the LLD handling of ARM exidx sections to
centralise more of the Arm specific implementation
[LLVM-494] LLD is now turned on for clang linux kernel defconfig builds
[LLVM-542] Worked out how to get Zephyr (Linaro's choice of IoT
embedded OS) compiling with clang. Looks like it is going to be
difficult to get linking with clang/lld so I've used the gcc/ld.bfd
for now.
Linux kernel sent a
[LLVM-158] Monitor and maintain buildbots
- Some work to track down a faulty msan test on AArch64 that was
intermittently failing.
- Spent some time trying to reproduce an intermittent failure in libfuzzer.
[LLVM-523] Synthesise EXIDX_CANTUNWIND entries for sections without tables.
- Not getting
Fosdem:
- Presented on LLD performance at LLVM devroom
https://fosdem.org/2019/schedule/track/llvm/
- Other interesting presentations from the devroom include:
-- Compiling the Linux kernel with LLVM tools
-- Lessons in TableGen
LLVM-523 LLD should synthesise .cantunwind .ARM.exidx sections for
Majority of the week spent preparing for Fosdem talk on LLD:
- Built Chrome for Arm and AArch64 to investigate link time
performance on non-X86 platforms
-- Both gold and bfd take a considerable amount of time to produce
stubs/veneers/errata fixes
-- AArch64 link time is comparable to X86
- LLD
[LLVM-521] LLD and taking the address of an ifunc
Went through the possible combinations (pic, pie, non-pic, exec,
shared,...) found one relocation that gcc uses that clang doesn't,
hence mc and LLD don't support. Raised upstream pr. Also found that
clang's code-sequence for -fpie doesn't seem to
[LLVM-520] LLD Fix movt/movw relocation overflow
Now committed upstream.
[LLVM-521] Taking the address of an ifunc in AArch64
Prompted by a bug report and comment about pointer equivalence, spent
some time looking into gold, lld and bfd behaviour to ensure that LLD
is at least correct.
Other
[TCWG-1492] Add timeout and retry to git fetches in Linaro ci infrastructure.
[LLVM-505] LLD implement --pic-veneer for AArch32 linux kernel (pr39886)
In upstream review
[LLVM-509] Add support for v6m range extension thunks to LLD
In upstream review
pr34928 fixed undefined weak reference handling
[LLVM-499] LLD support for linking the linux kernel
- [LLVM-504] Support for linker script symbol assignment to an alias.
-- Diagnosed problem and made reproducer on PR.
-- Reviewed the upstream patch.
- [LLVM-503] Support for discarding .dynamic, .dynstr and .dynsym
-- Reviewed upstream patch and
[LLVM-493] LLD link failure on KASLR for AArch64 Linux kernel
The linux kernel can build in an ASLR mode that is currently causing LLD
some problems. There are a few oddities in the kernel that aren't quite
right but there are some problems in LLD that need resolving as well. has
been a couple of
[LLVM-486] Error id user defines _GLOBAL_OFFSET_TABLE_ (upstream review)
[LLVM-484] Fix linker script dynamic relocations combination into a single
output section (upstream review)
[LLVM-483] cortex-a53 erratum fix interaction with TLS relaxation (upstream
review)
[LLVM-489] Measure (cross)
LLD bug fixing and triage
pr39678 Calculation of DT_PLTRELSZ with strange linker script.
pr39662 Request to add more emulations
pr39634 LTO and references from inline symbols
D54474 Fix for incorrect relocation span out of ifunc review
D54624 Redefinition of _GLOBAL_OFFSET_TABLE_
[LLVM-203] Using PGO for code size optimization
Communicated results and shared patch with Google Android/ChromeOs and
Fuchsia teams
[LLD] Did some benchmarking of LLD against ld.bfd and ld.gold
On some large applications like Mozilla and Chrome LLD can be up to 10
times faster.
Patch review and
[LLVM-203] Code-Size investigation with PGO
- Finished up the remain tasks and resolved the ticket.
- Tidied up the patches and added tests so that I can potentially
share them with other interested parties.
-- Writing tests took a lot longer than I thought as it involves
faking a profile and
[LLVM-203] Investigation into profiling and code-size optimizations
- Collected the remaining data I needed over the weekend.
- Wrote up report
- Rebased patches on tip of trunk
- Attached results and report to Jira issue.
- A one line summary of the results is that if you are lucky you can
get
[LLVM-203] (was TCWG-1424, we've moved issues to a new project)
Started writing up results to close out this investigation.
- Reran some sample profiling test cases with a higher sample rate.
- Investigated why some test cases exploded in code-size with LTO.
- Got some results for thin LTO
[TCWG-1473] Fix -fno-integrated-as and -mbig-endian (Linux Kernel
Build with clang)
- Needed some revision to handle linker emulation. Patch in upstream review
[TCWG-1474] Fix out of range branch (CBZ) when -fimplicit-it (or
-fno-integrated-as) and certain kinds of inline assembly
- Committed
[TCWG-1473] Fix -fno-integrated-as and -mbig-endian (Linux Kernel
Build with clang)
- Patch in upstream review
[TCWG-1474] Fix out of range branch (CBZ) when -fimplicit-it (or
-fno-integrated-as) and certain kinds of inline assembly
- Patch in upstream review
[TCWG-1424] Code-size investigations
[Linaro Connect]
- Wrote my presentation for the official track (on using Clang
libtooling and ASTMatchers)
- Started working on hackroom presentation on profile guided
optimisation in LLVM.
In both cases writing a presentation on something you don't know much
about forces you do a lot of
Investigated yet another sanitizer related buildbot failure. This time
it looks like latent problems in the compiler-rt/cfi implementation
and tests provoked by the introduction of the Arm LLD bot.
- cfi requires LTO so it requires a bot using LLD or a bot configured
to run gold with the LTO
4 day week, out on holiday Wednesday.
[TCWG Jira]
- Recommendations made on what to do with outstanding epics.
- Will be making the changes on Monday.
[Linaro Connect]
- Research for presentation on libtooling.
- Outline of presentation written and made a start on the first of the examples.
-
[TCWG-1424] Investigation into profile guided information for code size
- Wrote script to process all the data from all the runs and correlate
it with code size.
- Now have some visualisations of some of the data that I can use to
make sense of the output.
- Next step is to prepare a presentation
[TCWG-1450] Support for Tag_ABI_VFP_args in LLD
Needed by FreeBSD in order to switch to LLD for Arm.
[TCWG-1451] Support for v5 and v6 Arm in LLD
Tidied up and submitted patches for v5/v6 (branch encoding and
compatible thunks), in upstream review.
[TCWG]
- Started doing some Jira gardening in
4 day week.
[TCWG-1424] Investigate profile feedback on codesize
Have now got all the data I need, started the process of tidying up
scripts to analyse whether it is worth posting upstream and what the
best default parameters are.
[Misc]
Track down problem on AArch64 build-bot to a likely
Hello Alex,
Sorry for the late comments. I think that looks good to me as a
proposal for Connect. I spotted a couple of typos that I've
highlighted inline. Would it be worth mentioning if you are going to
cover bare-metal system emulation or concentrate on Linux?
Peter
On 23 July 2018 at 15:07,
[TCWG-1424] Using profile feedback to investigate code size
- Have most of the information I need to draw some conclusions. Should
have the remaining runs I need over the weekend.
- Next step is to analyse the data a bit more formally and write up.
- Discuss next steps. It may be worth polishing
4 day week, on holiday monday
Submitted a Linaro Connect presentation.
[TCWG-1424] Investigate profile feedback for code-size
Frustrating week trying to plug profile feedback into builds and
benchmarks and get sensible results
- First attempt was to use clang 2 stage pgo build
-- New pass
[TCWG-1368] Tracked down libfuzzer buildbot failures on aarch64 and raised PR
[TCWG-1424] Use profile information for size optimisation
- Decided to use clang's 2-stage PGO build as next experiment with
compile times on the full test suite as the performance benchmarks
- Spent rather too much time
[TCWG-1424] Profile guided information code size investigation.
- Wrote up initial findings in Jira
- Have written a pass that works with both the new and old pass
manager that I can use to selectively add size optimisation attributes
to functions.
- Spent way too much time trying to work out
TCWG-1319 ICF support in clang and lld
- Reviewed LLD patches
TCWG-1424 Investigate profile information for code-size
- Spent some time tracking down problem with using perf=profile and
run_under simultaneously. Posted patch upstream.
- Investigated how llvm makes use of profile information and
[ACTIVITY]
- Landed D44928, we should pass the subtarget through to fixups and
relaxation now. The only remaining use of the subtarget in the
assembler backend is for writeNop(). Patches to fix that are upstream
but I'm not hopeful that anyone will want to review them due to the
cost/benefit.
-
[ACTIVITY]
Upstream reviews for LLD. Trying to be more proactive here now that
there are fewer maintainers.
[TCWG-1420] Initial investigation into some proposed linker
enhancements for embedded systems
- Mostly features already implemented in proprietary linkers such as
AT and an equivalent to
Half of the week spent investigating identical code folding -icf=safe.
Turns out that upstream have a proposal that is much further along so
shifted focus on to doing as much as I can to help it along.
Found out that for some use cases of AArch64 PIC the small code model
is inappropriate as the
[Activity]
[TCWG-1319] Link AOSP with LLD.
Closed this out as I've gone as far as I can profitably go without
being an Android expert.
- With trunk LLD I can now link and boot AOSP with LLD without any
use_clang_lld=false on both Arm and AArch64 emulators. I also managed
to get it to boot on a
4 day week
[TCWG-1236] Android on LLD
Android team have switched to LLD by default for most modules. Looking
to switch over the course of a release.
I've been looking at the list of modules that don't work with LLD and
investigating.
- Sent some patches upstream to add some missing features
[Activity]
[TCWG-1384]
- Implemented missing TLS LE relocations in LLD
- Found out while testing that LLVM had the range check in locally
resoloved fixups for Thumb2 BL wrong, and was not range checking B.w
or Bcc.W at all. Patches submitted for review.
[LLD]
- Submitted extra test cases to
Progress:
Monday Tuesday at Euro LLVM, trip report at
https://collaborate.linaro.org/display/CR/20180416+EuroLLVM+2018
Found an example that shows that both gold and ld attempt to fix up
illegal "by strict interpretation of ELF" local debug references to
discarded local symbols from rejected
[TCWG-1375] Make sure MCSubtargetInfo is passed through to
ARMAsmBackend functions
Spent most of the week working on this and follow up patches. Have
submitted a patch for the most important functions. Nearly have one
ready for the correct Nop encoding, this is more complicated as Nops
can be
Hello Godmar,
This is a very difficult question to answer as it will depend a lot on
the constraints of the OP-TEE environment and what subset of the C++
language and libraries that the developers are willing to support. I
can speak a little bit about generic support of C++ in embedded
systems
4 day week.
[TCWG-614] Range Extension Thunks
- Rebased due to upstream refactoring
- Pinged but no upstream review progress
[Compiler-rt]
Clang no longer always uses base PCS for all the builtins it expands
such as the _Complex helpers.
- Added tests to make sure RTABI 4.1.2 Floating Point
[TCWG-614] Range Thunks
Finally managed to get some review on the entirety of the Range Thunks
patches. Have reorganised the patches and wrote some documentation to
make it easier to review. Responded to all review comments so far.
Compiler-rt
A long tail of frustration.
Managed to get a hello
Achievements:
Some progress on Range Thunks. [TCWG-614]
- I have all the enabling patches that allow assignAddresses() to be
run multiple times committed.
- Need review for the actual range thunks implementation itself.
Compiler-rt [TCWG-1156]
- Clang (as opposed to llvm) is assuming that all
== Activity ==
- Rebased and posted for review all my range-thunks work for LLD as
there had been some interest from some individuals on IRC in trying
out the patch.
-- Seems to work for them
-- Hoped that this might provoke upstream into looking and reviewing
the patches but no such luck.
-
[TCWG-614] Range extension thunks
- No progress on upstream reviews from maintainers this week
I have received some interest on IRC and on at least one of the
reviews from other people wanting the feature so I'm hoping that this
may speed up the process.
- I've committed to rebasing and posting
== Progress ==
LLD
- Committed refactoring patches to enable long range thunks. This
should unblock progress towards upstreaming patches.
- Rebased and sent out for review first patches in series. Expecting
slow but steady progress as I hope to not need much more large scale
refactoring.
== Plans
Progress
- Long range thunks
Committed a couple of refactorings on .ARM.exidf and SHF_LINK_ORDER
support. With luck final patch for SHF_LINK_ORDER will be approved
next week
Submitted patches to convert existing Thunk Implementation to use
InputSectionDescriptions. Hopefully these ones are
Progress
- Long range thunks
Made some more progress on the refactoring needed to merge the
representations for the script and non-script cases. Close to getting
the .ARM.exidx sections converted.
- Some thoughts on https://reviews.llvm.org/D33436 to do with
ARM/Thumb interworking in the
Achievements:
Spent all week on investigating a potential problem with the Gold
--fix-cortex-a53-843419 erratum fix (The ADRP on 0xff8/0xffc boundary)
- Managed to reproduce with a smaller example, although still using LTO
- Diagnosed the cause of object with errata stubs being relocated
after
Progress:
- Re-implemented range thunks based on recent upstream changes and
sent for review. No comments as yet.
This is likely to be an ongoing conversation with upstream that won't
take all my time up so I've been looking at some additional stuff
outside of range thunks.
- Looked at PR28647 in
== Progress ==
[TCWG-614] Long Range Thunks
- Posted for upstream review. I may have to do some refactoring of the
address allocation first to unify the linker-script and non
linker-script cases.
- Started work on a prototype that fabricates linker script commands
for the default non
[Eurollvm]
Attended, we have recorded our thoughts in EuroLLVM 2017 Recap doc
[TCWG-614] Range extension thunks
- I've finished my downstream implementation, and have written almost
all the lld tests I'd like to write
- Still need to test on real large programs such as libclang.so
- Made a start
Achievements:
[TCWG-614] Range extension Thunks
- About 3 hours in total of rebasing due to upstream refactoring
- Have finished the non-linkerscript tests and fixed all the bugs
detected by them
- Started the linkerscript tests, no problems found so far
[TLS]
- Some explanation to upstream of
[TCWG-614] Range extension Thunks
Worked all week on this. I've got a prototype that is nearly feature
complete. It passes the existing tests when run in a single pass. I'm
now trying to get it to run in multiple passes.
Plans
[TCWG-614] Range extension Thunks
Start adding tests for the new
2 day week:
== Activity ==
[TCWG-617] Range extension thunks
- rebased patch after coming back from holiday, took some time as
quite a bit had changed, patch still in upstream review.
- Have downstream patches to make inline thunks work with linker
scripts, will post for review next week.
==
1 day in office this week
== Activity ==
[TCWG-617] Range extension thunks
- Reworked patch to finalize dynamic content early and resubmitted for
upstream review
- Investigated what I'll need to do to handle linkerscripts
[BUD17]
Uploaded slide deck
== Plan ==
On holiday till Thursday 1st March
[TCWG-617] Range extension thunks
- Did some refactoring to allow addresses to be assigned to sections
prior to Thunk creation
-- In upstream review
- Investigated lld's implementation of linkerscripts and found out
that they will need some refactoring as well
-- Need to assign addresses more than
== Progress ==
[TCWG-617] Upstreamed a patch to make copy relocations use synthetic
sections. This allows us to remove the output section relative dynamic
relocation which is important for range extension Thunks
Did some design work for range extension Thunks.
Did some refactoring to merge PLT
[TCWG-614] Range extension thunks
- LLD now uses synthetic sections for Thunks.
ARM Thunks now have symbols and mapping symbols.
As a side-effect we can now create local symbols in synthetic sections
so I've added them to the ARM PLT sections.
[Misc]
- Wrote 3 lines of lld 4.0 release notes for
[TCWG-614] Range extension thunks
Started process of upstreaming the conversion of Thunks to SyntheticSections.
- Patch 1 of 3 committed, move Thunk Creation later in the link step.
- Patch 2 of 3 add support for local symbol creation in upstream review
- Patch 3 of 3 waiting for patch 2
Made a
[TCWG-614] Long branch thunks:
Implemented a prototype of the existing Thunk implementation using
Synthetic (Linker created sections) and moved it close to the area it
will need to go for Long Branch Thunk work.
Worked on this exclusively all week.
Plans for next week:
[TCWG-614] Long branch
Progress:
TCWG-829 Ifunc support
- Refactored implementation using synthetic sections upstreamed. Found
out that x86 ifunc was broken and probably hadn't ever worked so I
fixed that while I was there.
PR31332 x86 pic plt sequences broken
- Found out that x86 pic and pie is broken in lld, the
-- Progress --
TCWG-829 IFunc support
I have a downstream implementation of ifunc using synthetic sections
that handles x86_64, ARM and AArch64. I think it may be a bit too
complex to upstream in its current form but I think it is illustrative
enough to post upstream for comment.
TCWG-828 Static
Progress:
[TCWG-940] LLD test failures on libcxx and libcxxabi
- Reported bug upstream. Upstreamed a patch to LLD to add a sentinel
value. This will mean that lld linked executables won't trigger the
bug.
[TCWG-901] Investigate LLD as a system linker on ARM
- All the llvm and lld test failures
Progress:
[TCWG-940] LLD test failures on libcxx and libcxxabi
I think this is a latent bug in libunwind's .ARM.exidx table entry
search that happens to be exposed by lld. Will try and make a
reproducer using ld.bfd and report upstream if I'm correct.
[TCWG-901] Investigate LLD as a system
TCWG-901 Investigate lld as a system linker
- Installed lld as the system linker on my Chromebook and attempted to
build and run things to see what breaks
- Only one unknown concrete problem found so far, thunks to undefined
symbols with PLT entries don't work. This seems to be common in python
C
-- Activity --
[TCWG-683] Branch to undefined weak on aarch64 and arm
Fix in upstream review, looks pretty close to being accepted.
[TCWG-828] TLS support for static linking
In upstream review but no comments as yet
[TCWG-829] IFunc support
In upstream review, but will probably need to be
1 - 100 of 118 matches
Mail list logo
