i
Hi Zied,
As requested before, always add the CS mailing list when interacting
with us. There is a fair amount of people on there that would surely
be interested in this work. I also CC'd the linaro-toolchain group
since some of the content below is related to what they do.
On Mon, 17 Feb 2020 at 10:08, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
> Hi Mike, hi Matthieu
> it works!
>
>
>
> On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> hi Mike, hi Mathieu
> last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level.
> so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7).
> I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here?
I will address your questions one by one:
Q: Do you think it is ok to push it in this status (feature partially
achieved) ?
A: That depends on how advanced things are. If it is stable (i.e it
does something) and can be used as a starting point for other people
to work on, then there is probably value in publishing your work.
Q: is linaro gdb git the correct one?
A: I see from your other email that you've already published your work.
Q: who is the maintainer of this part of gdb?
A: I'm sure the GDB project has documentation and a well defined
process that would identify who you should submit your code to.
Q: I do not have an ARMv8 platform to test. who can support here?
A: No doubt you'd get a lot more interest if you were working on V8.
I suggest purchasing a dragonboard 410c - they are super cheap, well
supported and one of our CS reference platforms. I think we talked
about that before...
>
> during the implementation few technical question raised:
> - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress)
I would assume this "set record btrace" command has an effect on the
current session only. If so I would go for the latter option.
> - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs.
>
I am very confused by this question. Yes, the path
"/sys/bus/event_source/devices/cs_etm/" is guaranteed to be unique but
it is by no means a "default source". Is is simply a directory used
by the perf tools to have more details on the CS specifics for the
running platform. Nowadays it is fair to assume there is one ETM perf
CPU, all enumerated under sysfs. Also keep in mind that processes are
being moved around by the scheduler and as such, a specific source
can't be hard coded.
> for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call?
Configuration of the tracers does indeed need to be considered. At
this time we assume all the tracers in an implementation are similar,
hence using ".../cpu0/mgmt". The information gathered from there is
related to the static configuration of the tracers. Per session
dynamic configuration is collected from the perf tools command line
and communicated to the perf infrastructure for later interpretation
by the decoding code when instantiating a decoder from the openCSD
library. Since the current framework handles only N:1 source/sink
configuration, there can only be one trace session using a sink.
There is currently no way to extract trace session configuration other
than the user space perf tools mechanic.
>
> I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round.
>
> Thanks for your support
> Zied Guermazi
>
>
== Progress ==
* More Morello (updating for new capability encoding)
* Went to the embassy to get my passport
* Read a couple ARM policy refreshers...
== Plan ==
* More Morello
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted v4
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m:
posted updated patch for latent bug on trunk
* GCC upstream validation:
- reported a couple of failures/regressions
- fixed FDPIC build broken on trunk
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* FDPIC GDB
VirtIO Related Work
===================
This is essentially a mind-map of bullet points as we work out what
concrete work items should be implemented by the TCWG Virt hackers
(most likely just me ;-)
Xen for Automotive ([LBI-24])
- Things that need doing
- support for virtio in core (i.e. not just emulated devices)
- support for virtio-iommu and sharing memory between guests
(ivshmemv2?)
- support virtio over ivshmemv2 (would native virtio be supported?)
- support for vhost over shared memory (zero copy device emulation)
- support isolating userspace emulation from hvm (vhost-user)
- Why?
- userspace emulation has performance benefits (exit-less, polling)
- growing number of virtio devices for that guests support
[LBI-24] <https://projects.linaro.org/browse/LBI-24>
Virtualizing Android ([LBI-38])
- Builds on Google's work on Cuttlefish
- New Android Device model using VirtIO (including VirtGPU) \o/!
- Used to run on QEMU, now targeting CrosVM
- Potential interest in using as a HAL layer
- Potential work items
- Better support for ARM in CrosVM
- Is QEMU of interest to members? (emulation & tooling - unlike
CrosVM)
- Is a virtualised Android HAL possible
- Where does Hafnium fit it?
[LBI-38] <https://projects.linaro.org/browse/LBI-38>
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- re-based [a v7 branch]
[VIRT-281] <https://projects.linaro.org/browse/VIRT-281>
[a v7 branch]
<https://github.com/stsquad/qemu/tree/gdbstub/sve-registers-v7>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v2 00/12] testing/next (with build fixes!) Message-Id:
<20200130113223.31046-10-alex.bennee(a)linaro.org>
- posted [PATCH v2 00/19] testing and plugin updates Message-Id:
<20200213225109.13120-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[RFC PATCH 1/2] GitLab CI: avoid calling before_scripts on unintended jobs
Message-Id: <5d0def0e-0943-3345-784d-80f8ccc318b9(a)redhat.com>
[PATCH v1 00/14] tests/vm: Add support for aarch64 VMs
Message-Id: <20200205212920.467-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-02-07 Fri 19:56]
Some problems with hangs, not sure about using threads/file
approach.
Added: <2020-02-06 Thu>
[PATCH 0/2] target/arm: Pass arguments by value for sve FMLA/FCMLA
Message-Id: <20200212025145.24300-1-richard.henderson(a)linaro.org>
Absences
========
- 17t-24th Feb Half Term
- 23rd-27th March BUD20
Current Review Queue
====================
* [PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-1-eric.auger(a)redhat.com>
Added: <2020-02-14 Fri>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
Progress:
* VIRT-241 [QEMU ISA Support for A-profile]
- Looking into implementing some of the easier, smaller architecture features
- Implemented ARMv8.1-VMID16 (16-bit VMID support), which is trivial
for QEMU because it doesn't care much about VMIDs
- Working on ARMv8.1-PMU and ARMv8.4-PMU: it turns out that we already have
most of these extensions, so we just need to finish off some smaller pieces
and fix one or two bugs. Sent out a patchset implementing these.
- Found a bunch of ID-register related bugs in the process, which I have
fixes for
- Implemented the "mandatory from v8.2" ACTLR2 and HACTLR2 registers
* VIRT-65 [QEMU upstream maintainership]
- code review:
- series from Laurent fixing a long-standing issue with handling of
realtime signals in our linux-user code
- imx6 model patches to fix a watchdog device bug and add the
watchdog to our imx6 boards
- final few unreviewed patches in rth's "PAN, ATS1E1, UAO" series
- respin of the json QAPI Sphinx conversion patchset; hopefully the
first half of this is now uncontroversial cleanups that can go in
while the second half gets code reviewed
thanks
-- PMM
o LLVM:
* 10.0.0 RC:
- reported issues upstream
- upload AArch64 binaries
* IR Outliner:
- looking at the branch status
o Misc
* Resurrected an old GNU toolchain prototype w/r to Linux kernel
size reduction.
* Various meetings and discussions.
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted v3, no feedback yet.
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m:
reproduced latent bug on trunk, fix accepted, but I'm still worried by
it not setting all insn attributes correctly.
* GCC upstream validation:
- reported a couple of failures/regressions
- FDPIC build broken on trunk
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* Fix FDPIC build
[ Linux on ARM mini-conference ]
2 days. Some interesting stuff in the future hardware directions talks.
Helped out a bit with ABI history in the toolchain breakout session. Some good
hallway discussion, especially re record-replay on aarch64.
I should make time this weekend to produce a more complete trip report.
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
Posted v7 -- merged!
[VIRT-262 # ARMv8.1-PAN ]
[VIRT-273 # ARMv8.2-ATS1E1 ]
[VIRT-276 # ARMv8.2-UAO ]
Posted v3.
[VIRT-327 # Richard's upstream QEMU work ]
Random patch review.
Updated some aa32 vfp cleanup patches; still need to
re-test and post.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- sent pullreq with some of the pending rST doc conversion work
- finished the work on converting the json QAPI doc comments from
texinfo to rst, and sent out a patchset for this
- code review:
- Cornelia's patches rstifying some s390 docs
- rth's 'Reduce aa64_va_parameter overhead' patch
- a patchset fixing some minor memory leaks in timer devices
- rth's PAN/ATS1E1/UAO patchset
- sent out an arm pullreq
I seem to be currently keeping on top of the code-review queue
with about an afternoon a week spent on review, which is pleasing.
thanks
-- PMM
Progress:
* VIRT-65 [QEMU upstream maintainership]
- more work on rST doc conversion. I've started in on converting the
documentation that we auto-generate from doc comments in json files
(this covers QEMU's QMP protocol and a similar protocol for the
guest-agent).
I now have something that is basically the right shape and correctly
handles 'Command' and 'Object' (with 'Enum' and Alternate' and some
other corner cases still to do). Might be able to send a patchset out
next week with luck. This is I think the last major obstacle to the
rST conversion -- once it's done the rest is just simple-but-tedious
conversion of the remaining document files.
- code review:
+ aspeed 'misc fixes and extensions' patchset
+ "Stop wrongly programming GICR_PENDBASER.PTZ bit" bugfix patch
+ KVM 'adjust virtual time when VM starts/stops' patchset
+ last few unreviewed patches in RTH's VHE patchset respin
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: fixed bugs found when
running the testsuite with the new option activated. Adding warnings
to help understand potential placement changes.
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m: the
patch applies cleanly in the branch, but there are unexpected failures
compared to trunk. Debugging.
* GCC upstream validation:
- reported a couple of failures/regressions
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
== Progress ==
* Updating lldb for the latest Morello architecture changes
* Started running the tests for llvm 10.0.0-rc1
== Plan ==
* Check up on the release
* More Morello
[LLD]
Fixed interworking problem causing Thumb2 kernel not to
Some diagnosis of LLD problem when .ctor and .init_array initialisers are used.
[LLVM-MC]
Upstream reviews for some methods to avoid llvm-mc making symbols
inter-positionable that the code generator has assumed are not.
[Morello]
reviews.
[Other]
Clean up my Jira tickets so that they can be passed on or closed.
This is my last week as a Linaro assignee, will be going back to the
Arm as of next week. I've really enjoyed my time here, thank you for
having me.
Buildbots, busy week that took up most of spare time
- deploying timezone fix to containers
- a couple of weekend patches that broke Arm and AArch64 bisected and
followed up.
- difficult to track down stage-2 failure that was difficult to work
out whether there was a bug in clang, or a code-gen failure in the
backend, also made it harder to bisect. Turned out that it had caused
more easy to bisect failures in other projects and by the time I'd
found the patch it had been fixed.
[ClangBuiltLinux]
LLD's simplified interworking looks to be insufficient for the linux
kernel thumb-2 build. Got agreement with upstream on how to proceed.
Have a patch ready to send upstream.
A small amount of upstream review and bisecting some Linaro CI build
failure for the -fpatchable-functions feature in Clang-10. Looks to
have been resolved.
[VIRT-327 # Richard's upstream QEMU work ]
* tcg patch queue flush, including some VHE prereqs.
* target/hppa patch queue flushing.
* combined the two in-flight avr patch sets, hoping
to move that project to completion.
* patch review.
* target/s390x local variable "leak" fix,
to satisfy a static analyzer.
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
* started rebasing, and addressing the collected
comments from v4 in December.
r~
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: debugging
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m: local
newlib/crt0 patches, patched simulator. Running various validation
configurations
* GCC upstream validation:
- reported a couple of failures/regressions
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
Progress:
* VIRT-65 [QEMU upstream maintainership]
- code review:
+ RTH's bug fix for the PAuth ComputePAC operation
+ patchset adding DMA support for Exynos4210 UARTs
- small patchset documenting the right way to conditionally run
expensive computations that are only needed for trace event output,
and updating a handful of places that used an older (worse) method
- more QEMU documentation conversion to rST; in particular wrote a
Sphinx 'hxtool' extension to handle pulling out fragments of documentation
from QEMU's '.hx' files which define and document command line options
thanks
-- PMM
hiI am progressing in the implementation of the proposal "GDB process record and replay with ARM Coresight" https://lists.linaro.org/pipermail/coresight/2019-July/003021.html
so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7). and I can collect the traces from the perf mmapped aux area.
For parsing them I needed to gather information about the cpu and etm registers. those are available in the events of type PERF_RECORD_AUXTRACE_INFO in the priv section. priv is a kind of "opaque" data structure where the layout is depending on the perf pmu drivers. the implementation of perf tool gives a good example to follow. I needed also to make a wrapper around opencsd library and again perf was offering a good example to follow.
those are good reasons to think about factoring out the functionality of parsing etm traces on linux system in a dedicated library that can be reused by other software, a kind of libcoresightperf.is there any plan or ongoing activities for such a library?
Kind RegardsZied Guermazi
== Progress ==
* More EuroLLVM submissions reviews
* More investigations into Morello bare metal debugging
* Started looking into updating lldb for the latest Morello architecture
changes
* Asked Adhemerval to look into PR44157
== Plan ==
* More Morello
* Keep an eye out for 10.0.0 - rc1
[VIRT-327 # Richard's upstream QEMU work ]
* Implement x86_64-linux-user vsyscall page,
which should keep Peter's pre-merge testing working.
* Another tcg queue pull without the bits that depend
on the vsyscall implementation above.
* Posted v2 of some fixes to -accel option processing.
* Posted v2 of some fixes to target/arm syn data syndrome bits.
* Wrote some test cases for a target/arm pauth sbox fix.
* Investigated a fix for memory layout of -static-pie binaries.
* Random patch review.
r~
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- posted [PATCH v5 00/22] gdbstub refactor and SVE support (+check-tcg
tweaks) Message-Id: <20200114150953.27659-3-alex.bennee(a)linaro.org>
[VIRT-281] <https://projects.linaro.org/browse/VIRT-281>
Upstream Work ([VIRT-109])
==========================
- played with [for-5.0 PATCH 00/11] Support for reverse debugging with
GDB Message-Id:
<157709434917.12933.4351155074716553976.stgit@pasha-Precision-3630-Tower>
- still broken but could be build stability
- while reviewing vsyscall patches ran into qemu-x86_64, buster
/sbin/ldconfig and setup_arg_pages (a mind dump) Message-Id:
<874kwukmxr.fsf(a)linaro.org>
- posted [qemu-web PATCH] documentation: update links to readthedocs
Message-Id: <20200113103550.1133-1-alex.bennee(a)linaro.org>
- we successfully recovered the qemu project name for rtd
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[for-5.0 PATCH 00/11] Support for reverse debugging with GDB
Message-Id: <157709434917.12933.4351155074716553976.stgit@pasha-Precision-3630-Tower>
- CLOSING NOTE [2020-01-13 Mon 18:00]
Introduces some regressions into check-block that need to be fixed
first.
Added: <2020-01-06 Mon>
[PATCH 0/4] migration: Replace gemu_log with qemu_log
Message-Id: <20200114030138.260347-1-jkz(a)google.com>
[PATCH 0/3] linux-user: Implement x86_64 vsyscalls
Message-Id: <20200114210921.11216-4-richard.henderson(a)linaro.org>
Current Review Queue
====================
* [PATCH v2 0/7] configure: Improve PIE and other linkage
Message-Id: <20191218223441.23852-1-richard.henderson(a)linaro.org>
Added: <2020-01-06 Mon>
* {RFC PATCH v3 000/132} Proof of concept for Meson integration
Message-Id: <1576155176-2464-1-git-send-email-pbonzini(a)redhat.com>
Added: <2019-12-12 Thu>
* {PATCH 0/2} tests/acceptance: Add boot vmlinux test
Message-Id: <20191206140012.15517-1-wainersm(a)redhat.com>
Added: <2019-12-06 Fri>
* {RFC PATCH 00/10} hw/avr: Introduce the Arduino board
Message-Id: <20191128015030.27543-1-f4bug(a)amsat.org>
Added: <2019-11-28 Thu>
--
Alex Bennée
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: found problems in the
testsuite when the flag is activated by default
* GCC:
- trying to find a way to add run more validation of -mpure-code on
v6m, to support a request to backport to gcc-9: need to patch newlib's
crt0.S which has some offending sequences
* GCC upstream validation:
- updated scripts to cope with the new git repo and release branches names
* misc:
- infra fixes / troubleshooting / reviews
- fixed problems with automatic bisection of gcc regressions
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
Morello
- Upstream LLD INPUT_SECTION_FLAGS that I implemented downstream.
Quite a few review comments to work through but I think I'm close to
getting something accepted. This will hopefully come in useful for LLD
with embedded systems.
- Wrote down some definitions for the new relocations.
LLD
- landed fix for clang-built-linux-812 linux allyesconfig problem.
- Quite a few upstream LLD and MC reviews
Other
Some research for the clang built linux conference.
== Progress ==
* Out of office for 2 days
* Reviewed EuroLLVM submissions
* A bit more investigation into Morello bare metal debugging
== Plan ==
* PR44157
* Morello bare metal debugging
Hello Linaro team,
I want to use your cross compiler version 6.3.1, but I miss the library
asound and its header (alsa/asoundlib.h)
What do I need to do to fix this ?
Best regards,
Markus Bollinger
Hi Ana,
I don't know anything about the POC myself, but I'm forwarding this so our
QEMU folks can answer.
Cheers,
Diana
---------- Forwarded message ---------
From: Ana Pazos <apazos(a)quicinc.com>
Date: Fri, 10 Jan 2020 at 19:08
Subject: about QEMU support for SVE2 POC
To: diana.picus(a)linaro.org <diana.picus(a)linaro.org>
Cc: Ana Pazos <apazos(a)quicinc.com>
Hello Diana,
We at Qualcomm are trying to find out the POC for QEMU support for SVE2.
We have been using QEMU with SVE support, and need to find out when SVE2
support will be added to QEMU.
I assume Linaro is involved in this task. Do you know the POC?
Thanks for the help!
Ana.
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: sent updated versions with
testcases and doc.
* GCC:
- trying to find a way to add run more validation of -mpure-code on
v6m, to support a request to backport to gcc-9
- proposal to implement LLVM's -arm-assume-misaligned-load-store
rejected by the community
* GCC upstream validation:
- reported/checked a few issues
* misc:
- infra fixes / troubleshooting / reviews
- investigating problems with automatic bisection of gcc regressions
- fixed a long-standing bug in proot
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
[VIRT-327 # Richard's upstream QEMU work ]
* TCG patch queue flush, including phase 1 increase for
number of mmu_idx, on which VHE is dependent.
* Random patch review.
* Capstone update.
* cputlb cleanup in prep for modeling ASIDs.
r~
Morello:
- Implemented INPUT_SECTION_FLAGS in LLD for the Morello toolchain,
now in review. Took most of spare engineering time this week. Will
attempt to upstream once committed in Morello
- Fixed pr44451 upstream, it was already fixed on Morello toolchain.
LLD:
- Made an attempt to fix the LLD linux kernel allyesconfig +
cortex-a53 erratum problem. Was not successful as kernel linker script
is just about as awkward as possible for this problem. I have a good
idea of what to try next. Will aim to fix early next week.
- Quite a few upstream reviews, some pending from last year.
Progress:
* VIRT-65 [QEMU upstream maintainership]
- caught up on the backlog of email that accumulated over the Christmas break
- investigated an intermittent failure of a test case on our BSD hosts
which had reached a failure rate that was seriously impeding the
flow of pull requests. Tracked it down to glib's g_source_ref/unref
not being thread-safe unless the GSource is attached to a GMainContext;
QEMU gets this right for its own use but a set of mock functions used
for a few testcases were not doing so, resulting in occasional races
where the GSource would get destroyed while it was still in use.
- code review:
+ Beata's "inject DABT for load/store insns KVM couldn't emulate" patch
+ a minor cubieboard cleanup patchset
+ i.MX RNGC device emulation patch
- annual review season, some time spent on that
thanks
-- PMM
== Progress ==
* Out of office until Tuesday
* LLVM 9.0.1
- Uploaded final binaries
- Still looking into PR44157 (CFI tests failing on armv7)
* Morello LLDB
- Trying to get bare metal debugging to work
* More ARM Code of Conduct courses etc
== Plan ==
* More Morello and PR44157
* Patch set cleaning up PIE/non-PIE linking
- Add new support for static pie.
* Another revision removing MMU_MODE_SUFFIX.
* Random patch review.
* Planning for Linux on ARM summit in Cambridge in February.
r~
To whom,
I’m seeing a failure on this bot:
--
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-armv7-quick/stage1/bin/llvm-objdump: error: '/home/buildslave/buildslave/clang-cmake-armv7-quick/llvm/llvm/test/tools/llvm-objdump/Inputs/macho-stabs-x86_64': can't find target: : error: unable to get target for 'x86_64---macho', see --version and --triple.
This is just a binary file verifier. Is it the case this bot doesn’t have a mach-o disassembler? And if so, is there a way to disable this test on this bot?
Thanks!
MDT
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- posted [PATCH v4 00/21] gdbstub refactor and SVE support (+check-tcg
tweaks) Message-Id: <20191220120438.16114-1-alex.bennee(a)linaro.org>
[VIRT-281] <https://projects.linaro.org/browse/VIRT-281>
GSoC Mentoring Afermath ([VIRT-348])
- started working on re-base of [TCG code quality tracking]
- bit of a re-factor rethink required
[TCG code quality tracking]
<https://github.com/stsquad/qemu/tree/tcg/tbstats-and-perf-v10>
Upstream Work ([VIRT-109])
==========================
- posted [PULL 00/25] testing and logging updates Message-Id:
<20191219104934.866-1-alex.bennee(a)linaro.org>
- posted [PATCH v1 0/4] semihosting read console support Message-Id:
<20191218180029.6744-1-alex.bennee(a)linaro.org>
- posted [PATCH v2 0/5] semihosting read console support Message-Id:
<20191220132246.6759-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [4/4]
=======================
{PATCH} Semihost SYS_READC implementation (v6)
Message-Id: <20191104204230.12249-1-keithp(a)keithp.com>
- CLOSING NOTE [2019-12-18 Wed 19:39]
Found some issues with deadlocks, fixed and sent my own series
including this patch.
Added: <2019-12-06 Fri>
[PATCH] docker: gtester is no longer used
Message-Id: <1576632611-55032-1-git-send-email-pbonzini(a)redhat.com>
- CLOSING NOTE [2019-12-20 Fri 12:20]
Queued to my tree
Added: <2019-12-18 Wed>
{Qemu-devel} {RFC PATCH} Implement qemu_thread_yield for posix, use it in mttcg to handle EXCP_YIELD
Message-Id: <20190717054655.14104-1-npiggin(a)gmail.com>
- CLOSING NOTE [2019-12-20 Fri 13:11]
Replied.
[PATCH v2 00/28] cputlb: Remove support for MMU_MODE*_SUFFIX
Message-Id: <20191216221158.29572-1-richard.henderson(a)linaro.org>
Absences
========
- Christmas and New Year holidays
Current Review Queue
====================
* [RFC PATCH 00/13] hw/timer/allwinner: Make it reusable
Message-Id: <20191219185127.24388-1-f4bug(a)amsat.org>
Added: <2019-12-19 Thu>
* [PATCH v2 00/14] chardev: Use QEMUChrEvent enum in IOEventHandler typedef
Message-Id: <20191218172009.8868-1-philmd(a)redhat.com>
Added: <2019-12-18 Wed>
* [RFC PATCH v3 000/132] Proof of concept for Meson integration
Message-Id: <1576155176-2464-1-git-send-email-pbonzini(a)redhat.com>
Added: <2019-12-12 Thu>
* {PATCH 0/2} tests/acceptance: Add boot vmlinux test
Message-Id: <20191206140012.15517-1-wainersm(a)redhat.com>
Added: <2019-12-06 Fri>
--
Alex Bennée
Progress (covers two weeks; lost half of last week to the cold that's
been going around the office here):
* VIRT-65 [QEMU upstream maintainership]
- code review
+ RTH's ARMv8.2-UAO patchset
+ RTH's ARMv8.1-PAN patchset
+ had a look at Huawei SDEI patchset; there are some things I don't
like about the approach but I don't currently have any better ideas :-(
Sent an email to the list to see if others have any suggestions.
+ Andrew Jones' patchset to pause the virtual timer when VM is paused
+ Some smmuv3 emulation fixes from Amazon
+ Support for emulating generic timers that run at platform-dependent
frequency (rather than insisting they always run at 62.5MHz)
- release work
+ herded a handful of key bugfixes into rc5; got rc5 and
then the final release out of the door
+ got new s390 box into the set of machines we test QEMU on
(IBM want to turn off the old one at the end of the year)
+ a couple of arm pull requests now 5.0 is open for new contributions
thanks
-- PMM
== Progress ==
* LLVM 9.0.1
- Had trouble with our TK1 machine
- Trying to build rc3 on one of the buildbots
- AArch64 rc3 looks fine
* Morello
- Got lldb-server working on android and it seems to behave fine
- Working on getting the lldb test-suite to work in remote mode with the
morello android simulator
- Running into all sorts of issues with it
== Plan ==
* More of the same
* Out of office: 25-26 December, 1-7 January
One cannot use objcopy --target=efi-app-aarch64 because it appears
that PE/COFF targets are not enabled for aarch64.
Making UEFI & Windows on Snapdragon work harder.
Given that Windows 10 is fully supported on aarch64, I assume it does
have PE/COFF.
Can someone please fix bfd to provide PE targets on aarch64?
--
Regards,
Dimitri.
== Progress ==
* GCC:
- -mpure-code on v6m: committed.
- investigated potential problem with -mno-unaligned-access. It was a
wrong-user-code case, but maybe it would be desirable to implement an
option like llvm's -arm-assume-misaligned-load-store
* BFD Linker:
- GNU-629: non-contiguous memory support: Now able to detect cases
where input sections change size during the linker iterations and when
linker-created stubs would cause overflows.
* GCC upstream validation:
- reported/checked a few issues
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* Holidays: Dec 23rd-Jan 2nd
There’s been an ongoing failure on the clang-cmake-armv8-selfhost
builder for the last day or so; see e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-selfhost/builds/2827/
This list is recorded as the contact information for that builder.
It is apparently crashing in a tblgen backend that I just added:
```
Stack dump:
0. Program arguments:
/home/buildslave/buildslave/clang-cmake-armv7-selfhost/stage1/bin/clang-tblgen
-gen-clang-type-writer -I
/home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/clang/include
-I
/home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/clang/include/clang/AST
-I
/home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/llvm/include
/home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/clang/include/clang/AST/TypeProperties.td
--write-if-changed -o
/home/buildslave/buildslave/clang-cmake-armv7-selfhost/stage1/tools/clang/include/clang/AST/AbstractTypeWriter.inc
Segmentation fault (core dumped)
```
I would like to fix this, but I have no ability to reproduce it, and the
crash information in the log is quite minimal. Is there a way I can get
a shell on a system that can reproduce this, or at the very least get a
line number for where exactly it is crashing?
John.
The Arm GNU Toolchain for the A-profile Architecture
=====================================================
We are pleased to announce the Arm release of the pre-built GNU cross-toolchain
for the A-profile cores: GCC 9.2-2019.12.
Further information about the GNU Arm toolchain and the release packages is
available at Arm Developer site
https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Features
========
* Based on GCC 9.2 (See https://gcc.gnu.org/gcc-9/changes.html for details).
Supported targets
=================
* On Windows(x86_64):
- AArch64 (bare-metal and Linux)
- AArch32 (bare-metal and Linux hard-float)
* On Linux(x86_64):
- AArch64 (bare-metal, Linux and Linux big-endian)
- AArch32 (bare-metal and Linux hard-float)
* On Linux(AArch64)
- AArch64 (bare-metal)
- AArch32 (bare-metal and Linux hard-float)
Changes since Arm release GCC 8.3-2019.03
=========================================
* Additional AArch64 hosted cross-toolchains for AArch64 (bare-metal) and
AArch32 (bare-metal and Linux hard-float)
* Additional Windows hosted cross-toolchains for AArch64 (Linux) and
AArch32 (Linux hard-float)
* Retired Linux(x86_64) toolchain for AArch64 (big-endian bare-metal) and
AArch32 (Linux soft-float)
* Changed toolchain naming convention to match standard target triplet
naming convention, with vendor name being none.
For example, arm-eabi is now arm-none-eabi.
* Fixed the Windows toolchain convention to correctly include mingw-w64
instead of mingw32
Host Requirements
==================
* x86-64 Linux: Ubuntu 16.04 LTS or later, or RHEL 7 or later
* AArch64 Linux: Ubuntu 18.04 LTS or later, or RHEL 8
* x86 Windows: Windows 10
Package Versions
=================
* GCC 9.2.1
* glibc 2.30
* binutils 2.33.1
* GDB 8.3.0
* libexpat 2.2.5
* Linux Kernel v4.20.13
* libgmp 4.3.2
* libisl 0.15
* libmpfr 3.1.6
* libmpc 1.0.3
* libiconv 1.15
Contact Arm
===========
For any questions, please use the Arm Communities forums at:
https://community.arm.com/tools/
Please report any bugs via the Linaro Bugzilla at:
https://bugs.linaro.org/
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
* One day off
o LLVM:
* Couple of failures with the bots
* Machine Outliner:
- Completed testcases
- Validation before re-submission
o Misc
* Various meetings and discussions.