Hi Richard,
Am I right in understanding that fsf's primary objection to
-mimplicit-it is the resulting unpredictability of the size of the
assembler output for asm blocks? Note that the assmbler output size
is _already_ unpredictable: what about the variable size of Thumb-2
instructions already, and what about use of assembler directives such
as:
#define nops(count) asm( \
".rept " #count "\n\t"
"nop\n\t"
".endr" \
)
Presumably this will defeat GCC's literal pool placement on any
architecture which has literal pools. Indeed, we can come with an
inexhaustible supply of such cases: it's an inevitable result of the
separation between GCC and the assembler.
If for Thumb-2 I assume we already have a heuristic that attempts to
count the number of instructions and predicts the maximum size of the
asm block as n*4 bytes (where n is the instruction count), would it be
feasible to estimate a bound of n*6 bytes if using -mimplicit-it? Or,
do we dump the literal before the asm block to be on the safe side
(and if so, why doesn't this work equally well when using
-mimplicit-it?)
Re the suggestion that inline asm should be "fixed" to include
explicit IT instructions, do you know a practical way to do this?
My concern is that with GCC -marm, the inline asm is passed as-is to
be interpreted non-unified syntax (for backwards compatibility
purposes), whereas with -march>=armv6t2 -mthumb, the asm is passed
(again as-is) to be interpreted in unified syntax. But with explicit
IT blocks, it's impossible to be compatible with both syntaxes if my
understanding is correct: Am I right in thinking that current GNU as
in non-unified syntax mode, and indeed legacy versions of the tools
will treat the IT instructions as an error and barf? Can you think of
a way of working round this?
The best I can think of right now is ghastly preprocessor stuff along
the lines of
#ifdef __thumb__ /* or more correctly __thumb2__ ? */
#define __asm_it_generic(mnemonic,cond) #mnemonic " " #cond "\n\t"
#else
#define __asm_it_generic(mnemonic,cond) /* expands to nothing */
#endif
#define __it(cond) __asm_it_generic(it,cond)
#define __ite(cond) __asm_it_generic(ite,cond)
/* ... */
asm(
__it(eq)
"moveq r0, #0\n\t"
__ite(eq)
"bleq func1\n\t"
"blne func2\n\t"
);
An alternative, if we are happy to "fix" source packages in a way
which breaks building them with older tools, is to pass unified
assembler assembler in unified syntax too. But that would require
some work in the code gen backend for arm if I understand correctly.
But it's a huge task to port everything and some upstream projects may
not accept the changes at all. My concern is that without some
transitional approach, there's simply too much existing code for this
to be viable.
Do you know when unified assmbler support was introduced in fsf?
Cheers
---Dave
As some of you know I came to Linaro from OpenEmbedded project. In OE we cross
compiled by default and to make it more easy we had one nice addon to gcc.
When host includes were used gcc errored out with "CROSS COMPILE BADNESS:
/usr/include used" style message. Patch is present in metadata:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/gcc/gcc-4.4…
no-host-includes.patch
Some time ago replacement was announced on OE mailing list:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/34169
In that thread Khem Raj mentioned -Wno-poison-system-directories which is
available in CSL toolchains.
I would like to get that functionality in our cross compiler as this nicely
shows problems in packages. I got hit by that in eglibc when it fails with:
In file included from ../ports/sysdeps/arm/libc-tls.c:20:0:
../csu/libc-tls.c: In function ‘__libc_setup_tls’:
../csu/libc-tls.c:194:1: error: ‘__ARM_NR_set_tls’ undeclared (first use in
this function)
../csu/libc-tls.c:194:1: note: each undeclared identifier is reported only
once for each function it appears in
just because unistd.h used from host instead from target includes.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
Dnia piątek, 16 lipca 2010 o 11:35:30 Michael Hope napisał(a):
> * Marcin
> * Working on the staging of the GCC build
> * now combining into a build from scratch
> * has stage 1 for most cases
I have all stages working. Eglibc/stage1 needs work on packaging.
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
[ Resent to linaro-toolchain@. ]
Hey
Sorry for the belated post; please find below the minutes from Monday's
Toolchain Working Group meeting and the activity reports from the
preceding week.
You can find the full meeting notes at
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-12
= Monday 12th July 2010 =
== Agenda ==
* Review action items from last meeting
* New linaro-toolchain mailing-list
* Topics for sprint [[Internal/Events/2010-07-PlatformSprint]]
* Release, version numbers, uploading tarballs
* No meetings next week
* Blueprint status
* Initial delivery of Linaro GCC 4.4
* Cross Compiler Packages
== Action Items from this Meeting ==
* Andrew to propose the triplet change to toolchain upstream
* Andrew to send email to Debian ARM on best triplet
* MLH to pickup perl if pbrook doesn't have a patch by Monday evening UTC
* MLH to write up wants as a toolchain developer/tester
* Marcin to check if xdeb incorrectly produces a package findutils-armel
* Loic to push changes on mysql
== Action Items from Previous Meeting ==
* Loic and Andrew to extend wiki page to track progress of the merging
of Ubuntu patches, assignees etc. DONE
* Loic to setup and run a call on merge workflow with bzr DONE
* Matthias to sort autotools issues with new cell-4.4 Linaro patch or
to ask Ulrich for help :-) DONE
* Marcin to fix -gcc symlink (LP #600927) and update-alternatives
installability issue in his public cross-compiler packages DONE
* Yao to update
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuGCCPatches wiki
page for the issue with ADA support and the patches he merged
* Yao to update
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuRegressions
wiki page for the removal of the license patch DONE
* Loic to create a linaro-toolchain-drivers team which can upload
tarballs PARTIAL Group created, tarball upload currently not working
== Minutes ==
* The linaro-toolchain list for toolchain related chatter; please
subscribe!
* Loic called for sprint topics. See
https://wiki.linaro.org/Events/2010-07-PlatformSprint/ToolChainWG
* Meetings have been cancelled for the week of the sprint
* Mentioned the upcoming hardfp port that Debian is investigating
* Port is too large for Linaro itself
* Toolchain should support - best place to support, easiest to
maintain due to doko
* Better choice for Debian as they may get support from Linaro; won't
from CSL 2010 Lite edition
* Noted that there's disagreement on the Debian triplet and position
of the hf marker. Problem is what is correct vs which is the path
of least resistance.
* ACTION Andrew to propose the triplet change to toolchain upstream?
* Noted that the ARM EABI is a family of ABIs that different vendors
take variants from
* ACTION Andrew to send email to Debian ARM on best triplet
* Milestone issue review
* ACTION MLH to try perl if no progress is made by pbrook
* getfem++ can't be reproduced
* vect/* won't fix
* mysql fix is ugly
* pr9771-1.c MLH to continue or send patch otherwise
* neon triggered by march=armv7a which should have occurred with
Lucid GCC
* Can lower priority if a missed optimisation
* MLH wants help on how to best use the packaging system to do what
he's used to such as
* Build exactly what the Ubuntu PPA will end up as
* Build a cross-compiler to try ARM failures on a fast machine
* Do an incremental build
* Do a non-bootstrap build
* Run the compiler under a debugger
* Use the test compiler to build a package
* ACTION MLH to write up wants
* Andrew has a process to build the tarball and will run the
certification process afterwards
* Loic recommended CSL developers to have local hardware
* Blueprints status
* Initial 4.4 release reviewed. Done except Ada patch. Andrew to
edit whiteboard to note
* Update broken Ubuntu patches
* Loic suggests reviewing Ubuntu patches month to month
* Cross compiler (Marcin)
* Tidying up ugly GCC hacks
* Stage 1 is now clean
* ACTION Marcin to check if xdeb incorrectly produces a package
called findutils-armel
* ACTION Loic to push changes to mysql
* Michael will run Wednesday standup call
Activity reports from preceding week:
= Ulrich Weigand =
== GCC ==
* Resolved merge conflicts between cell-branch.diff and gcc444-linaro.diff
(investigated and fixed additional autoconf-related build issue)
* Investigated bug #602287; resolved as won't-fix for Linaro 4.4
* Started investigating bug #602289
== GDB ==
* Completed build and regression test of GDB 7.2 branch on beagle board
* Started working on hardware-breakpoint-support blueprint
== Education ==
* Continued getting familiar with Debian package build process
* Continued getting familiar with Launchpad infrastructure
* Read ARMv7 Architecture Reference Manual
== Infrastructure ==
* Got remote access to Loic's beagle board
* Started process to acquire IGEPv2 board
= Yao Qi =
== Linaro GCC ==
* Ubuntu patch ada-acats.diff on linaro gcc 4.4.
ada-acats.diff and its dependent patches cause some regression
failures. Spent a lot of time on trying different patch sets to
linoar gcc 4.4, but failures do go away. Checked the build log of
ubuntu gcc, and the same failures are there. We decide to leave
this ubuntu patch.
* Merged 19 ubuntu patches to linaro gcc 4.4.
Learn bzr push/merge/branch/commit. Very good version control tool,
and well-collaborated with launchpad.
* Revert license patch in linaro gcc 4.4.
* Merge CS GCC 4.4 patches to CS GCC 4.5.
Choose three patches from Julian's ARM patch list. Two of them are
committed into CS GCC 4.5. The third is sent to CS internal review.
== Misc ==
* Some meetings on linaro status.
= Andrew Stubbs =
== GCC 4.4 ==
* Continued refining the blueprints. We now have the initial 4.4
toolchain delivery blueprint finalised.
* Entered bugs for each of the test regressions in the Ubuntu GCC vs.
FSF GCC.
* Reviewed Yao's launchpad merge request for the Ubuntu GCC patches.
It was all good, so I approved the request and did the merge.
* Reviewed the ARM test failures to make sure they were what we
anticipated they would be.
* Reviewed some of the Ubuntu patches marked "Needs review". Decided
not to use two, rewrote the third and submitted the new patch for
review. Matthias has now accepted it, and applied it to Debian also.
* Found out how to create gnu-style release tarballs and wrote a
Linaro GCC release procedure document for the wiki.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCCReleaseProcess
== GCC 4.5 ==
* Assisted Yao with his patch porting work, and made sure he had
things to do.
= Loic Minier =
* Repaired Beagleboard to boot again
* Cross-built ncurses; did other xdeb tests
* Added color codes and improved structure of
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuRegressions and
https://wiki.linaro.org/WorkingGroups/ToolChain/UbuntuGCCPatches
* Discussed armhf port, started
http://wiki.debian.org/ArmHardFloatPort
* Started sprint planning and associated wiki pages
Bye,
--
Loïc Minier
Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but
maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and
when state changes. If we don't do something like this, we'll lose track
of what's submitted, and what isn't.
Thanks
Andrew
Hi, all,
I notice that linaro-gcc is a native compiler on ARM, when I go through
linaro gcc bugs on launchpad. When we fix bugs, shall we configure gcc
as a native compiler on ARM directly, or configure gcc as a cross
compiler on i386 box? Former needs extra hardware boards, while latter
needs some cross compiling setting. I'd like to know how do you do that?
Hi there. The notes from today's stand up call are available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-14
A copy follows.
One thing I forgot is the upcoming sprint. Please add what you'll be
working on to https://wiki.linaro.org/Internal/Events/2010-07-PlatformSprint/ToolChainWG
- it's great for networking as it helps those interested in similar
areas to track you down.
== Attendees ==
* Andrew Stubbs
* David Rusling
* Michael Hope
* Richard Earnshaw
* Ulrich Weigand
* Yao Qi
* Juilan Brown
== Minutes ==
* Andrew has been working on the release. A power failure last night
interrupted the test suite. MLH noted that Matthias has started his
own build/test process. Andrew will hold off re-running the tests
* Richard has been getting involved in the ABI discussions, which
seem to be winding down from ARM's point of view
* Ulrich has been backporting the testsuite fixes. Next task is
looking at gdb. He has run the test suite on gdb 7.2 and found more
failures than expected.
* Yao is continuing on the CSL 4.4 to 4.5 patch set. The process is
still ongoing. MLH offered to help with any Ubuntu specific packaging
problems partly due to being close in timezones.
The next stand up meeting is on Friday the 16th.
-- Michael
I've expanded the notes on using bzr for toolchain development here:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
It's now much more step-by-step and includes notes on how long
operations take and how big they end up on disk or the network.
-- Michael
Hey
Matthias kicked an armel rebuild of Ubuntu main with a gcc-4.4 + Linaro
diff package. The rebuild copy-archive is visible at:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707
The failed logs are at:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707/+builds?build_t…
@Steve, you had offered help in reviewing the i386/amd64 rebuilds in
the past (and I think Michael Hope was working on these); I would very
much take help in reviewing the armel issues. Is this something the
Foundations team could help with?
I'd like to discuss organizing this review a bit.
* First, we need to make sure we don't review the same build logs
multiple times; the rebuild isn't over and builds are going to
continue showing up; Matthias told me new build logs will show up at
the top, so we only need to note the last package we reviewed.
* We need some place tracking the build logs which we skipped (for
which we didn't file a bug) and/or note last reviewed package; I
propose to note this down in a wiki page.
* For now, we should skip openjdk / java related issues; openjdk needs
some bug fixing before we can consider using it on armel. Such
issues should be documented along other instructions in the
aforementioned wiki page.
* I think we should skip packages which FTBFS on x86. Do we actually
compare build logs before classifying these?
* We should file bugs with some standard tags, perhaps linaro + armel?
* I would like us to develop helpers to analyze build-logs; perhaps
Lucas Nussbaum has something since he manages to analyze the grid5000
rebuild logs decently. Ideally, these tools would also allow
assigning build log reviews to people, leaving comments and such.
Comments welcome!
Cheers,
--
Loïc Minier
