We decided long ago to disable Thumb/Thumb2 in the Fedora ARM world.
Due to the RPM macros being out of date, we were not actually disabling
the default provided by RPM itself, which views armv7hl as having
Thumb2. I have released an updated redhat-rpm-config package which
overrides this. It is now a pending update for Fedora 15 primary.
This is now manually tagged (well, copied really) into stage4 and should
be picked up on any of the active builders.
Due to the way that ARM interworking is implemented, we are able to
drop-in replace libraries and other code with non-Thumb versions and
nothing should break. Therefore, there is no panic. But this should help
fix the build problems we've been having with some packages. When we do
the mass rebuild in Koji, it will correctly have Thumb turned off.
 And therefore there is no need for this thread to turn into a
bikeshedding exercise around comparing Thumb vs. no-Thumb :)
The armv7 distro bootstrap have run into a number of packages failing to
compile in Thumb mode (default enabled in rpmrc) failing on ARM assembly
parts with conditional branch instructions. In thumb mode one apparently
need to use the IT instruction to hint to the CPU about the conditions
of following instructions in addition to have the conditions on the
instructions themselves. While investing these I saw rumors about GCC
eventually adding an automatic handling of these adding IT instructions
as needed, and even projects being very reluctant about touching any of
this until GCC have made up it's mind, and finally in an upstream bug
report on pulseaudio there is a reference to the -mimplicit-it=thumb GAS
option doing exacly this.
Is there any drawbacks from enabling implicit IT instruction generation
letting GAS automatically deal with this as required by Thumb mode? If
not, should we add this to rpmrc?
from what I can understand it should be quite safe. And I am even of the
opinion that GAS is way better suited at adding these instructions than
the average programmer as it carries redundant information which need to
match the conditions of the instructions following after.
Would even argue that it's a design error in Thumb assembly language to
even require the instruction to be declared not have the instruction
implicitly generated by default based on the conditional instructions it
covers. Programmers are humans. But that is a separate topic.
Right. I wrote that then realized I was thinking rpmbuild not mock. I blame it on being pulled in other directions while working on the weekend ;) So anyway, we should fix this in the am by getting the stage4 macros changed accordingly and rebuilding the mock buildroot. Can do an updated set of images afterwards.
I'll be online from 10EDT.
Sent from my phone - message formatted and/or shortened accordingly.
From: Dennis Gilmore [dennis(a)ausil.us]
Received: Sunday, 18 Sep 2011, 16:55
Subject: Re: [fedora-arm] Thumb mode IT instruction requirements and -mimplicit-it assembler flag
On Sunday, September 18, 2011 01:10:46 PM Jon Masters wrote:
> On Sun, 2011-09-18 at 16:21 +0200, Henrik Nordström wrote:
> > There is no redhat-rpm-config package in the armv7 repositories, so yum
> > picks the one from primary-noarch (F15 gold /
> > redhat-rpm-config-9.1.0-5.fc14.noarch).
> Argh. It should be installed properly on the host (this is something we
> did previously explicitly in the images that we made) so would be used
> by mock anyway. If that's not happening, we need to fix that by pulling
> in the right set of macros. It's not a disaster since interworking
> renders the two compatible and won't break anything, and when we rebuild
> again in Koji, we'll just make sure we do it right that time.
whats on the host doesnt matter at all in any way shape or form. whats
installed into the chroot sets everything.
Updates to the wiki for F15 generally are coming soon. Meanwhile...
If you are wanting to get involved in the F15 bootstrap, and you have a
TrimSlice, you might be interested in the following image+instructions:
This can be installed onto an SD Card or microSD Card installed into an
SD Card adapter in the front slot (for other users, you will need to
adapt the boot.scr/cmd files - or ask for assistance if you like). Once
installed, you can copy the content onto the internal SSD:
0). mkfs.ext3 -L root /dev/sda1
1). mount /dev/sda1 /mnt
2). mkdir /mnt/dev /mnt/mnt /mnt/proc /mnt/selinux /mnt/sys
-ax /bin /boot /etc /home /lib /media /opt /root /run /sbin /srv /tmp /usr /var /mnt
4). Edit the first line of /etc/fstab to use /dev/sda1
5). Change the file /boot/boot.cmd to contain:
setenv bootargs mem=384M@0M mem=512M@512M nvmem=128M@384M vmalloc=248M
video=tegrafb console=ttyS0,115200n8 rw root=/dev/sda1 nohdparm rootwait
ext2load usb 0:1 4080000 /boot/uImage
ext2load usb 0:1 4400000 /boot/uInitrd
bootm 4080000 4400000
(no new line between "setenv" and "rd_NO_PLYMOUTH")
6). mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n "TrimSlice
boot script" -d /boot/boot.cmd /boot/boot.scr
8). Press power button for 4 seconds, remove (micro)SD Card
9). Power on.
There is no swap in the default configuration. You will need to change
the network configuration, etc. See the readme file for more detail.
P.S. For Red Hat folks, this image includes all of the necessary
packages to mount and use NFS client shares, RPC, and so on.
I want to let you know I have some notes from LPC that I will be sending
out. I didn't get to this on Friday, so I plan to have it out first
thing Mon. I'll followup to this thread once I have that taken care of.
THe hardfp bootstrap is progressing quite well, now at the stage of
resolving a fairly long list of build failures and circular package
The brute force dependency resolution have now come to an end, and
manual action is required to continue building packages. It's quite
amasing how many packages are FTBFS in F15, even major ones. Becaue fof
this the build queue is currently empty most of the time, but
occationally we repopulate a bunch of packages as problems gets
identified and resolved.
Notes on how problematic packages are solved is kept in detail at
wiki have also been updated (thanks DJ Delorie) with the notes from the
previous status update and additional notes colleced after that.
For those running builders it is now relatively important you update yum
on the build node (yum update yum) and also keep the arm-rebuild.sh
We are not yet ready to kill stage3 (but hopefully not before long), and
the original yum gets quite confused by the stage3/stage4 overlap in
package versions, often picking bad quality packages from stage3 when it
should have used stage4. And due to the shaking of the packages we are
currently doing on stage4 yum often fails for that reason as well which
is not handled well unless the script is updated.
If you do not update then you may actually do more harm than good at the
moment, causing false build failures. Most of them gets automatically
identified by other scripts however, just takes longer time.
If you have the time then please also update mock to
mock-1.1.12-1.fc15.noarch from Fedora-15 updates.
this fixes some PTY related problems and a couple of other minor things.
But this is not very important as I think all of those packages affected
by this have been built already.
mock 1.1.14 in updates-testing should be avoided. seem broken not saving
I meant to get to this already...but I'm short on time today.
If anyone has time, it would be super awesome to get the F15 bootstrap
docs updated on the wiki, explaining the stage4 process. I hope to get
back to this tonight...but if you have cycles, and are able to cover
this, let me know. I'm hoping to have this sorted for tomorrow so that
we can at least have an "unofficial" VFAD again.