[ACTIVITY] Week ending 31st January 2020

[Peter Smith]

[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]
reviews.

[Other]
Clean up my Jira tickets so that they can be passed on or closed.

This is my last week as a Linaro assignee, will be going back to the
Arm as of next week. I've really enjoyed my time here, thank you for
having me.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 24th January 2020

[Peter Smith]

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 failure in the
backend, also made it harder to bisect. Turned out that it had caused
more easy to bisect failures in other projects and by the time I'd
found the patch it had been fixed.

[ClangBuiltLinux]
LLD's simplified interworking looks to be insufficient for the linux
kernel thumb-2 build. Got agreement with upstream on how to proceed.
Have a patch ready to send upstream.

A small amount of upstream review and bisecting some Linaro CI build
failure for the -fpatchable-functions feature in Clang-10. Looks to
have been resolved.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] for week ending 17th January 2020

[Peter Smith]

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
- landed fix for clang-built-linux-812 linux allyesconfig problem.
- Quite a few upstream LLD and MC reviews

Other
Some research for the clang built linux conference.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 10th January 2020

[Peter Smith]

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 linux kernel allyesconfig +
cortex-a53 erratum problem. Was not successful as kernel linker script
is just about as awkward as possible for this problem. I have a good
idea of what to try next. Will aim to fix early next week.
- Quite a few upstream reviews, some pending from last year.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 13th December 2019

[Peter Smith]

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 and thunks interaction in
instrumented Chromium build
- Discussion about deploying BTI in large programs like Chromium with
pre-compiled objects and lots of assembler files.

Planned absences
On holiday for the rest of the decade. First day back in the office 6th January
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 3x3 for week ending 6th December 2019

[Peter Smith]

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
https://bugs.llvm.org/show_bug.cgi?id=44071 for a gigantic build of
Chromium > 260 Mb .text section on AArch64. Diagnosed problems but
will need to fix next week.
Some support for ClangBuiltLinux with respect to some integrated
assembler compatibility with GNU as.

Buildbot duty.
Pretty quiet, attempted to reproduce some timeouts seen on the LNT
generate cmake. 3 minutes on an lightly loaded machine, exceeding 20
minutes in some cases on the heavily loaded buildbot host. Seems to
have resolved itself with the latest container update.

- Some changes to BTI for the Android team. All committed upstream.
-- Adding PT_GNU_PROPERTY support.
-- Increasing alignment of .note.gnu.property section to 8.

Holiday
- On holiday from Monday 16th to 3rd January inclusive. Back in office
January 6th.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 29th November 2019

[Peter Smith]

[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 all static linking has been merged.
Wrote up notes of Linaro Tech-leads Morello Q

Misc:
Upstream LLD reviews
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 22nd November

[Peter Smith]

[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 CUCL merge has been completed and submit for review.

Planned Absences:
Christmas Holiday 16th December - 3rd January inclusive
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 15th November 2019

[Peter Smith]

[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.
- Rebase into reviewable patches.
- Document the design decisions.
- Test on more than just the examples in the toolchain.
- Rebase on top of latest CUCL drop when merge is finished.

[Other]
LLVM-MC upstream review for the Linux Kernel.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 3x3 for week ending 8th November 2019

[Peter Smith]

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 implementation.
-- Rebase all the patches to remove the false starts.
-- Update the documentation I've just started as it is already out of date.
-- Not looked at ifunc or TLS yet.

llvm-mc
Some review on MC patch to allow limited symbolic computation when
evaluating .if
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 1st November 2019

[Peter Smith]

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 mostly the right thing and have
written some tests.
-- Will need to rewrite to move calculations earlier in the link-step.
-- Morello is quite different from Cheri in this regard so I have had
to diverge much more from the implementation.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 3x3 for week ending 18th October 2019

[Peter Smith]

[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 rebasing and adding tests for all the
fixes/hacks I needed to make to the linker work.
- Aligned the base and limit of capabilities according to the incoming
CHERI concentrate scheme. Interesting question of what should a linker
do when alignment requirements on the base and limit cross section
boundaries, and what are the responsibilities for an object producer
when creating a section when the length of the capability is known at
compile time.

Planned absences:
Holiday Thursday, Friday (24th, 25th October)
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 4th October 2019

[Peter Smith]

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
- Getting familiar with the toolchain
- First target is sufficient support to statically link the Howdy
"hello world" equivalent.
- Made the first couple of local patches to implement the easiest set
of static relocations.
Some upstream LLD patch review.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] for week ending 13th September 2019

[Peter Smith]

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.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 6th September 2019

[Peter Smith]

[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
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] week ending 23rd August 2019

[Peter Smith]

- 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 thunk/veneer convergence patch to help move through
an iterative symbol assignment algorithm.

UK Bank Holiday Monday
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 9th August 2019

[Peter Smith]

- 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 could be worded and
how we may want to word them in the next cycle.
- Initial thoughts written down on Connect presentation, need to flesh
out more this week.
- Upgraded machine to 18.04, almost managed to break it in the process
but luckily it was recoverable. Will likely have some teething
problems.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 1st August 2019

[Peter Smith]

[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 needed.
Investigations with respect to inline assembler constraints.
- Some patch review comments for my ABE (Linaro GCC build system)
patch for GCC RM multilibs
- LLD review for smaller AArch64 images.
- Wrote a summary of what TCWG do for the upstream community, may turn
into a Linaro blogpost
- Raised GCC PR91299 to cover incorrect weak definition inlining in
GCC LTO in presence of non-weak definition.

On holiday Friday 2nd August, back in the office on Monday.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 26th July 2019

[Peter Smith]

[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 a PR for an AA
expert to either fix the test or initialise class member pointer to
nullptr.
- A long review of an LLD patch that changes page-alignment rules and
this has impact on the TLS address. Spent way too long trying to
reverse engineer why the formula used would work, needed to find the
corresponding loader code to find the other side.
- Assertion added to LLVM triggered a failure in Linux kernel build,
reproduced example and forwarded on
- Code size investigation Linaro Connect proposal accepted, now have
to write it.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 19th July 2019

[Peter Smith]

[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]
- LLD reviews for reducing image-size using some VA/PA address alignment tricks.
- MC and LLD changes to add MOV[WNZ] relocations.
- Looked into why our container might be giving Resource unavailable
during ninja check-all

Some thoughts on ABI process.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending Tuesday 9th July

[Peter Smith]

[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, implying
that different inlining strategies could be most significant
difference.
- Sent in Linaro Connect presentation submission to cover all of TCWGs
code-size improvement work.

Planned absences
- Rest of this week, back in the office on the 15th July
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 5th July 2019

[Peter Smith]

[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 spills
TODO: Get an estimate of how much code-size difference is down to
different inlining decisions.
On CMSIS DSP cortex-m4f clang appears to be producing smaller than
GCC, not measured averages yet.

[LLD]
- Quite a few upstream reviews, PRs and investigations surrounding them.
- Likely that LLD will be converting to the new variable naming convention.
- Received a request to add cortex-a8 erratum fix for Google Android team.

[Linaro Connect]
Registered and contacted travel.
Drafted a submission for presentation, will submit next week.

Planned Absences:
On holiday Wednesday, Thursday, Friday next week
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 21st June 2019

[Peter Smith]

[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 cortex-m3 put llvm -Oz trunk about 2%
larger than arm-none-eabi-gcc (9.1.1) -Os with frame pointers
disabled. The samples are making very little use of the library
(newlib built with arm-none-eabi-gcc).
- Working out which samples will build with cortex-m0.
- Investigated latest version of bloaty mc bloat face a code size tool
from Google. Has some interesting features including an inline
detection feature that can map a portion of a function's code size to
inlined functions.

 Misc:
LLD reviews and mailing list comments.

Planned Absences:
Likely to take some holiday around 13th July
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 14th June 2019

[Peter Smith]

[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 interesting failure introduced in LLD, but causing segfaults in
2-stage build, now fixed.
[LLVM-542] Zephyr code size investigation
- Rebased modifications to Zephyr
- Wrote script to build all the examples with GCC and Clang
- Fixed problems with modifications found by building all the examples
- Clang built helloworld no longer booting, need to investigate
- Found some areas for more investigation:
-- llvm-objcopy missing --gap-fill (used by one of the sample programs)
-- lld missing --print-memory-usage, while I'm using gcc for the main
link, zephyr build system seems to be feature testing using clang bare
metal default linker (lld)
-- clang always generates .note.GNU.stack, gcc embedded does not,
leading to lots of orphan section warnings. Probably best solved by
linker script modification.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending Friday 7th June

[Peter Smith]

[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 toolchain using the linaro infrastructure.

[Misc]
Reported bug in gold whereupon it would generate v4t veneers for v8-a CPUs

Still waiting for TK-1 board to finish building clang so that it can
run the testsuite. Hopefully finished over the weekend.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Plugin ideas/experiments

[Peter Smith]

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 plugin that can break down instruction counts
> for any given run, for example a kernel boot:
>
>   Instruction Classes:
>   Class:   UDEF   not counted
>   Class:   SVE(68 hits)
>   Class: Reserved (0 hits)
>   Class:   PCrel addr (4589078 hits)
>   Class:   Add/Sub (imm,tags) (0 hits)
>   Class:   Add/Sub (imm)  (26832113 hits)
>   Class:   Logical (imm)  (74304974 hits)
>   Class:   Move Wide (imm)(10933759 hits)
>   Class:   Bitfield   (71470957 hits)
>   Class:   Extract(85655 hits)
>   Class: Data Proc Imm(0 hits)
>   Class:   Cond Branch (imm)  (37227632 hits)
>   Class:   Exception Gen  (6 hits)
>   Class: NOP  not counted
>   Class:   Hints  (244825554 hits)
>   Class:   Barriers   (1668558 hits)
>   Class:   PSTATE (202144 hits)
>   Class:   System Insn(7132992 hits)
>   Class:   System Reg (2268308 hits)
>   Class:   Branch (reg)   (6280976 hits)
>   Class:   Branch (imm)   (18347905 hits)
>   Class:   Cmp & Branch   (180167025 hits)
>   Class:   Tst & Branch   (4092972 hits)
>   Class: Branches (0 hits)
>   Class:   AdvSimd ldstmult   (0 hits)
>   Class:   AdvSimd ldstmult++ (0 hits)
>   Class:   AdvSimd ldst   (0 hits)
>   Class:   AdvSimd ldst++ (0 hits)
>   Class:   ldst excl  (160861365 hits)
>   Class: Prefetch (0 hits)
>   Class:   Load Reg (lit) (12828544 hits)
>   Class:   ldst noalloc pair  (0 hits)
>   Class:   ldst pair  (60381349 hits)
>   Class:   ldst reg   (0 hits)
>   Class:   Atomic ldst(0 hits)
>   Class:   ldst reg (reg off) (0 hits)
>   Class:   ldst reg (pac) (0 hits)
>   Class:   ldst reg (imm) (119597941 hits)
>   Class: Loads & Stores   (0 hits)
>   Class: Data Proc Reg(113586343 hits)
>   Class: Scalar FP(0 hits)
>   Class: Unclassified (0 hits)
>
> You can break down each class to individual instructions. For example
> the Hints are mostly:
>
>   Individual Instructions:
>   Instr: wfe  (132400072 hits)(op=0xd503205f/  
> Hints)
>   Instr: sevl (66433640 hits) (op=0xd50320bf/  Hints)
>   Instr: yield(29619246 hits) (op=0xd503203f/  Hints)
>   Instr: wfi  (2865 hits) (op=0xd503207f/  Hints)
>
> So I'm looking for a similar experiment that would be useful for the
> memory sub-system. When I chatted to Maxim we thought maybe a simplified
> cache line simulator might be useful. The aim wouldn't be to simulate
> what a real cache might do but to be useful say for identifying regions
> of code which might be susceptible to cache line bouncing. So as
> compiler writers what sort of run time memory behaviour would you like
> to track? What sort of information would be useful to extract with such
> a tool?
>
> I'm open to ideas ;-)
>

In our embedded compiler team we used a fast model plugin to check
that our cortex-m3 execute-only code did indeed not read the
executable instructions (no literal pools etc). You may have this
emulated already though. Another demo I saw was a cache visualisation
plugin that gave a graphical display of the cache as the program was
running. Pretty, but sure did slow the model down.

Peter

>
> --
> Alex Bennée
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 30th May 2019

[Peter Smith]

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.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 24th May 2019

[Peter Smith]

[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 scripts when using a fast-model,
needed to get LMA == VMA for program header covering BSS.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] Week ending Friday 10th May 2019

[Peter Smith]

[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

[LLVM-122] BTI and PAC support in LLD
Wrote an implementation, it compiles, but completely untested as of today.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending April 26 2019

[Peter Smith]

[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 GNU ld when linking LLVM lto via the gold plugin. Looks like
a memory access/corruption problem in the conversion from .bc to bfd.

Other miscellaneous reviews for some linker script support in LLD.

Investigation into why ld.bfd with NOLOAD on the .gnu.build-id section
corrupts debug information.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending Thursday 11th April 2019

[Peter Smith]

[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 build an embedded toolchain with Linaro's
ABE and work out how to fit it into their infrastructure.

Planned Absences
Holiday 12- 16th, back on Wednesday.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending Friday 29th March 2019

[Peter Smith]

[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 look a lot better and
more likely to go in. Shouldn't be too difficult to build BTI on top
of.

[LLVM-523] .ARM.exidx redesign
- Now committed, and has stuck for at least a day without needing to
be reverted.

Linaro Connect
- Preparations for hack room
- Gave dry run of presentation for Doughnuts. Will need to cut out
some material to get through in time.

Next week:
At Linaro Connect
Then at EuroLLVM
Then most likely on holiday for remainder of that week.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 23rd March 2019

[Peter Smith]

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 approval, committed and then reverted my exceptions redesign due
some build-bot failures. Found another potential problem with
--emit-relocs that may be a bit more difficult to fix.

[BTI]
Continuing to review and make suggestions for Intel CET patch
(pre-requisite for BTI due to common use of .note.gnu.property
sections)

Some more communication with Linux Kernel port to Arm with respect to
assembler problems.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 15th March 2019

[Peter Smith]

[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] patches to LLD (similar to BTI)
- Reviewed patches and made suggestion for an alternative design. Will
need to re-review the follow up this week.

[LLVM-523] .ARM.exidx redesign
- Responded to review comments, will need to ping again this week.

Linaro Connect
- Preparations for hack room
- Started on Presentation on cross compilation, need to finish slides this week.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 10 March 2019

[Peter Smith]

- 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 details in one
place. Hope to post upstream to get some movement on the review to add
missing .ARM.exidx sections for chrome OS team.
- LLVM-542 Managed to build most of the Zephyr examples for clang,
shared patches to do so with zephyr tech lead.
- Some research for some ABI topics.
- Some thoughts for Linaro connect activities, started team calendar.

Next week:
- Start on my connect presentation
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending March 1st 2019

[Peter Smith]

[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 draft patch to try and alleviate some object
ordering problems that arise when linking the linux kernel with LTO.

[Misc]
Intel patch to add CET to LLD https://reviews.llvm.org/D58102
I mention this as this is related to BTI and CFI and
.note.gnu.property sections. There has been some pushback to the use
of .note.gnu.property sections, and in Intel's case their 2 level PLT
scheme although it seems like as this has been mitigated by the
presence of this option in gcc for some time. I have noticed that we
tend to do design of a feature in one community (LLVM, GNU) and then
attempt to win over the other one with leverage that the other
community supports it. We may need to cast our early feedback net a
bit wider to mitigate the chance that one of the communities blocks
one of our features.

There was an interesting RFC on a linker feature for improving
code-size for mobile phones
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html in
essence an application is developed with loadable features implemented
in DSOs loaded by dlopen. The entry points of the DSO are recorded,
then all the input objects are given to the static linker which then
performs LTO and creates stripped down DSOs that must be loaded at a
specific offset from the application (shrinking them but losing the
shared part of DSO).
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending Friday 22nd February 2019

[Peter Smith]

[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 much response from upstream beyond a vague suggestion to
rewrite the whole of .ARM.exidx handling as a single custom section. I
may have to go down this path to get the feature accepted, even if it
is to show that it is a bad idea.

[LLVM-496] LLD in linux kernel
- Submitted patch to ignore -p (--no-pipeline-knowledge) which is used
by the AArch32 linux kernel.
- Submitted patch to integrate LLD in TCWG kernel regression test.
- Learned, the hard way, about how the linux kernel build system works
and how to pass extra flags.

Reviews:
Spent an awful long time looking at how clang passes options to GNU as
to try and match the existing clang defaults. I'm not sure I've seen
anything much more confusing than tracing through target features from
clang to llvm and back again.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 8 Feb

[Peter Smith]

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
sections without them
- Implementation and regression tests done. Will do a bit more testing
and post upstream on Monday.

LLVM-521 Taking the address of an ifunc in LLD
- Spent some time reviewing upstream patch that should fix the
remaining LLD ifunc address equivalence problems for all Targets.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 25 Jan

[Peter Smith]

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 gets more usage out of multithreading than gold
- Studied Gold and BFD structure to compare to LLD
- About half of slides written.

Some minor involvement with some investigations for ClangBuiltLinux.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 18 Jan

[Peter Smith]

[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 guarantee ifunc
pointer equivalence when linking -fpie (non-got generating sequence
used when ifunc is in same translation unit). Will need some further
investigation to confirm.

[LLVM-499] Support for linking the linux kernel
Committed -pic-veneer support and associated overflow fix, now merged
to 8.0 branch.

Other:
- Started work on Fosdem presentation on LLD performance. Studying
ld.bfd and ld.gold source code to look for structural differences
between them and LLD.
- Submitted presentation for next Linaro Connect
- Review for comdat group and unused section elimination.
- On buildbot duty.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 11 Jan

[Peter Smith]

[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
Some investigation into LLD non-support of common-page-size and
whether this is significant for code-size. Used in response to query
about whether LLD should change default value of max-page-size.

Thoughts about whether a linker must generate cantunwind .ARM.exidx
sections for code sections missing a .ARM.exidx section. If C++ code
with exceptions is interleaved with some assembly code without
.ARM.exidx sections then the assembly code can match the address range
of the C++ code that precedes it.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 10 - 14 December 2018

[Peter Smith]

[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 for AArch64

Spent quite a bit of time revisiting cross-compilation of compiler-rt
after helping out on llvm-dev. Posted a review D55709 to improve the
documentation.

Planned Absences
Next 3 weeks on Christmas holiday back Monday 7th January
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 3 - 7 December 2018

[Peter Smith]

[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 proposed testcase that is
representative of the kernel use case.

Some revisiting of scripts and advice on how to cross compile clang
libraries. Looks like I have some updates to do to the documentation
for some configurations I haven't tried before.

- 2 days at ARM internal Codegen conference. Really good event,
standard of work was very high, left enthused.

Planned absences:
Christmas Holiday from 17th December to 4th January
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 30th November 2018

[Peter Smith]

[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 interesting days trying to work out why some strange
options have been used.

[LLVM-484] LLD combination of dynamic relocs into a single section
Committed upstream
[LLVM-486] Error if user code defines _GLOBAL_OFFSET_TABLE_
Committed upstream
[LLVM-489] Measure (cross) linking of performance of LLD on Chrome
Performance of linking AArch64 matches X86, roughly twice as fast as
ld.gold and five times faster than ld.bfd.

[TCWG-1492] Investigated why git-clone and git-fetch might hang/deadlock.
Back up might be to put a timeout/retry.

[Other]
Submitted LLVM team goals for the TCWG team

Wrote up how TCWG use Jenkins and CI, now in Confluence.

Planned Absences:
ARM internal Compiler conference 4th/5th December
Christmas holiday 17th December - 4th January
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] week ending November 23rd 2018

[Peter Smith]

[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) linking performance of LLD for AArch64 and Arm.
Looking for large projects that I can build for Arm and AArch64
- Firefox seems to have some ARM Android cross build support but it does
not appear to be working too well.
- Chrome can cross build to ARM and AArch64 Android. Have been able to
build AArch64 so far.
Notably both projects don't support building natively on AArch64, there are
quite a few build dependencies for which only x86 support is available.

Raised Jira tickets for recent PRs fixed

2019 Planning
- Drafted objectives document for LLVM team
- Drafted some Jira suggestions for TCWG
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] week ending Friday 16th November

[Peter Smith]

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_
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 9th November 2018

[Peter Smith]

[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 debug triage:
https://bugs.llvm.org/show_bug.cgi?id=39587
https://bugs.llvm.org/show_bug.cgi?id=39571
https://reviews.llvm.org/D54314
https://reviews.llvm.org/D54145
https://reviews.llvm.org/D54265
https://reviews.llvm.org/D53980
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending November 2nd 2018

[Peter Smith]

[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 there were quite a few caveats to doing that.

Some prototyping in LLVM and LLD for some internal ABI discussions.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 26th October 2018

[Peter Smith]

[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 close to peak performance at close to Os code size if your program
happens to spend most of its time in a few small places. If you are
unlucky then increased inlining and unrolling can still result in an
overall code size increase over -O3 but the effect will be limited.

[LLVM-158] Monitor and maintain buildbots
- Relatively quiet week, a couple of patches pinged for fixes/reverts.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 18th October

[Peter Smith]

[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 (broadly similar to LTO).
- Discovered that I need to pass in extra linker options to enable LTO
to use the new pass manager, sample profiling and setting of
optimisation level.
-- Need to rerun these configurations over the weekend.
- Have most of the surrounding text of the report written, now need to
work on presentation of results.

[TCWG-1473] Fix big-endian linux kernel builds for AArch32
Now committed upstream

Holiday Friday
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 12 Oct

[Peter Smith]

[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 upstream.
[TCWG-1424] Code-size investigations with PGO
- Marking functions for size optimisation at the earliest possible
stage improves code-size for little loss in performance. The main
beneficiary is that loops are not unrolled in size optimised functions
and inline thresholds are lower.
- LTO with instrumented profiling still sees large increase in size.
Originally thought my changes weren't working with LTO but I think
that something else is happening.
-- Found out that the profiling information isn't being sent to the
LTO code-generator (although it should be present as IR annotations
from the objects.
-- There is an option to pass the sample profile through to the LTO
code-generator but not an instrumented profile file.
-- It seems like the LTO plugin doesn't use the new pass manager
unless a separate option is passed through to the code-generator.
-- It seems like Thin-LTO is where most of upstream development is
these days and there is a slightly different pass pipeline, and some
interaction with profiling. Worth some more experiments.

First draft made of incorporating YVR18 Jira discussion into
Confluence 
https://collaborate.linaro.org/display/TCWG/JIRA+Usage+and+Best+Practices
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 5th October

[Peter Smith]

[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 with PGO
- Reworked the clang command line options and pass manager interface
so I could insert the pass prior to inlining.
- Benchmarks running over the weekend.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Weekly report for week 36

[Peter Smith]

[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 learning.

Plans for next week:
- Finish hackroom presentation.
Spare time will be spent on reviews and llvm/clang bugs
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending Aug 24

[Peter Smith]

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 plugin. Raised upstream PR on cfi.

[Linaro Connect]
Made some more progress on a clang-tool example to use for my
presentation on how to build a clang tool. Learned quite a bit more
about ast-matchers and the clang-ast.

[LLD]
Committed support for Armv5 and Armv6 in LLD.

[Miscellaneous]
Quite a heavy patch review week.

Planned absences:
On holiday on Tuesday
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 17 Aug

[Peter Smith]

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.
- Will be doing a further presentation in the hack-room on LLVM
profiling and code-size

Involved in more than the usual amount of reviews.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending Aug 12 2018

[Peter Smith]

[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 for the Connect hacking room
on the output.

- Jira sweep for TCWG LLVM epics in preparation for upcoming connect.
- Presentation for Linaro connect on Clang Tooling accepted, a
bittersweet moment as I've got to write it now.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 3 Aug

[Peter Smith]

[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 preparation for status report
- Went back to libfuzzer hang on AArch64 buildbot. Looks like failure
to converge on -O2 and above, from the logs and code-generation I
suspect that it isn't handling the CINC instruction well (not
increasing coverage when the condition passes).
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 27 July

[Peter Smith]

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 code-gen problem
in Clang 3.8 for AArch64 only. Wrote a patch to use clang 6.0 on all
the Linaro buildbots rather than just the libcxx builder. Will
hopefully get deployed next week.

[LLD] Work on adding support for EF_ARM_ABI_FLOAT_HARD and EF_ARM_ABI_FLOAT_SOFT
Needed to unblock freebsd from moving onto trunk
Mostly done, just need to finish adding tests. Might be a good jumping
off point to implement full build attributes support.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Abstract: My Other Machine is Virtual

[Peter Smith]

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, Alex Bennée  wrote:
>
> Following on from last weeks discussion here is an alternative abstract
> which instead of looking to the future with where QEMU can go would
> concentrate on what you can do with QEMU now. What do you think?
>
>  _
>
>   MY OTHER MACHINE IS VIRTUAL
>
>   Alex Bennée
>  _
>
>
>  YVR18
>
>
> When working with new architectures there is often a scramble for
> getting access to hardware. However hardware comes with it's own
> problems - especially when it's new. It's hard to upgrade, hard to poke
> around inside and hard to experiment with.
>
> This is an area where QEMU can help. Thanks to it cross-architecture

Typo: it -> its "Thanks to its cross-architecture"

> emulation and ability to run full-system emulation it provides a
> platform for experimentation without the potential consequences of
> turning your new board into a inanimate brick.
>

Typo: a -> an "into an inanimate brick". You might also be able to
drop inanimate unless you know of a species of animated brick.

> This talk will start with an overview of QEMU and how various
> configurations can be setup. We'll then examine various features
> available that allow us to examine the run time behaviour of code inside
> QEMU as well as discuss some of its limitations. Finally we'll look at
> some experiments that would be hard to do with real hardware and what
> they can tell us about the code we are running.
>
>
> --
> Alex Bennée
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] Week ending 19th July 2018

[Peter Smith]

[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 up the pass and
posting upstream as an RFC.
- Would like to wrap the investigation up by the end of July

On holiday on Friday 20th July and Monday 23rd July, back in the
office on Tuesday 24th.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[no subject]

[Peter Smith]

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 manager has a bug that prevents clang from linking when I
enable clang instrumented profiling (local ref into discarded comdat
group containing counters)
-- Sample based profiling requires building create_llvm_prof from
Google's autofdo repository. Does not build out of the box after it
switched to using git submodules for its dependencies, managed to fix
up makefile to get it built.
-- Tried a sample profiling run but with perf's sampling rate and
clang's running time mean that the number of samples is too small to
give meaningful results.
-- The version of perf on my machine doesn't support incremental
profiling so I can't accumulate data from multiple runs.
-- Inlining before my pass to mark functions for size optimisation
accounts for majority of code size increase.

- Second attempt was integrating clang/llvm profiling into spec
-- Spent way longer than I'd expected working out how to write a
config file that handles sample and instrumentation based profile
runs. Both forms require the profile generated from perf or an
instrumented build to be post-processed before being used as an input
for the next stage. The sample profiling also needs the path to the
training executable which isn't obvious how to do.
-- Got SpecInt running with all the various combinations that I want
to run, haven't had time to do full runs to get results yet
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 6 Jul

[Peter Smith]

[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 trying to inject an extra c-flag into the
right stage of the bootstrap builds. As a consolation I know a little
bit more about the bootstrap builds.
- Just measuring code size the profile guided feedback builds of clang
are roughly 33% larger than standard clang, with cold functions
optimised for size this drops to 25% larger. Still waiting for
performance figures for all runs. It is looking like in its current
formulation the size optimisation might offer most of the benefits of
PGO but with a lower code size impact. It misses the original goal of
keeping the performance of non-PGO optimisation but lower overall
size.
[Misc] Tracked down a LLD static build failure with a recent glibc.
Looks like it won't affect Arm and AArch64 as it is related to X86
relaxed got relocations to ifunc resolvers.

Planned absences
- Holiday Monday 9th July
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Weekly report for week 25

[Peter Smith]

[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 where to put the pass in
both the old and new pass manager.
-- I now understand why the new pass manager is required to get the
most benefits of profile feedback.
-- I now understand a bit better some of the frustrations of the old
pass manager.
-- I can see why the new pass manager isn't quite ready yet.
- Fixed up, I think, -fprofile-instr-generate in the new pass manager.
I didn't realise that were two separate instrumentation methods as
-fprofile-generate is subtly different.

Misc:
- Updated state of sanitizer tests on Arm and AArch64 to enable a PR
to be closed.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 15th June 2018

[Peter Smith]

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 found an
analysis pass that can be adapted to get the information I'm likely to
need.

Other
- Worked on side-project for tiny-code model. Got it passing the
test-suite modulo TLS and one test that was too large for the code
model.
- Have a good idea of what I'll need to do for TLS, will need to start
with assembler support.
- Landed https://reviews.llvm.org/D45959 one step closer to removing
MCSubargetInfo from assembler backend.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 8 June

[Peter Smith]

[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.
- Wrote up some thoughts on Maxim's idea to use pgo to optimize hot
code for time, but cold code for size in an attempt to retain as much
as performance as possible while reducing code-size.

- Some investigation into the --pgo option of lnt. There seem to be
some pre-requisites and some interactions that have made it difficult
to get results:
-- Needs compiler-rt, duh! But it didn't tell me until after I'd
waited for everything to compile.
-- Failed when I enabled perf and pgo, looks to be a configuration
problem where profile-generate and profile-use are set simultaneously.
Probably a cmake problem.

- Some work on side-project to implement the tiny code model
-- Have something working on small examples, much more testing needed.
-- Need to decide what to do about TLS.

Peter
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 1 Jun

[Peter Smith]

[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 .any.
- Completed initial investigation with links to TI/IAR documentation,
binutils discussions.
- Some thoughts on which of the features might be implemented cleanly
enough to be upstreamed.

Pinged llvm-mc subtarget reviews (no response)

Spent some more time investigating a tiny-code model for AArch64 in an
attempt to teach myself more about LLVM.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week ending 24th May

[Peter Smith]

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 code segments may not be 4k aligned. Started
looking into what it would take to implement the tiny code model in
LLVM (supports only small and large at the moment). Built a small
prototype to handle the easiest absolute addressing case, much more
work needed to handle PIC and TLS.

Not a lot of tangible progress, but I think I have learned a bit more
about LLVM.

Planned Absences

- Friday 25th May (holiday).
- Monday 28th May (UK public holiday)
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 18 May

[Peter Smith]

[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 Hikey960 (aarch64).
- Communicated recent additions to LLD in aid of building AOSP, and
extra command line options needed to the Google team.

Landed support for GCC inline assembly constraint S in LLVM.

Some comments on LTO + linker script proposal on llvm-dev mailing list.

Started thinking in more detail about ICF=safe.
- Decided that LLVM was a better place to do this than clang after
attempting to use libtooling.
- There is an existing LLVM pass called merge functions that does what
ICF does but at the LLVM IR level
-- This is off by default, maybe worth looking at as part of LTO and
code-size reductions.
- Started to write a prototype pass that uses
Function::isAddressTaken() although I think that this may give me too
pessimistic a result.

Peter
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] report week ending 11 May

[Peter Smith]

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 needed by
Android such as --keep-unique

[Other]
Reviewed some patches for LLD and MC
Sent a patch upstream for support of the "S" constraint in AArch64
inline assembly.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] report week ending 4th May

[Peter Smith]

[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 improve code-coverage
- Arm LLD 2 stage build-bot including test suite now configured
(thanks Maxim!), will be active upstream soon.
- Started to think about how ICF could be implemented in clang
-- Should be able to make a prototype using clang libtooling


[TCWG-1236]
- Added aarch64 emulation used by Android to LLD
- Tried and failed to get Android to boot when using LLD, narrowed
down the number of modules that could be problematic but I think that
the main symptom is dlopen failing on some modules.
- Found that Google have added LLD support to the Android build system
with a very slightly tweaked version of LLD. This will successfully
boot Android. The main differences are:
-- Google's LLD is a few weeks behind trunk.
-- They have reverted a couple of patches that add undefined symbols
from Shared Objects and allow these to resolve against static
libraries. These patches are correct and I think it is just exposing
some library dependency problems in Android.
-- They are setting -zmax-page-size to 4K on AArch64, LLD defaults to 64K.
---  Android dynamic linker does use 4K page size, but Gold still
seems to use a 64K max page size and I can't see why overaligning
would cause problems.
-- A handful of modules have LLD disabled.

[Plans]
- Investigate differences in trunk and Google Android LLD to see if I
can pinpoint why trunk is failing to boot Android.
- Start to build a prototype with libtooling that records when the
address of a function/member-function/lambda is taken.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 20th April 2018

[Peter Smith]

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 comdat groups.

[TCWG-1375] LLVM should do relaxation per function.
- Worked out what instruction bundling is (From NaCl) and how it
relates to MCFragments.
- Posted revised patch upstream to handle relaxation and fixups, now
diagnoses attempt to change MCSubtargetInfo mid bundle.
- I have a finished a large series of patches to pass the
MCSubtargetInfo through to all the places it needs to be including
writeNops. Will post upstream review next week.

Next week:
- Post revised patches to TCWG-1375 and ping reviews.
- Work through a laundry list of small things to do in LLD.
- Get back to trying to link Android AOSP with LLD.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] week ending 6th April 2018

[Peter Smith]

[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 used as padding.

[Plans]

In office Monday Tuesday only.
Progress [TCWG-1375]

Planned Absences:
- At ACCU conference Wednesday - Friday [Holiday]
- At Euro LLVM following Monday Tuesday
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: Q: reasons for lack of support for C++ in OP-TEE?

[Peter Smith]

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 via my experience with ARM's commercial toolchain, which is
based on a mixture of clang, libc++, libc++abi and libunwind; and
ARM's own C-library and linker. This isn't going to directly map to
the GNU world but I don't think it will be too far off.

The minimal additional support for C++ over C is support for the
language runtime, representing helper functions that the compiler
expects to be defined, regardless of whether these are called in the
source code; for example the various forms of new and delete. These
functions often have a cxa prefix are defined generically by the
Itanium C++ ABI and built upon by platform specific ABIs such the ARM
C++. In the llvm world these are defined by the libc++abi library with
stack unwinding provided by the libunwind library. In general I
wouldn't expect there to be any major difficulty in providing such a
run-time support library for OP-TEE, but I don't know anything at all
about any special restrictions that platform has that might get in the
way. For example I don't know whether OP-TEE requires additional
libraries to be certified?

Any use of C++ static constructors need to be initialised by the
run-time environment, this is typically handled by the C-library
start-up.

Support for the C++ standard library is more complicated, particular
with C++11 and beyond. There are some areas of functionality that are
fairly easy to say this won't work on our platform. For example
std::thread may not work if the underlying platform has no support for
threads. There are some areas such as the containers and algorithms
that will require little additional support beyond the runtime. Some
features such as use of iostream will significantly bloat the code as
this will pull in all the locale support, require static
initialisation of the cin, cout objects.

Perhaps the most difficult decision is whether to support exceptions.
For your own code, choosing not to support exceptions isn't a problem
as both gcc and clang can compile without exception tables, however
many C++ libraries, including the standard library make use of
exceptions, and an uncaught exception results in program termination.
The libc++ library can be compiled without exceptions but this just
means it will terminate the program if an exception would be thrown.

To summarise, if the platform runtime support is limited, there isn't
an easy answer to say C++ is supported, and the answer heavily depends
on the design choices of the platform holder. The OP-TEE developers
would most likely have to define a subset that is supported and
constantly monitor it as toolchains change. They may not consider this
worth the trade-off against the simpler answer of C++ is not
supported.

Hope this is of some use

Peter


On 11 August 2017 at 14:53, Godmar Back  wrote:
> In a recent github thread
>  it
> was suggested that I ask this list about what the exact reasons for the
> lack of C++ support are, and how/if they break down by C++ feature so as to
> gauge a possible investment in remedying this situation at least partially.
>
> In other words, suppose I changed the build process to include libstdc++,
> libgcc, and libgcc_eh (and/or other runtime support commonly linked with
> C++ programs), what features of C++ would work/still fail?  And what
> implementation work would be required to implement the missing features?
> On a related note, are there intrinsic properties of the secure environment
> that may conflict with running C++ code, if any?
>
> Thank you.
>
>  - Godmar
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 24 - 28 July

[Peter Smith]

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 helpers all use
softfp in Clang D35538 and llvm D35904.
- Reviewer pointed out useful script update_llc_test_checks.py that
can simplify writing of llc tests. Well worth checking out

[LLD]
Looks like lld use in Android may be becoming more likely, major
blocking feature is lack of Cortex-A53 erratum fix 843419.
- I've commented on the upstream PR https://bugs.llvm.org/show_bug.cgi?id=33463
- I've written some test cases and have started a prototype implementation

Submitted Linaro Connect presentation proposal for Functional Safety
and Development tools.

Plans:
In priority order:
- range extension thunks
- Cortex-A53 843419
- Compiler-rt
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 10 - 14 July 2017

[Peter Smith]

[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 world semi-hosting test case running on the
latest QEMU running newlib-nano. This was much more difficult than I
expected due to:
- The semihosting startup code of newlib does a semi-hosting call for
top of memory regardless of whether the heap and stack location have
been identified in a linker-script.
- The QEMU semihosting response to top of memory is not helpful
leaving the stack location in an invalid memory location (latest QEMU
requires emulation of a board and not a generic machine)
- QEMU doesn't data-abort when writing to a stack location, so my
return address is helpfully read back as 0x0
Worked around by providing a large enough memory size to QEMU that the
semihosting call for top of memory returns 0, allowing newlib to use
the values in the linker script. Will probably need to spend some time
to write my own startup code that just uses the linker script for the
heap and stack.

Building compiler-rt for v6-m and v7-m has been much more difficult
than I expected as well. I've managed to find a configuration that
works, although it relies on some experimental work in moving
compiler-rt to the runtimes directory.

Plans for next week:
- LLD is top priority
- Get testing for compiler-rt working via qemu on v7-m, the recipe
that works for build does not support testing. I've got to either
extract the cmake magic flags or find a way to plumb through the runes
that make the tests work to the recipe I've got.
- On holiday Thursday, Friday and the following Monday
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 3 - 7 July 2017

[Peter Smith]

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 builtins for ARM are
mandated to have a soft-float interface. I have a tentative patch but
need to test it a bit more first.
- Found out a bit more about the structure of how compiler-rt, and why
it behaves differently when I use the default target and
auto-detection of toolkit as opposed to supplying the target via
options.
-- There is quite a bit of hidden magic and hacks going on in the
default case, some of it I don't think is quite right. For example
Compiler-rt seems to conflate architecture with abi.

Set myself the task of getting compiler-rt tests running on v6-m with
testing on qemu.
- v6-m is the only auto-detected default target that I haven't been
able to reproduce results on.
- A review claimed that tests had been run on qemu, and I'm now trying
to work out how to reproduce this with clang and an arm-none-eabi
sysroot.
-- Not having a lot of luck so far, latest qemu only supports
emulation of 2 cortex-m3 dev-boards and I have yet to make a
standalone program that works [*]
-- I'm not looking forward to plumbing in the options to make the
arm-none-eabi testing work.

[*] I thought I would try semi-hosting first, but it turns out the
default semihosting startup code supplied with arm-none-eabi replaces
my heap and stack locations with a semi-hosting call to get top of
memory which qemu gives an inappropriate result for a dev-board
emulation with non contiguous memory. Would like to see if I can get
this working via a quick experiment to rewrite the start-up code,
although for the full tests I may fall back to retargeting the IO via
an emulated serial port.

Plans:
- First priority is range thunks for lld
- Second priority is getting a v6m test of compiler-rt to check for
any latent problems
- Submit clang patch when I know it works for all the supported platforms
- Look into v7-m support, particularly v7-m + single precision floating point.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 26 - 30 June 2017

[Peter Smith]

== 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.
- Landed the patch that sets _GLOBAL_OFFSET_TABLE_ so that FreeBSD can
link on ARM
- Some other small lld patches
- Investigations into whether an X86 patch might affect CFI generation
for AArch64.

Spent some time banging my head against the compiler-rt build system
to try and see if I can get a cross-compiled build and test run on
Qemu when my compiler-rt target != the default target (i.e. I want to
build clang with ARM and AArch64 targets and cross-build and test all
the ARM compiler-rt targets from that)
- Thwarted by what seems to be inconsistent decisions about
auto-detection of options, what is an architecture, target, sub-target
and abi.
- By passing in all auto-generated options by steam I'm still hitting
some problems with some tests that have an external assembly file.

Found numerous other small inconsistencies that I'll need to write up.

== Plans ==
- Ping the Range Thunks reviews again.
- Compiler-rt
Aim to get to the point where I can write a coherent mail to llvm-dev
explaining what I think is wrong and what I think needs changing.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 19 - 23 June 2017

[Peter Smith]

[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 the full patch-set for review
so that interested people can take it and test.

PR31159 Tracked down why LLD wasn't correctly linking ARM BSD port
- lld only provides a dummy absolute value for _GLOBAL_OFFSET_TABLE_
- llvm-mc doesn't transform .word _GLOBAL_OFFSET_TABLE_ - . into
R_ARM_BASE_PREL like GNU as does, this relocation doesn't use the
value of _GLOBAL_OFFSET_TABLE_ . Instead we get R_ARM_REL32 which
needs _GLOBAL_OFFSET_TABLE_ to be set correctly. PR335511
- Patch accepted upstream will commit today

Misc:
- lld consultancy for Android
- Help to fix build error on clang for ARM colleague
- Query on lld behaviour with respect to .ARM.extab, I think lld
behaviour is within spec, but it may be producing larger files so
probably enough to argue the case for a small patch.
-No time to spend on compiler-rt this week

Plans:
- Post all the range-thunk patches for the people interested in it.
- Commit patches accepted last week
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 05 - 09 June 2017

[Peter Smith]

== 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 ==
Compiler-rt
- Investigated cross-compilation and testing via qemu user mode
emulation. It seems to be possible to do so, although fiddly to set up

Plans for this week:
- LLD long range thunks
- Build up a task list for compiler-rt
- Likely take Friday on holiday
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 29 May - 2 June 2017

[Peter Smith]

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 broken down into
small enough parts for upstream to look at.
- Tracked down https://bugs.llvm.org/show_bug.cgi?id=33136 libc++
failing ~100 tests with std::bad_cast exception when built in release
mode. Was down to global-merge incorrectly merging globals that were
not DSO local. Looks to have been fixed quickly

- llvm-mc
Helped out with D33436 review on how to do interworking branches in assembler
D33492 accepted, will commit next week.

Plans:
- Long range thunks
Continue with slow progress towards upstreaming
- Investigate compiler-rt
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 22 - 26 May 2017

[Peter Smith]

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 assembler.
-- Discovered that gold and lld get the case of a relocation to a
Thumb non STT_FUNC symbol with bit 0 clear wrong. Both linkers attempt
to interwork (they shouldn't as the symbol is not STT_FUNC) but
identify the symbol as ARM due to bit 0 being clear. Luckily these are
corner cases only brought up by hand-written assembler.

- Investigation into https://bugs.llvm.org/show_bug.cgi?id=33136
libc++ failing ~100 tests with std::bad_cast exception when built in
release mode (clean upstream build uses debug).
-- Reduced failing test to std::cout << std::endl; the std::bad_cast
comes from an out of range index into a vector of available locales.
-- Current thought is that this could be a codegen bug as I can only
reproduce in Release (-O3) and not RelWithDebInfo (-O2).

Plans for next week:
- Long range thunks
Make more progress on refactoring. Should get .ARM.exidx patches
upstream, next step to convert long range thunks themselves.
- Work on diagnosing PR33136.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 8 - 12 May 2017

[Peter Smith]

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 the stub table has been relocated
-- Most likely to hit LTO as the object from the LTO plugin will
always be last in the task queue, but the stub table is relocated when
the object that "owns" it is relocated, this is often not the LTO
object.
-- In theory it should be reproducible without LTO and a linker script
-- Workaround for LTO is to create an Output Section just for LTO (The
stub table is always owned by the LTO object)

Plans for next week:
- See if I can reproduce Gold errata problem without LTO
- Report Gold errata problem upstream
- Get back to LLD range thunk work
- Investigate SBREL32 relocation support in LLD, upstream PR32924
- Look at fixing missing Thumb2 modified immediate fixup PR28647
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 1 - 5 May 2017

[Peter Smith]

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 llvm-mc, preventing openssl from being compiled
with clang. Investigated to the point where I know what we should do
next to fix. Next steps will be implementation.

- Looked into a problem reported internally in ARM in gold's erratum
--fix-cortex-a53-843419 on a large program using LTO. The patch is not
being applied correctly leading to segfaults at run-time. This is
likely to take some time to pin down as simple attempts to reproduce
have failed. There is an upstream PR reporting a similar set of
symptoms that looks like it could be the same thing but there is no
useful information or investigation in it:
https://sourceware.org/bugzilla/show_bug.cgi?id=21062
- Looked into lld PR32924, someone asking for RWPI support in lld,
someone at least is keen to get embedded systems support into lld.

Plans:
- Continue looking into above PRs
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 3 - 7 April 2017

[Peter Smith]

== 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 linker-script case. Failing 7 tests of 1007 and it
is a mess so some work to do here.

[TLS] Fixed recent breakage in ARM TLS caused by change in the way
that values are written to the GOT.

== Plans ==
Progress the prototype address allocation far enough to post upstream
for comment, I think that this is likely to take a few iterations to
get right.

== Planned Absences ==
ACCU 2017 27-29 April
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 27-31 March 2017

[Peter Smith]

[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 at breaking down the implementation into smaller
patches that can be sensibly upstreamed

Plans for next week
[TCWG-614]
- Aiming to start upstreaming on Monday, I'm expecting this to be
quite a drawn out process
- Continue testing on ARM Linux

Planned Absences
ACCU conference 2017 27-29 April
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 20th - 24th March

[Peter Smith]

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 how ARM TLS works
- Discovered that upstream have broken TLS global-dynamic for
executables, I have a fix but will need to write a test case.

Plans for next week:
- Euro LLVM Monday, Tuesday
- Continue with TCWG-614
-- Try and link clang (> 30 Mb) to test range thunks on some real programs
-- Aim to get something ready for upstream review by end of week, may
slip to beginning of next week depending on if I find any hard to
debug problems.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 13th Mar -- 17th Mar

[Peter Smith]

[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 functionality and doubtless spending a
lot of time fixing problems. If I'm lucky I may have something that I
can at least in part send upstream for review by the end of the week.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] March 2nd - March 3rd 2017

[Peter Smith]

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.

== Plan ==
At linaro connect all next week

== Planned absences ==
Euro LLVM 27-28 March
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 20 Feb 2017

[Peter Smith]

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
Deal with any last minute Linaro Connect stuff
Continue with Range Extension Thunk work.

== Planned absences ==
Holiday 21st Feb to 1st March
Linaro Connect 6th to 10th March
Euro LLVM 27-28 March
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 13 - 17 February 2017

[Peter Smith]

[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 once
-- Need to insert some thunks at precise points (Mips equivalent of
inline veneers), need to make sure that linkerscript won't reorder the
sections.

[BUD17]
Gave test run of presentation, cut down a lot of the slides as a result

== Plan ==
In office on Monday only, then Holiday to 1st March
- Finalise slides for connect, and work out how to submit them.
- Work out how to do Thunks and linker scripts cleanly

== Planned absences ==
Holiday 21st Feb to 1st March
Linaro Connect 6th to 10th March
Euro LLVM 27-28 March
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 6 - 10 February 2017

[Peter Smith]

== 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 and IFunc PLT at maintainers request

[BUD17]
Researched my forthcoming Connect presentation and wrote about 3/5 of the slides

== Plan ==
Finish Connect presentation early next week as I'll be on holiday the
week before Connect.

Start implementing range extension Thunks.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 23 - 27 January 2017

[Peter Smith]

[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 ARM
- Some upstream patch review in rtdyld and ilp32 support in the assembler
- Presented my personal Linaro objectives to the TCWG leads.

Plans for next week:
- Complete Fosdem presentation, will be leaving early Friday to catch
the Eurostar
- Respond to any post commit review comments on Thunks
- Start work on range extension thunks, the previous commits to use
synthetic sections were pre-requisites to range extension thunks, but
added little new user-visible functionality.

Planned absences:
- Fosdem 2017 will need to leave early on Friday 4th Feb
- Holiday 21st Feb to 1st March
- Linaro Connect 6th to 10th March Euro LLVM 27-28 March (Linaro's
request and cost-code)
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] 16 - 20 January 2017

[Peter Smith]

[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 patch to output mapping symbols in PLT to test local symbol
creation. Not recommending this for inclusion in lld yet, but have
included as a way of testing 2.

Responded to comment on implementation and overall Thunks proposal.

Plans for next week:
Yet more range extension work, hope to get patches 2 and 3 above committed.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 9 - 13 Jan 2017

[Peter Smith]

[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 thunks:
Tidy up and refactor prototype to a point where I can post for
upstream review. This won't be long-branch thunk support but it will
be a significant intermediate step.

Do a draft plan of Connect submission and decide how long I need.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 5-9 December 2016

[Peter Smith]

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 implementation
assumes that .got is immediately followed by .got.plt with no gap. As
lld makes no such guarantees it is easy to break with a trivial
example. Raised PR31332 after investigating the root cause. Spent
quite a bit of time on this, even though it is x86 specific, I wanted
to make sure I hadn't broken it.

Fosdem-2017
- Submitted a llvm-devroom talk on lld to Fosdem (post deadline, but
probably still up for consideration)

Plans for this week:

TCWG-985 PIE on ARM broken
- I have a simple fix that should be simple to upstream

TCWG-919 Thunks to undefined symbols
- I have a downstream patch, but there is risk I'll be asked to refactor

TCWG-911 Eglibc requires a .ARM.attributes section for dlopen
- There is a trivial hack to make this work; just use the first ARM
attributes section and throw away the rest. A proper solution to
support ARM attributes merging will take some time.

PR31332 x86 pic plt sequences broken
- I think I can fix this fairly cheaply which while not directly
relevant to ARM, it does give me another easily accessible target to
test on my desk top and has some community benefits.

Ifuncs
- LLD doesn't support taking the address of ifuncs for any
architecture. I don't think that this is common practice, but it is a
latent problem that it might be good to fix now when ifunc is in my
head.

Planned holidays:
19th December till end of the year, back on Tuesday 3rd January
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 28 Nov to 2 Dec 2016

[Peter Smith]

-- 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 TLS support
Implemented using new GOT structure and successfully upstreamed.

Took up an opportunity to get involved with progressing some AArch64
documentation back at ARM.

-- Plans --
Will post current state of TCWG-829 (ifunc) for feedback on whether
the design is right.
- Write more tests for TCWG-829.
- Work on TCWG-911 eglibc insists on .ARM.attributes section for
dlopen to work and TCWG-919 Thunks to undefined symbols for shared
libraries that call back to the application.
- Spend some time reviewing and updating AArch64 documents back at ARM.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 20 - 25 November 2016

[Peter Smith]

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 were down to me forgetting to
initialise a single bitfield member that I'd added. I can now
confidently say lld can link itself and the other llvm executables
from a clean build.
- Closed out the investigation to concentrate on upstreaming my changes.

[TCWG-829] Ifunc support
- ARM does ifunc differently to all the other Targets (uses .got and
.rel.dyn instead of .got.plt and .rel.plt) I have an old downstream
patch that is essentially if (ARM) do this else do that; which is far
too messy.
- LLD has now been refactored a bit to make its linker generated
sections more flexible. I'm currently trying to rework the design to
use these. Not yet found an approach I'm happy with.

Plans:
Upstreaming priority:
[TCWG-829] Ifunc support
[TCWG-828] Static TLS support
I've got downstream patches for these but I need to extend lld and
rewrite them in a more general way to get them accepted upstream.
[TCWG-919] Thunks to undefined symbols, such as when a Shared Object
is dlopened and calls back to the executable (not yet posted
upstream).
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 14 - 18 November 2016

[Peter Smith]

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 linker on ARM
- Found 6 test failures in libcxxabi and 41 test failures in libcxx
tests. I think these are likely to be all related to TCWG-940
- I cannot build working llvm tools from clean using LLD as the
linker. Everything links but the resulting binaries are unstable,
llvm-tablegen is the first to fall over, giving incorrect results.
Other tools segfault when run on certain inputs.

Much rebasing of downstream patches to account for refactoring.
Refactoring will soon be at a point that I can start rewriting the
downstream patches.

Wrote a python script that can glue together the output of
llvm-objdump, llvm-readobj to give me a better view of the plt, got
and exception tables.

Plans for next week:
- Close out TCWG-940, find out what is wrong that is preventing lld
from linking the llvm-tools.
- Rewrite some of my downstream patches using the refactored framework.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 7-11 November 2016

[Peter Smith]

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 extensions that are dlopened from python, and call back to the
interpreter.
-- I have a downstream fix (TCWG-919), with this fixed the test-suite
can run with lld as the linker through the pip install (SQLAlchemy has
C extensions).
- As thought previously, clang is too big to link without thunks.
- Attempted to make a simple add thunks to all branches to see if I
could get clang to link. Sadly this won't work as lld only permits one
thunk per symbol and this might be out of range of the caller as well.
- Some thoughts and experiments on how much of llvm, compiler-rt,
clang and libc++ can be linked with lld. I'm currently thinking of
altering my lld driver to automatically switch to ld.bfd after a
relocation out of range link error. I want to try and get a lld linked
clang + compiler-rt +libc++ system running.

TCWG-683 lld support for branches to unresolved weak references
- Now upstream

Also:
- A lot of rebasing of downstream patches as some refactoring is going
on to make lld more flexible.
- Some inconclusive investigation into weak reference behaviour in GNU
ld. The ARM and AArch64 ld.bfd linkers will put a dynamic relocation
on a got slot generated by for an unresolved weak reference. The x86
linkers do not, they statically resolve the got slot to 0.
- Some inconclusive investigations into trying to work out what
packages to build to test lld. With the exception of very large
programs ld seems to successfully complete the link for all programs.
Whether it has done so correctly or not is another matter.
-- Currently thinking about whether I can build a BSD make world on a
raspberry pi.

Plans for next week:
- Bring TCWG-901 to a close and work out what to work on next.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 31 Oct -- 04 Nov

[Peter Smith]

-- 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 rewritten after some
upstream refactoring has finished
[TCWG-911] eglibc requires a SHT_ARM_ATTRIBUTES section for dlopen to work
I have a quick hack to work round this on my Chromebook but a full fix
will take some time as lld doesn't understand build attributes right
now.
[TCWG-901] Investigate lld as a system linker
With downstream fixes, using lld as the system linker on a Chromebook I can :
- Build llvm, lld and run the regression tests successfully
- Use lld as the linker in the lnt tests successfully
- Using lld to build the shared objects used by lnt's python C
extensions was less successful. I have some interesting debugging to
do.
-- Plan --
Debug the python extension problems
Respond to upstream review comments
More use of lld as system linker
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain