[ACTIVITY] 1st June - 3rd June 2016

[Peter Smith]

== Progress ==

- Holiday Monday/Tuesday
- Finished writing initial support for ARM in lld. Posted upstream as
RFC, no comments so far.
- Implemented, but not tested the static Thumb relocations present in
the arm-linux-gnueabihf-gcc
-- I'd forgotten how much I hated the Thumb 2 instruction encodings.

== Plan ==

- Add tests for Thumb relocations
- Start thinking about how interworking can be implemented in lld
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 6-10 June 2016

[Peter Smith]

== Progress ==
TCWG-607 Initial ARM port for LLD committed upstream. Hello World on
an ARM with an ARM only gcc libc is possible, but not much else.

TCWG-611 Initial Thumb support sent for upstream review. Interworking
is possible at the BLX level but full interworking support
(veneers/thunks) isn't there yet. With this patch it will be possible
to do Hello World with a recent Linaro gcc release.

TCWG-634 llvm-mc putting out R_ARM_THM_PC24 for B.W instead of
R_ARM_THM_PC19. Simple fix now committed upstream.

== Plans ==
Interworking thunks for lld. The existing thunk design is very simple
and only supports one type of thunk per target. For interworking we
need at least two (ARM to Thumb) and (Thumb to ARM).

I think it might be possible to fit a basic implementation just good
enough for ARMv7a to be correct into the existing mechanism, however
just one more thunk type will need a more sophisticated design.

Current thought is to try and implement the basic design to learn a
bit more about the mechanism as it will hopefully not take too long.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 23-27 May 2016

[Peter Smith]

== Progress ==

* LLD Port:
- Got hello world running.
-- Needed a horrible hack to make lld output PLT and GOT entries for
unresolved weak references with default visibility.
- Wrote up in Jira the major areas of work that would be needed for a
useful port.
- Started putting in changes cleanly and writing tests for them.
- Currently hitting a few problems with llvm-mc. I can't generate the
relocations I need to test the linker. The hello world test case used
mainly GCC library objects.
-- Most serious is not emitting R_ARM_BASE_PREL for .word
_GLOBAL_OFFSET_TABLE - (label+8)

== Plan ==
* On holiday Monday and Tuesday
* LLVM MC
See how easy it would be to add missing features to llvm-mc as it
would allow me to write more tests.

* LLD
Complete the test cases for the code I've added.
Take stock of where the lld port is and decide where to go from there.
Options are:
- Send an RFC upstream with what I have. It is not sufficient to run
hello world but should be relatively uncontroversial.
- Cleanly implement the emit the unresolved weak references in the PLT
and GOT so hello world will work out of the box on ARM.
- Keep going until I've got Thumb2 support so I don't have to use ARM
only static libraries to make hello world working.
There is obviously a trade off between having a useful linker and the
patch size getting out of hand.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] 20-24 June 2016

[Peter Smith]

== Progress ==
* TCWG-653 Add interworking thunks to LLD

Investigated and reported upstream bug in existing implementation.
This has been fixed by reverting the change that introduced it. Got
some feedback about whether I would need to strictly follow existing
Thunk implementation.

Implemented an alternative thunk mechanism that should generalise to
supporting range extension and interworking thunks. It is passing the
existing lld regression tests.

== Plans ==

Finish off support for and add tests for ARM/Thumb interwork.
Tidy up and submit upstream.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] for week ending 8th April 2016

[Peter Smith]

== Progress ==
Transition week into Linaro toolchain group from ARM to replace Bernie [*]
- Some ARM handover work done.

- Started looking into https://llvm.org/bugs/show_bug.cgi?id=24350 (TCWG-466
ADRL support)
-- Checked behaviour of ADRL on armasm and GNU as
-- Worked out what I need to do in LLVM to make ADRL work, looks like
nothing hugely complicated but a lot of plumbing through various layers.
- Started reading about AArch64 TLS descriptor implementation. I'm familiar
with the AArch32 traditional model so I need to bridge the gap a bit.

== Plans ==
- Post some review comments on Adhemeval's TLS patch with the hope of
unblocking it.
- Start implementing support for ADRL in the integrated assembler

== Planned Absences ==
Holiday 18th - 22nd April (Attending ACCU conference in Bristol). I think
I've put that in the shared holiday calendar correctly.

[*] Hello to everyone I didn't manage to meet at Linaro Connect. I've been
working in ARM's proprietary compiler team, with much of that time spent on
armlink and the other non-compiler tools.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] Week 16

[Peter Smith]

Progress:
- On holiday all week, at ACCU conference. I've put some highlights at
the end of the message.
- Did some more investigation into TCWG-466 ADRL support in integrated
assembler during breaks.
-- Not looking good, to do this properly bumps up against a lot of
design decisions and restrictions made by the LLVM assembler (designed
as compiler target, not to be user friendly).
-- There are ways it could be implemented with restrictions, but it is
debateable whether it is worth doing at all.
-- On the plus side I've got a much better idea of how the assembler
works and what restrictions exist on each stage of the journey from a
line in the .s file to emission in the object. Will add some comments
to the LDR r0, =expr TCWG as well.
-- On the negative side the :upper16: and :lower16: operators for MOVT
and MOVW don't look to be correct in the presence of addends. Will
need to investigate further to see what the scope of the problem is.

Plan:
- Dump results of TCWG-466 investigation into Jira.
- Take a look at and post a comment on Adhemerval's revised TLS patch,
even if it is just looks fine in the hope of pushing it forward a bit
more.
- Catch up with Renato's scripts and documents for LLVM sub-group.
- Work out what to do with TCWG-466, if the answer is put it down,
find something else to look at.

ACCU Highlights/Report:

Tough stuff in modern C++
A deep dive into some of the newer areas of C++ such as:
- rvalue references and forwarding (universal) references
- How to use SFINAE (mostly std::enable_if) to select algorithms
optimised for particular template instantiations
- Variadic templates. Including all sorts of strange ways to (ab)use
expansion of parameter packs.

C++ WG21 SG14 Gaming and low-latency study group
- A new study group aiming to represent the gaming (primarily), but
also embedded and high frequency trading concerns.
- Motto seemed to be make sure "Don't pay for what you don't use" is enforced.
Most interested in:
-- No exceptions configurations
-- No RTTI
-- More performance out of the STL (see EA STL
https://github.com/electronicarts/EASTL)
-- Add ring buffers and support for unitialised memory, fixed point
numbers, flat-map, standardised simd vector types

Using sentinels
- An example of how using two sentinels in an implementation of
std::partion speeds up the algorithm by saving comparisons. Can speed
up quicksort by a few percent

Constexpr in C++14
- Example showing how you could build a string to enum map, operating
entirely at compile time, and its subsequent negative effects on
compile time!

Concepts Lite
- Concepts missed the C++17 standard, this presentation went into the
current Technical Standard (optional) and how concepts would likely be
implemented in C++(20?)
- Not surprising to see that concepts still missed C++17 as there is
only one implementation and one non-trivial use case (ranges) and
there are still unresolved questions to be answered.

Introduction to Julia
- Really a comparison of Julia to the author's favoured language of common lisp.
- Was impressed at how "lispy" Julia was whilst retaining high performance.
- Liked the mathematical syntax
- Didn't like the python like parts that seemed to be added to try and
get people to migrate from python, but were non "lispy".
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 25 - 29 April 2016

[Peter Smith]

# Progress #

* TCWG-466, ADRL pseudo instruction support in integrated assembler. I
couldn't find a way of putting ADRL into the assembler in a
maintainable way. Managed to work out a pretty close approximation of
ADRL in a macro so I added it to upstream PR. Put the results of the
my investigations into TCWG-466. Agreed with Renato's initial
diagnosis of won't fix.

* TCWG-468, Transform LDR rn, =expr pseudo instruction into MOV. I'm
more hopeful with this one. I've got a prototype that delays the
emission of the constant pool entry to a point where the
transformation can occur.

* Try out the build and push scripts. Had a frustrating day of chasing
down missing dependencies from my Ubuntu 12.04 machine while building
lldb. Should be resolved now.

# Plan #
* UK national holiday on Monday.

* Continue with TCWG-468. I've got a tablegen prototype that treats
LDR rd,= as a real pseudo instruction. Need to finish Thumb and
Thumb2. Next step after that is to do the transformation to MOV.

* Will spend any other time investigating LLD
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: missing gold --be8 support

[Peter Smith]

Hello,

BE8 support in ARMv7 is independent of LTO. In essence the bit-code
file will be code-generated into a big-endian object file. To a linker
this is no different to an big-endian ELF object file from the command
line or a static library.

I think that the bit missing from Gold is the endian reversal code for
instructions, in ARMv7 BE8. If that is implemented then no additional
support is needed for LTO. I would suspect that it would be much
quicker to implement BE8 support in gold than write a ld LTO plugin.

My understanding is that ld.bfd does support BE8 but there isn't a
clang/llvm LTO plugin available for it.

The AARCH64 lld port is little-endian only. I've just started the ARM
port downstream, and have started with little-endian support only. As
of yesterday I have managed to get hello world working in ARM state
only but there is quite a lot to do before lld will become useable in
production.

Peter

It is possible to use LTO without a plugin on any linker. There is an
executable llvm-lto that wraps libLTO.so. As long as you know which of
your input objects are bitcode, and the references that your
non-bitcode objects make to the bitcode objects you can simulate the
LTO linker plugin. This isn't friendly enough to give to customers but
if all LTO is being used for is internal benchmarking it can be good
enough.

Not that it is of much use to you, but ARM's proprietary toolchain
supports LTO for bare-metal via clang, including v7a, and we (ARM)
haven't seen any problems with code-generation due to LTO in the tests
that we run.


On 24 May 2016 at 17:27, Renato Golin  wrote:
> On 24 May 2016 at 17:05, Jim Wilson  wrote:
>> Cisco is trying to use clang/lto on big-endian arm, which apparently
>> requires gold, and gold does not support the --be8 option which is
>> required for ARMv7 big-endian support.  Does anyone here care about
>> this?
>
> Hi Jim,
>
> Using Clang with LTO on ARMv7 is already risky business, since not
> many people are testing it (we're not), but running it on BE8 is Terra
> Incognita. We'd have to care about many other things first to get
> there...
>
> For one, validate BE8, which probably needs QEMU, but we don't have
> x86_64 hardware where QEMU would be remotely useful. Another, make a
> decision between implementing LTO in BFD, Gold, or LLD and stick to
> it, as well as extend to support BE8.
>
> I don't know much about the BFD vs Gold, but I remember that ARM folks
> weren't happy about relying on Gold for AArch64. Also, LLD has
> reasonable AArch64 support (mostly only TLS missing), and ARM can
> (maybe) link (but not run) "hello world" on Peter's development tree,
> but otherwise doesn't exist.
>
> The best decision, IMHO, would be to have it working on at least one
> GNU linker and one LLVM linker. The order in which they come doesn't
> matter.
>
> But that's a year's plan, at least, unless we pick someone to focus
> solely on that, in which case it could be a few months' plan.
>
> cheers,
> --renato
> ___
> 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] 16 - 20 May 2016

[Peter Smith]

=== Progress ===
TCWG-591 MOVW incorrectly allowed on ARM v5 committed upstream
TCWG-595 LLD port to ARM architecture
I am getting close to being able to run hello world built with lld.
I'm converging 1 bug at a time.
- The PLT handling code is working and the loader can execute the
image and starts the .init function.
- Currently failing in the weak call to __gmon_start__. At present lld
is removing undefined weak references from executables instead of
passing them on for the dynamic loader to resolve. This may not be
necessary on x86 but it is necessary on ARM.
-- Just finished a hack that should make this work, although it will
need some tidying up.

=== Plan ===
Get hello world working and then take stock of what I've learned and
come up with a plan in Jira for what needs to be done.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 02 - 06 May 2016

[Peter Smith]

* Monday off [2/10]

# Progress #

* TCWG-468, ldr rt, =immediate
   Have a feature complete implementation. Passes existing regression tests.
   Still need to add more tests for new functionality and see if
implementation can be tidied up a bit

* Setting up a local chromebook to run the regression-tests. Should
now be able to run test suite on ARM relatively easily.

# Plan #

* Complete TCWG-468 and send upstream for review.
* Pick something else up.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 11 - 15 April 2016

[Peter Smith]

Progress:
- Read up on AARCH64 TLS and LLD code base
- Commented on upstream patch in hope of getting approval from the code-owners
- TCWG-466 Implement ADRL pseudo in LLVM assembler
-- Slow progress as the pseudo instruction does not fit well into the
existing architecture
-- On the positive side I have learned quite a bit about how the LLVM
assembler works
-- Will make a decision next week whether it is worth actively
pursuing TCWG-466. Supporting ADRL is not high priority and whatever
fix I come up with may be difficult to get accepted upstream. I'd
still like to keep trying, at least as a background task, but I think
that there is higher priority work that can be done instead.

Next Week:
On holiday (hopefully added correctly to Linaro google calendar). I'll
be at the ACCU conference.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 18-22 July 2016

[Peter Smith]

== Progress ==

TCWG-680 Some analysis on what non-compiler support would be required
for an llvm based EBC (UEFI) toolchain.

TCWG-612 ARM TLS support in LLD: Initial support and tests for
standard model upstreamed. There is still some work to be done for
corner cases where LLD's relaxations will cause assertion failures.
Static linking also needs some work as the TLS module index needs to
be written into the GOT without a dynamic relocation. I have a
prototype fix that needs cleaning up and tests written.

Did some experiments with static linking and TLS to work out what I'll
need to look at next. Discovered GNU ifunc support when static linking
is not working.

Did some thinking about what would be needed to support C++ exceptions
in LLD for ARM. This is probably the next major chunk of work as
supporting exceptions is needed when static linking against the C
library startup code.

== Plans ==
Plans for next 4 weeks:

On Sabbatical back on the 22nd August. Will probably have limited
access to email if there is anything urgent.

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

[ACTIVITY] 4-8 July 2016

[Peter Smith]

== Progress ==


TCWG-653 ARM/Thumb interworking veneers

Committed upstream after several review rounds and at least one set of
build bot failures in systems/compilers we don't have set up.

TCWG-612 ARM TLS support in LLD

Have an implementation and most of the tests. Should be ok to upstream
next week.
Found that llvm-mc doesn't implement .word sym(tlsldo). Have a simple
fix that I'll need to upstream before I can test local-dynamic.

== Plan ==
11 - 15th July TCWG Sprint

== Absences ==
25th July - 20th August Sabbatical
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[ACTIVITY] 27 June - 1 July 2016

[Peter Smith]

== Progress ==

TCWG-653 ARM/Thumb interworking veneers

Have completed an implementation, now in upstream review. Had initial
set of comments and posted an update. Likely to take several
iterations before commit

TCWG-612 ARM TLS support in LLD

Made a start. Looks to be more straightforward the interworking
thunks, should just be grunt-work to get done.

Updated lld slides on llvm sprint presentation.

== Plan ==
TCWG-653 and TCWG-612.
___
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] 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] 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] 30-2 September 2016

[Peter Smith]

== Activity ==

[TCWG-610] Sent .ARM.exidx for upstream review.
Will need to rework and simplify bit to make more specific to ARM. In
summary abandon pretence of SHF_LINK_ORDER in general and concentrate
on supporting its one known use case in .ARM.exidx sections.

Made a couple of drafts of forthcoming LLVM Cauldron presentation
- Presented locally
- Modified slides after overrunning time

== Plans ==
[TCGWG-610] Rework and resend for review
llvm-cauldron on Thursday
Intending to take Friday as holiday to take advantage of visiting
parents whilst up North.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] 5 - 8 Sept 2016

[Peter Smith]

== Progress ==

- Still trying to get support for .ARM.exidx into upstream LLD, looks
like more changes are needed by the owners, but I think I should be
able to get this by the next report.

- LLVM Cauldron on Thursday. Trip report sent separately

- Holiday on Friday

== Next week ==

Planned:
- ARM Exceptions support in lld
- Further lld porting work
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] 19-23 September 2016

[Peter Smith]

== Activity ==

Exceptions.

Another attempt at ARM exceptions support. I did get some more fine
grained comments back which have been addressed, but no approval to
commit yet.

Some follow up over whether ld -r support for merging output sections
is necessary, answer seems to be yes as kernel modules depend on it.

I've volunteered to post a simpler patch without ld -r support as this
is a very niche use case. Not had any feedback yet so will just post
it next week.

TLS
Fixed TLS support in lld so that it does not attempt to follow lld's
generic relaxation model, which can't be implemented in ARM. Still
some work to do for static linking.

== Next Week ==
Out of office at Linaro Connect in Las Vegas

== Planned Absences ==
Holiday 10th to 14th October
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

[Activity] 12 - 16 September

[Peter Smith]

== Activity ==
Exceptions support in LLD; 3rd try at an implementation that will be
accepted upstream. Now implementation complete and passing my existing
tests but needs some more cases checked.

Helped track down an intermittent build bot failure to an ld stub
generation problem

Some upstream patch review

== Next Week ==
Add more test cases and send exceptions support upstream

Use some of the Cauldron slides to replace existing LLD ones in the
Connect presentation.

== Planned Absences ==
Holiday 10th - 14th October
___
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] 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] 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

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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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 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] 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] 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

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

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] 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 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

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

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