== String routines ==
* Got eglibc testing setup happy at last
- Note that -O3 builds generally seem to give a few more errors
that are probably worth looking at
- -march=armv6 -mthumb hit some non-thumb1 instructions (normally
non-lo registers), again worth looking at
- Cross testing to Qemu user mode often stalls, mostly on nptl
tests that abort/fail when run in system/natively
* Sent new version of eglibc/memchr patch upstream
* Now have working newlib test setup and reference set
- next step is to try adding my memchr there
== Other ==
* Testing a QEmu patch with Peter
* Looking at bug 861296 (difference in mmap layouts)
* Adding a few suggestions to the set of cpu hotplug tests.
* Dealing with the Manchester lab cold.
Short week; back on Monday
Dave
== GDB ==
* Committed hardware watchpoint support for gdbserver to mainline,
including two minor changes resulting from review comments;
backported those fixes to Linaro GDB as well.
* Implemented and tested support for disabling address space
randomization in gdbserver; patch posted for review.
* Investigated support for cross-platform core file generation.
== GCC ==
* Patch review week.
* Posted updated patch for PR 50305.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Arnd Bergmann <arnd(a)arndb.de> wrote on 08/26/2011 04:44:26 PM:
> On Thursday 25 August 2011, Russell King - ARM Linux wrote:
> >
> > Arnd, can you test this to make sure your gdb test case still works,
and
> > Mark, can you test this to make sure it fixes your problem please?
>
> Hi Russell,
>
> The patch in question was not actually from me but from Ulrich Weigand,
> so he's probably the right person to test your patch.
> I'm forwarding it in full to Uli for reference.
Hi Arnd, hi Russell,
sorry for the late reply, I've just returned from vacation today ...
I've not yet run the test, but just from reading through the patch
it seems that this will at least partially re-introduce the problem
my original patch was trying to fix.
The situation here is about GDB performing an "inferior function
call", e.g. via the GDB "call" command. To do so, GDB will:
0. [ Have gotten control of the target process via some ptrace
intercept previously, and then ... ]
1. Save the register state
2. Create a dummy frame on the stack and set up registers (PC, SP,
argument registers, ...) as appropriate for a function call
3. Restart via PTRACE_CONTINUE
[ ... at this point, the target process runs the function until
it returns to a breakpoint instruction and GDB gets control
again via another ptrace intercept ... ]
4. Restore the register state saved in [1.]
5. At some later point, continue the target process [at its
original location] with PTRACE_CONTINUE
The problem now occurs if at point [0.] the target process just
happened to be blocked in a restartable system call. For this
sequence to then work as expected, two things have to happen:
- at point [3.], the kernel must *not* attempt to restart a
system call, even though it thinks we're stopped in a
restartable system call
- at point [5.], the kernel now *must* restart the originally
interrupted system call, even though it thinks we're stopped
at some breakpoint, and not within a system call
My patch achieved both these goals, while it would seem your
patch only solves the first issue, not the second one. In
fact, since any interaction with ptrace will always cause the
TIF_SYS_RESTART flag to be *reset*, and there is no way at all
to *set* it, there doesn't appear to be any way for GDB to
achive that second goal.
[ With my patch, that second goal was implicitly achieved by
the fact that at [1.] GDB would save a register state that
already corresponds to the way things should be for restarting
the system call. When that register set is then restored in [4.],
restart just happens automatically without any further kernel
intervention. ]
One way to fix this might be to make the TIF_SYS_RESTART flag
itself visible to ptrace, so the GDB could save/restore it
along with the rest of the register set; this would be similar
to how that problem is handled on other platforms. However,
there doesn't appear to be an obvious place for the flag in
the ptrace register set ...
Bye,
Ulrich
== String routines ==
* Having got agreement on ignoring the triplet for picking the
routine, I'm just testing a patch,
but fighting a qemu setup.
* Found the binfmt binding for armeb was wrong (runs the le
version); filed bug with fix in
Dave
==GCC==
Combined report for last 2 weeks -
===Progress===
* Committed conditional compares patch to Linaro GCC 4.6
* Looking at modelling auto-inc-decs better .
* Tried patch for PR19599 and that broke bootstrap with a segfault.
Needs some re-engineering.
* Looked at the latest bootstrap failure on trunk. Still narrowing down.
* Some work on some administrative stuff
* Bit of patch review.
* Went for LLVM dev meeting.
* Release week had a few issues and helped dry-run cbuild spawns of
jobs and think I now know how to do that.
=== Plans ===
* finish looking at bootstrap failure.
* Finish auto-inc-dec patch.
* some more patch review.
* Send out LLVM dev meeting report.
Absences.
* 5th October - Out of office.
* 13th -14th October - Internal ARM training.
* 31st Oct - 4th Nov - Linaro Summit Orlando
* 08 Nov - 11 Nov - Tentatively booked
* Dec 19 - 31st Dec - Tentatively booked
(short week: 4 days)
RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||add-omap3-networking || 2011-10-13 || 2011-10-13 || ||
||a15-systemmode-planning || 2011-10-13 || 2011-10-13 || 2011-09-22 ||
||a15-usermode-support || 2011-11-10 || 2011-11-10 || ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-11-10 || ||
Historical Milestones:
||qemu-linaro 2011-04 || 2011-04-21 || 2011-04-21 || 2011-04-21 ||
||qemu-linaro 2011-05 || 2011-05-19 || 2011-05-19 || n/a ||
||close out 1105 blueprints || 2011-05-28 || 2011-05-28 || 2011-05-19 ||
||complete 1111 planning || 2011-05-28 || 2011-05-28 || 2011-05-27 ||
||qemu-linaro-2011-06 || 2011-06-16 || 2011-06-16 || 2011-06-16 ||
||qemu-linaro-2011-07 || 2011-07-21 || 2011-07-21 || 2011-07-21 ||
||qemu-linaro 2011-08 || 2011-08-18 || 2011-08-18 || 2011-08-18 ||
||qemu-linaro 2011-09 || 2011-09-15 || 2011-09-15 || 2011-09-15 ||
== a15-system-mode-planning ==
* now complete: we have generated blueprints/roadmap cards for the TSC
for the various options
== a15-usermode-support ==
* tested udiv/sdiv implementation
* fused mac: rough idea of what needs to be done, need to get all
the fiddly details right
== omap3 upstreaming ==
* rebased and sent pullreq for various outstanding patches
== other ==
* code/design walkthrough for upstream's new memoryregion API
* working on lightning talk for pdsw doughnut session next week
* investigated compile failure building QEMU in thumb mode with debug
enabled (we're trying to use the Thumb framepointer register as a
temporary...)
* meetings: toolchain, standup, 1-2-1
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences (to end of year):
Sep 29-Oct 07, Oct 17, Nov 21, Dec 15-Jan 03: leave
Oct 30-Nov 04: Linaro Connect Q4.11
== This week ==
* Submitted a fix for the performance regression caused by my
arm_comparison_operator patch. Applied upstream after approval
from Ramana (thanks). Will backport to Linaro towards the end
of next week if there are no reported problems.
* Went back to looking at -fsched-pressure. To recap, a colleague
ran SPEC for s390 comparing:
(a) normal -O3 based flags
(b) (a) + -fsched-pressure without my patch
(c) (a) + -fsched-pressure with my patch
(c) got the best geomean result, but there were some individual
tests for which (b) was significantly worse than (a), and for
which (c) only partly closed the gap.
Found one problem. It looks like -fsched-pressure only really
operates on the issue rate and instruction latencies; it doesn't
seem to use the DFA. This seems to be unintentional, and fixing
it showed some nice results.
Also, the -fsched-pressure patch that I wrote at Connect set the
starting pressure based on the set of registers that are both live
on entry to the block _and_ used within the enclosing loop,
This still seems to be a bit too conservative, in that it makes
the scheduler go out of its way to preserve loop invariants,
even if there are too many of them. Experimented with changing
"used" to "defined". This too seemed to be a win.
* Got access to some PowerPC GNU/Linux machines that are suitable
for running SPEC. Set up my account there and got SPEC building.
The idea is to use this to get more cross-target evidence for the
-fsched-pressure submission(s).
* Discussion about the SMS register-scheduling patches after great
feedback from Ayal. While drafting a still-unsent reply justifying
the main part of the patch, I found I was also explaining why another
part of the patch (specifically the prologue/epilogue part) was wrong.
Thought about that a bit today.
* Submitted fix for LP 641126.
== Next week ==
* More SMS register scheduling.
* More -fsched-pressure.
* Hopefully remerge the arm_comparison_operator patch with this week's fix.
Richard
