Hi,
* fixed a bug where libunwind could segfault when unwinding through a
shared library using the ARM specific unwind tables
* discussed the libuwind internals with Uli (thanks!) and concluded
that the best way to implement remote unwinding for ARM is to integrate
the support for the ARM.exidx* directly into the DWARF code
* otherwise the user visible remote API needs to be extended for ARM
only which seems to be a bad idea
* requires to re-implement the existent ARM code (both local and remote)
* will also benefit from libunwind's (dwarf) caching mechanism
* started to re-implement the ARM code
Regards
Ken
- Continue Spec2006 analysis:
Looking into SMS opportunities in SPEC2006/462.libquantum.
- Looking into recent bootstrap failure with SMS flags on ARM -- it
seems to be related to do-loop optimization.
Hello Michael,
We do have more and more instances of the following issues turning up in
the kernel requiring toolchain assistance to solve the problem properly.
Could you or someone from your team follow this up please?
---------- Forwarded message ----------
Date: Tue, 1 Feb 2011 12:16:48 +0000
From: Dave Martin <dave.martin(a)linaro.org>
To: binutils(a)sourceware.org
Cc: linaro-toolchain <linaro-toolchain(a)lists.linaro.org>
Subject: Generating ancilliary sections with gas
Hi all,
Every now and again I come across a situation where it would be
really useful to be able to query the assembler state during
assembly: for example, to query and do something based on the
current section name. This makes it possible to write generic
macros to do certain things which otherwise require manual
maintenance, or complex and fragile external preprocessing.
Below, I give a real-world example of the problem, and sketch out
a possible solution.
What do people think of this approach? Does anyone have any better
ideas on how to solve this?
Cheers
---Dave
EXAMPLE
An example is the generation of custom ancilliary sections.
Suppose you want to write macros which record fixup information.
Currently, there's no way to put each fixup in an appropriately
named section automatically within gas. Tellingly, gas has had
to grow the ability to do this internally at least for ARM,
since the exception handling information in .ARM.ex{idx,tab}*
must go in sections with names based on the associated section
name. However, this ancillary section generation support is
neither flexible nor exposed to the user.
By putting fixups in sections whose names are based on the name
of the section they refer to, selective link-time discard of the
fixups (and hence the code referenced by the fixups) will work;
otherwise it doesn't. This would help avoid a situation where we
have to keep dead code in the kernel because custom fixups are
applied to it: at run-time, the code gets fixed up, then is
thrown away. The fixups can't be selectively discarded because
they are all in the same section: we seem have to no good
way to separate them out into separate sections appropriately.
For context, see:
http://www.spinics.net/lists/arm-kernel/msg112268.html
PROPOSAL
To solve the problem of generating custom ancillary sections
during assembly, here's a simple proposal: introducing a new kind of
macro argument can make aspects of the assembler state available to
macros in a flexible way, with only minimal implementation
required.
Basically, the macro qualifier field could be used to identify
arguments which are filled in by the assembler with information
about the assembly state, rather than being filled in by the
invoker of the macro: e.g.:
.macro mymacro name:req, flags, secname:current_section
/* ... */
.pushsection "\secname\name", "\flags"
/* ... */
.popsection
.endm
/* ... */
mymacro .ancillary, "a"
During expansion, \name and \flags are expanded as normal.
But \secname is substituted instead with the current section name,
so the macro expansion would look like this:
/* ... */
.pushsection ".text.ancillary", "a"
/* ... */
.popsection
Without the special :current_section argument, it doesn't appear
possible to implement a macro such as mymacro in a generic way.
This surely isn't the only way to achieve the goal, and it's
probably not the best way, but it does have some desirable
features.
Principally, while a new pseudo-op(s) could have been defined to
append text to the current section name, etc., allowing the current
section name to be appear as a macro parameter avoids prejudicing
the way the text is used. So there should never be a need to
introduce additional pseudo-ops to do things with the current
section name: with this patch, the user can always implement their
own macro to do the desired thing. This gets the desired
behaviour and maximum flexibility, while keeping the implementation
in gas very simple.
Also, using the macro expansion system in this way allows the
caller a free choice of macro parameter names, and so pretty much
guarantees that existing code won't get broken by the change.
Because my hack is currently simplistic, it has shortcomings: in
particular, it's not desirable to parse an argument from the
invocation line at all to fill a :current_section argument.
Currently, an argument is read in if present, but its value is
ignored and the current section name pasted in at macro expansion
time instead. However, that should be straightforward to fix with
a bit more code.
Of course, there's no reason only to expose the current section name
in this way. Any aspect of the the assembler state (current
subsection, current section flags, current instruction set, current
macro mode, etc.) could be made available in a similar way.
USAGE EXAMPLE AND PATCH
Note that the specific implementation described here is intended
to be illustrative, rather than complete or final.
binutils$ cat <<EOF >tst.s
.macro push_ancillary_section name:req, flags, csec:current_section
.pushsection "\name\csec", "\flags"
.endm
.macro register_fixup
_register_fixup 100\@
.endm
.macro _register_fixup label:req
\label :
push_ancillary_section .fixup, "a"
.long \label\(b)
.popsection
.endm
.long 1
register_fixup
.long 2
.data
.long 3
register_fixup
.long 4
.long 5
register_fixup
.long 6
EOF
binutils$ gas/as-new -ahlms -o tst.o tst.s
ARM GAS tst.s page 1
1 .macro push_ancillary_section name:req, flags, csec:current_section
2 .pushsection "\name\csec", "\flags"
3 .endm
4
5 .macro register_fixup
6 _register_fixup 100\@
7 .endm
8
9 .macro _register_fixup label:req
10 \label :
11 push_ancillary_section .fixup, "a"
12 .long \label\(b)
13 .popsection
14 .endm
15
16 0000 01000000 .long 1
17 register_fixup
17 > _register_fixup 1000
17 >> 1000:
17 >> push_ancillary_section .fixup,"a"
17 >>> .pushsection ".fixup.text","a"
17 0000 04000000 >> .long 1000b
17 >> .popsection
18 0004 02000000 .long 2
19
20 .data
21 0000 03000000 .long 3
22 register_fixup
22 > _register_fixup 1003
22 >> 1003:
22 >> push_ancillary_section .fixup,"a"
22 >>> .pushsection ".fixup.data","a"
22 0000 04000000 >> .long 1003b
22 >> .popsection
23 0004 04000000 .long 4
24 0008 05000000 .long 5
25 register_fixup
25 > _register_fixup 1006
25 >> 1006:
25 >> push_ancillary_section .fixup,"a"
25 >>> .pushsection ".fixup.data","a"
25 0004 0C000000 >> .long 1006b
25 >> .popsection
26 000c 06000000 .long 6
ARM GAS tst.s page 2
NO DEFINED SYMBOLS
NO UNDEFINED SYMBOLS
binutils$ arm-linux-gnueabi-objdump -rs tst.o
tst.o: file format elf32-littlearm
RELOCATION RECORDS FOR [.fixup.text]:
OFFSET TYPE VALUE
00000000 R_ARM_ABS32 .text
RELOCATION RECORDS FOR [.fixup.data]:
OFFSET TYPE VALUE
00000000 R_ARM_ABS32 .data
00000004 R_ARM_ABS32 .data
Contents of section .text:
0000 01000000 02000000 ........
Contents of section .data:
0000 03000000 04000000 05000000 06000000 ................
Contents of section .fixup.text:
0000 04000000 ....
Contents of section .fixup.data:
0000 04000000 0c000000 ........
Contents of section .ARM.attributes:
0000 41150000 00616561 62690001 0b000000 A....aeabi......
0010 08010901 2c01 ....,.
diff --git a/gas/macro.c b/gas/macro.c
index e392883..95c4de1 100644
--- a/gas/macro.c
+++ b/gas/macro.c
@@ -516,6 +516,8 @@ do_formals (macro_entry *macro, int idx, sb *in)
formal->type = FORMAL_REQUIRED;
else if (strcmp (qual.ptr, "vararg") == 0)
formal->type = FORMAL_VARARG;
+ else if (strcmp (qual.ptr, "current_section") == 0)
+ formal->type = FORMAL_CURRENT_SECTION;
else
as_bad_where (macro->file,
macro->line,
@@ -540,6 +542,15 @@ do_formals (macro_entry *macro, int idx, sb *in)
name,
macro->name);
}
+ else if (formal->type == FORMAL_CURRENT_SECTION)
+ {
+ sb_reset (&formal->def);
+ as_warn_where (macro->file,
+ macro->line,
+ _("Pointless default value for current_section parameter `%s' in macro `%s'"),
+ name,
+ macro->name);
+ }
}
/* Add to macro's hash table. */
@@ -734,7 +745,11 @@ sub_actual (int start, sb *in, sb *t, struct hash_control *formal_hash,
ptr = (formal_entry *) hash_find (formal_hash, sb_terminate (t));
if (ptr)
{
- if (ptr->actual.len)
+ if (ptr->type == FORMAL_CURRENT_SECTION)
+ {
+ sb_add_string (out, segment_name (now_seg));
+ }
+ else if (ptr->actual.len)
{
sb_add_sb (out, &ptr->actual);
}
diff --git a/gas/macro.h b/gas/macro.h
index edc1b6b..ea6cabb 100644
--- a/gas/macro.h
+++ b/gas/macro.h
@@ -38,7 +38,8 @@ enum formal_type
{
FORMAL_OPTIONAL,
FORMAL_REQUIRED,
- FORMAL_VARARG
+ FORMAL_VARARG,
+ FORMAL_CURRENT_SECTION,
};
/* Describe the formal arguments to a macro. */
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
RAG:
Red:
Amber: OMAP3 patch upstreaming is slower progress than hoped
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||qemu-linaro-2011-07 || 2011-07-21 || 2011-07-21 || ||
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 ||
== upstream-omap3-patches ==
* split and did most of the cleanup of 'overhaul onenand support' patch
* updated the omap gpio qdev patchset in response to review comments,
just about ready to send v2
* this is going more slowly than I had anticipated
== other ==
* patch review, etc
* confirmed attendance at KVM Forum and LinuxCon NA
Current qemu patch status is tracked here:
https://wiki.linaro.org/PeterMaydell/QemuPatchStatus
Absences:
1-5 August: Linaro sprint 1111
15-19 August: KVM Forum and LinuxCon NA, Vancouver
Hi
Linaro backport PPA [1] got updated to latest versions of armel cross
toolchains -- oneiric packages were used as a base.
What got changed:
- gcc 4.4 was updated to 4.4.6-3ubuntu1
- gcc 4.5 was updated to 4.5.3-1ubuntu2
- binutils was updated to 2.21.52.20110606-1ubuntu1
- eglibc was updated to 2.13-6ubuntu2
- gcc 4.6 was provided as 4.6.0-14ubuntu1 in Maverick, Natty
- gcc-defaults-armel-cross was updated to 1.6 in Maverick, Natty (uses
gcc-4.6 as default)
There is no gcc-4.6 for Lucid currently as it requires newer versions of
few libraries (mpfr, mpc) and one of rule of this PPA is "do not update
packages which may affect other packages".
Please test them and report any bugs found.
1. https://launchpad.net/~linaro-maintainers/+archive/toolchain/
== GDB ==
* Posted patch to fix shared library remote test problems (#804387).
* Started reviewing Yao's latest Thumb-2 displaced stepping patch.
== GCC ==
* Reviewed and approved Richard's mainline reload patch to fix
#803232 (ICE on code that uses vld4q_s16() NEON intrinsic).
* Followed up on gcc-patches to address concerns about Julian's
unaligned access patch.
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
== This week ==
* Looked at why the fix for #721531 wasn't working on the Linaro branches.
Wrote follow-up patches for both. Fix now committed to 4.5 and 4.6.
* Looked at #736007. Submitted and committed patch upstream.
* Looked at some "odd" ivopts behaviour. It turned out that this was
working mostly as expected. I'm still wondering about a couple of tweaks.
* Looked briefly at a miscompilation of vector code that turned out to
occur during predictive commoning. I haven't yet checked whether the bug
is there or not. For the time being, I'm using -fno-predictive-commoning
so that I can get on with other stuff.
* Looked at why the auto-inc-dec stuff wasn't as effective with current
mainline. It turns out that the new misaligned load/store patterns
are using overly weak predicates, so it appears to the RTL optimisers
as though we support reg+offset addresses.
* Reviewed the shrink-wrap patch.
* More auto inc/dec.
== Next week ==
* Backport the fix for #736007.
* More loop stuff.
Richard
Achieved:
* HW in place. Borrowed another Panda board that I can use permanently.
* linaro-media-create installed and working. Flashed sd-card with 11.05 for
Panda board.
* Played around with the Panda board. Networking is on the way.
I can ssh to my computer from the Panda but not the other way around yet.
Issues:
* Serial log from Panda board not working yet. Mike suggested I try a
straight-through cable instead in of a null-modem cable. (Have not done this
yet.)
* The ST-E firewall (proxy) is causing me some headache. But at least
everyone here is facing the same issues, so there are people to talk to
about the problems.
Good to know:
* I will be on vacation 18th July - 15 August
Best Regards
Åsa
Hi,
- continued working on prevention of over-widening in vectorization -
finalizing the patch
- improvement of vectorizer peeling heuristic - merged to gcc-linaro-4.6
- vectorization of widen-mult with over-promoted operands - proposed
for merge to gcc-linaro-4.6
- fixed PR 49610
- patch reviews
I am on vacation tomorrow and on Sunday.
Ira
Hello,
I'm interested in LLVM correct performance on ARM hardware and it looks
like LLVM is kind of sensitive to what GCC version is used for its
compilation. I tested LLVM 2.9 as a reference point and LLVM
HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu
versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro
2011.05 and 4.6.1 Linaro 2011.06. Please see
http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/
It looks like LLVM HEAD does have
about 28 regressions in comparison with LLVM 2.9. But also Linaro's GCC
4.6.1s do have some regressions in comparison with older GCC 4.3.4 and
4.4.1. Also what is really interesting with LLVM is how much tests fails
when compiled with -O2 or default -O3 compilation option. I don't know
if the culprit here is LLVM code or just GCC
miscompilation/overoptimization?
Is there any testing I may do to help you fix those regressions?
Thanks,
Karel
