[00:19] <asac> not using jit for mono makes compiler hit bad C code ...bails out
[00:19] <ogra> bah
=== persia` is now known as persia
[02:03] <sevenseeker> howdy, where can I obtain binaries of 9.04 for a sheevaplug?  Googling is giving me all sorts of goofy pages
[02:12] <persia> ports.ubuntu.com ought have individual packages.  No idea where to get images.
[02:12] <persia> Note that upgrading to 9.10 will break your system on a sheevaplug, and require reinstall.
[02:14] <sevenseeker> persia, yes thank you… I just read the 9.10 warning and was wondering if there is enough community to support maintaining a non VFP version of ubuntu
[02:14] <sevenseeker> just now starting to research
[02:18] <persia> sevenseeker: There's a bunch of people, but not enough infrastructure.
[02:20] <sevenseeker> persia: what does launchpad currently (if any) support?  I am new to embedded ubuntu, but have used launchpad to make packages for my ppa before
[02:21] <persia> This isn't the best place to talk about embedded ubuntu, because we don't do anything to make it more embedded friendly: we just do Ubuntu on armel.
[02:21] <persia> Mind you, many "embedded" systems are now powerful enough that this doesn't matter.
[02:21] <persia> But I wouldn't try to install Ubuntu on a network interface, for example :)
[02:21] <persia> Anyway, that aside ...
[02:22] <persia> launchpad PPAs don't suppprt armel at all right now.
[02:22] <sevenseeker> aha, good to know
[02:22] <persia> (same as powerpc, sparc, ia64)
[02:22] <sevenseeker> sad I am, but still good to know, lol
[02:22] <persia> But Ubuntu is available for armel.
[02:23] <persia> So any software in Ubuntu can be used.  Adding new software to Ubuntu isn't particularly hard, but there are several ways to do it, which can be a bit confusing.
[02:23] <persia> But since there are already something like 20,000 software packages, most of what one needs is already there.
[02:23] <sevenseeker> I also build Alix based systems but use openwrt for that
[02:24] <persia> Ubuntu 9.04 was ARMv5t+ compatible.
[02:24] <persia> 9.10 was ARMv6+vfp+ compatible
[02:24] <persia> 10.04 seems to be ARMv7/Thumb2
[02:24] <persia> (but it's not out yet, so no promises)
[02:24] <persia> Rumour has it that this escalation will be stopping soon.
[02:25] <persia> So one hopes that in the not-too-distant future, one can safely upgrade on common consumer devices.
[02:26] <sevenseeker> that would be nice
[02:26] <rcn-ee> persia, ARM hasn't announced anything past ARMv7...  So any cortex-aX device is safe...
[02:27] <sevenseeker> then maybe more embedded friendly sub-distros could be worked on… who knows?
[02:27] <persia> rcn-ee: So rumour has it, but I'm not privy to all conversations between all counterparties everywhere :)
[02:28] <persia> sevenseeker: Well, why do you need embedded?  Ubuntu 9.10 runs on devices with 2G storage and 256MB RAM.
[02:28] <sevenseeker> lol, you could be my 'insider' for info
[02:28] <persia> You could probably make it even smaller if you just did a single-purpose server.
[02:29] <sevenseeker> well its like this… I love that 'embedded' class systems are getting faster/more ram/better/etc… but it seems like much software is just banking on this and being lazy (I know I did that previously… ok, now)
[02:29] <rcn-ee> persia, if you factor in the time between ARM announcing ARMv7 devices, product availably from silicon manufactures and gcc support..  It'll be couple years before the next ARMv+ would be out..
[02:30] <sevenseeker> but the more tight it is the better it can use whatever system its on basically
[02:30] <persia> rcn-ee: That's my opinion as well.  I just tend to be careful when I don't have any formal statements.
[02:30] <sevenseeker> note: I have been optimizing for 2 weeks and probably am stuck mentally in that mode now
[02:30] <persia> sevenseeker: The main difference in "embedded" is usually stuff like not shipping documentation, etc.
[02:31] <persia> The code should be made as efficient as possible regardless of the target, for performance reasons.
[02:31] <sevenseeker> I agree
[02:32] <sevenseeker> I use EC2 for some 'stuff' and my optimization sure does save me money :) :) :)
[02:32] <persia> The other common "embedded" choice is monolithic static binaries.  That gets hard to maintain in a modular fashion.
[02:32] <sevenseeker> wow, yes it is
[02:32] <sevenseeker> you mean like jffs?
[02:33] <persia> No, like compiling your app linked statically against glibc so that you don't have to ship as many files (because you didn't ship glibc)
[02:33] <persia> We (kinda) support jffs2, and I know of at least one consumer device being sold with Ubuntu on ubifs.
[02:33] <sevenseeker> aha
[02:35] <persia> But anyway, there's lots of optimisations.
[02:35] <persia> So the "bloat" is mostly docs, overhead from having lots of files, overhead from having a full package management system, etc.
[02:35] <persia> But flash is cheap :)
[02:36] <sevenseeker> I see, yeah that makes sense
[02:37] <persia> So anyway, for your sheevaplug, just stick with 9.04.  ports.ubuntu.com has lots of packages you can use.
[02:37] <sevenseeker> sweet, that sounds great
[02:37] <persia> And when you have a chance to get newer hardware, ask for something that is known to work with Ubuntu :)
[02:37] <sevenseeker> lol, yeah
[02:37] <persia> And if rcn-ee and my speculations are correct, you should be able to upgrade that to the latest version and keep up for a while.
[02:38] <sevenseeker> well, I am considering this summer prototyping a series of Alix boards based on full ubuntu, granted they are x86 and thus OT here
[02:39] <rcn-ee> sevenseeker, one note thou too, even with an unoptimzed debian dist, the sheevaplug is still pretty quick: http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-8971-28884-22100
[02:39] <sevenseeker> is there a similar system to sheevas that is cheap and readily available that uses > ARM v5?
[02:43] <persia> I haven't heard of anything in that form factor.
[02:43] <persia> Most people around seem to use development boards (beagle, babbage, etc.)
[02:44] <persia> The Sharp Netwalker is also available, but I don't know of anyone who hosts a kernel for it that can boot 9.10 ot lucid
[02:47] <sevenseeker> hmmm
[02:47] <sevenseeker> thanks for the info… and the reminder, I need to try a beagleboard just for kicks
[02:48] <sevenseeker> since it won't do HD it really would not be useful for me now, but a year ago … woah nellie!
[02:52] <rcn-ee> sevenseeker, with the dsp, HD'ish is possible.. "1280x720"  i have just not spent enought time getting the ubuntu side to work..  It does play video with the DSP in Angstrom...
[02:53] <sevenseeker> hmm, now THAT sounds very enticing
[02:53] <sevenseeker> thank you
[02:54] <rcn-ee> sevenseeker, this was done at FOSDEM this year, 6 beagles each connected it's own display.. we are still waiting from the ffmpeg guys on how they did it.. http://hardwarebug.org/2010/02/10/1080p-video-on-beagle/
[02:58] <sevenseeker> WOAH
[02:58] <sevenseeker> yeah, they need to reveal that :)
[08:12] <saeed> davidm
[08:32] <ogra> saeed, i guess thats a bad time to  catch him (2am at his place)
[08:41] <saeed> hi ogra
[08:41] <ogra> hey saeed
[08:42] <NCommander> hey saeed!
[08:42] <saeed> I need some help with the power button on Dove DB
[08:42] <saeed> Hi Michael
[08:42] <ogra> ericm_, ^^^
[08:42] <NCommander> saeed: whats the issue with the power button?
[08:43] <cooloney> saeed: long time no see
[08:43] <saeed> I want to make it trigger user space suspend and power off
[08:43] <ericm_> ??
[08:43] <saeed> Hi bryan
[08:43] <ericm_> hey saeed, how u doing dude
[08:44] <saeed> currenty that button implemented as input device
[08:44] <saeed> and it reports EV_SUSPEND when pressed/unpressed
[08:47] <saeed> hi eric
[08:51] <ericm_> Saeed, maybe you want your Xorg.log.0 pasted?
[08:52] <saeed> here?
[08:52] <eggonlea> paste.ubuntu.com
[08:53] <eggonlea> http
[08:56] <lool> saeed: Try xev under Xorg; do you see any event?
[08:57] <lool> saeed: AFAIK, we expect all buttons to trigger Xorg key press events, then gnome-power-manager listens to them
[09:00] <lool> saeed: To quickly paste stuff to paste.ubuntu.com, you might find http://people.canonical.com/~cjwatson/ubuntu-paste useful
[09:00] <lool> Or install the pastebinit package
[09:01] <saeed> check http://paste.ubuntu.com/373788/
[09:02] <lool> You have evdev at least
[09:02] <lool> saeed: Could you try running xev in a terminal and checking whether the power button triggers a Xorg keypress event?
[09:02] <saeed> xev doesn't show anything when pressing on the button
[09:03] <lool> (II) UnloadModule: "evdev"
[09:03] <lool> that's odd
[09:03] <saeed> also lsof /dev/input/event0 is empty
[09:03] <lool> Ah the unload is for another device
[09:03] <ogra> that it configures the kbd as a mouse looks wrong too
[09:04] <lool> saeed: Your xorg.log doesn't show any setup for event0
[09:04] <saeed> yes
[09:04] <lool> saeed: So probably Xorg doesn't think your event0 is an interesting device
[09:05] <saeed> yes, I added some file to hal/fdi/policy
[09:06] <lool> I think we're trying not to use hal anymore, but straight udev
[09:06] <lool> In the xorg-server source package, patch debian/patches/12-Add-libudev-input-hotplug-backend.diff adds this stuff
[09:06] <ogra> and xinput
[09:06] <lool> udev rules would look something like:
[09:06] <lool> SUBSYSTEM=="input", KERNEL=="event*", ENV{x11_driver}="evdev"
[09:06] <lool> SUBSYSTEM=="input", KERNEL=="event*", ENV{ID_CLASS}=="kbd", ENV{xkb.layout}="fr", ENV{xkb.options}="terminate:ctrl_alt_bksp,compose:lwin"
[09:07] <ogra> i think we're supposed to use the xinput tool
[09:07] <lool> saeed: Check /lib/udev/rules.d/64-xorg-xkb.rules, does it match your device?
[09:07] <ogra> but at least here i cant make it use any device
[09:07] <ogra> (instead of xev)
[09:08] <ogra> we should ask tseliot, he cares for the whole xinput stack
[09:08] <lool> That's just xkb actually
[09:08] <lool> saeed: I would add a ENV{x11_driver}="evdev" property to your device
[09:09] <saeed> where should I add that?
[09:10] <lool> saeed: For now, add it manually to your local udev rules
[09:11] <lool> saeed: Something like /etc/udev/rules.d/90-power-button.rules
[09:11] <saeed> at /etc/udev/rules.d/ ?
[09:11] <saeed> ok
[09:11] <lool> with SUBSYSTEM=="input", KERNEL=="event0", ENV{x11_driver}="evdev"
[09:11] <lool> But I'm not an udev expert
[09:12] <lool> saeed: You can raise the verbosity of udev to debug this
[09:13] <lool> /etc/udev/udev.conf use info
[09:14] <lool> saeed: Ah I found some good examples
[09:15] <lool> saeed: /lib/udev/rules.d/66-xorg-synaptics.rules
[09:15] <lool> That sets ENV{x11_driver}="synaptics" and some additional options for some devices
[09:15] <lool> the generic rule is /lib/udev/rules.d/65-xorg-evdev.rules
[09:16] <lool> saeed: So your problem is that /lib/udev/rules.d/65-xorg-evdev.rules doesn't map your device to evdev
[09:16] <lool> saeed: It only maps devices of type keyboard, mouse, touchscreen or touchpad
[09:16] <lool> saeed: What intput type are you using?
[09:22] <saeed> keyboard
[09:22] <lool> saeed: Odd, so the generic rule should have mapped it to the evdev xorg driver
[09:22] <lool> saeed: You probably want some udev debug to see if that gets properly assigned
[09:23] <lool> saeed: Basically make sure that x11_driver gets set to evdev, then it becomes a xorg-server issue if it didn't load an evdev xorg driver for this device
[09:25] <ogra> (**) "Power Button": always reports core events
[09:25] <ogra> (**) "Power Button": Device: "/dev/input/event0"
[09:25] <ogra> (II) "Power Button": Found keys
[09:25] <ogra> (II) "Power Button": Configuring as keyboard
[09:25] <ogra> (II) XINPUT: Adding extended input device ""Power Button"" (type: KEYBOARD)
[09:25] <ogra> thats what i have on my laptop
[09:25] <ogra> so the keyboard driver should be fine for it
[09:26] <ogra> s/keyboard driver/evdev driver in keyboard mode/
[09:26] <saeed> here is the lshal part for the button http://paste.ubuntu.com/373798/
[09:28] <ogra> hmm, you shouldnt be having hal installed if you run lucid
[09:28]  * ogra wonders if that gets in the way somehow
[09:29] <ogra> (it shouldnt though)
[09:29] <lool> saeed: udevadm info --query=all --path=/sys/class/input/event0
[09:30] <lool> this is my power button http://paste.ubuntu.com/373800/
[09:30] <lool> You can see x11_driver=evdev
[09:31]  * lool had a great idea before sleeping in last night
[09:31] <saeed> the info.capabilities is just input, maybe is should be input.keyboard?
[09:32] <lool> saeed: Yes, that's likely why the generic rule doesn't match
[09:32] <lool> saeed: On my power buttong I have E: ID_INPUT_KEY=1
[09:32] <lool> saeed: Do you have it?
[09:36] <saeed> no
[09:36] <lool> saeed: Ok, that's your issue then
[09:37] <lool> saeed: Actually there seem to be two types
[09:37] <lool> One for keyboard and one for key
[09:37] <lool> /lib/udev/rules.d/60-persistent-input.rules references ID_INPUT_KEYBOARD
[09:37] <lool> saeed: But you basically want to set your kernel driver evdev props to key or keyboard
[09:39] <ogra> are we actually sure we want gpoi mapped to Xorg at all ?
[09:39] <lool> We're sure we want the power button mapped
[09:39] <ogra> right, but that doesnt necessarily need to happen with evdev
[09:40] <lool> ogra: What do you propose?
[09:40] <ogra> especially for gpio ... i.e. look at lirc which uses gpio buttons
[09:41] <ogra> it doesnt have much useful stuff, but definately doesnt use evdev ... all we need is to capture the gpio even somehow and make g-p-m aware through devkit-power
[09:42] <lool> saeed: I checked the ACPI power button implementation, and it does: input->evbit[0] = BIT_MASK(EV_KEY);
[09:43] <lool> set_bit(KEY_POWER, input->keybit);
[09:43] <ogra> though the devkit-power rules dont seem to have anything useful in them regarding buttons
[09:43] <lool> saeed: drivers/acpi/button.c:395
[09:43] <saeed> ok, I'll try that
[09:44] <lool> ogra: Can use your lirc device to power off?
[09:47] <lool> cooloney: WRT LP #516352, did you also cherry-pick the commit removing the file on package removal?
[09:47] <ubot4> Launchpad bug 516352 in linux-fsl-imx51 (Ubuntu) "fsl-imx51: need backport module.builtin to .31 kernel for lucid userspace compatibility (affects: 1)" [Medium,Fix released] https://launchpad.net/bugs/516352
[09:48] <lool> cooloney: 69f2227cdca42c4bbaa6fc931e64385f7fdee38f
[09:48] <ogra> grrr
[09:48]  * ogra hates reconnects
[09:48] <ogra> lool, /lib/udev/rules.d/95-keymap.rules has what we want
[09:48] <ogra> for example ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_name}=="Extensa*", ATTR{[dmi/id]product_name}=="*5210*|*5220*|*5610*|*5620*|*5720*", RUN+="keymap $name 0xEE screenlock"
[09:48] <ogra> (see the RUN part)
[09:48] <ogra> saeed, do you see any events in dmesg if you press the button ? preferably with a keycode ?
[09:49] <cooloney> lool: oh, i just cherry picked 2 .32 patches to .31 kernel as we discussed before
[09:49] <lool> cooloney: You might want the above SHA too
[09:50] <lool> ogra: What you're pointing at is for extra keys on laptop keyboards
[09:51] <ogra> lool, yes
[09:51] <ogra> well, keymapping for buttons not used by X
[09:51] <lool> ogra: The mvl-dove driver doesn't need any specific rule IMO
[09:51] <ogra> you want a low level power key event
[09:51] <lool> We just need to have the power key device using the proper class
[09:51] <ogra> which isnt mapped atm
[09:51] <lool> I don't think that's needed, no
[09:52] <ogra> well, as i understood it already emits an event
[09:52] <ogra> its just not mapped to power
[09:52] <lool> ogra: As you can see in the Xorg log, the device is not seen by Xorg at all
[09:52] <ogra> why should it be seen by Xorg at all ?
[09:52] <lool> While on your system and mine it is
[09:52] <ogra> you want a power event from the kernel
[09:52] <lool> No
[09:53] <lool> You want a keypress event
[09:53] <ogra> which you likely already get
[09:53] <ogra> <saeed> currenty that button implemented as input device
[09:53] <ogra> <saeed> and it reports EV_SUSPEND when pressed/unpressed
[09:54] <ogra> if there is a keycode emitted too a rule will just map it properly
[09:54] <lool> ogra: Try it out
[09:54] <cooloney> lool: do you mean this "UBUNTU: [Config] armel -- cleanup to-be builtin modules", right?
[09:55] <lool> cooloney: No, I mean UBUNTU: Add modules.builtin.bin to prerm rm list
[09:55] <lool> cooloney: Try installing and removing a fsl-im51 kernel package, you will see that a file is left behind
[09:56] <lool> cooloney: (modules.builtin.bin)
[09:57] <saeed> now xinput show the gpio device
[09:57] <lool> saeed: Wee
[09:57] <saeed> xev shows nothing when pressing on the button
[09:57] <saeed> thanks lool
[09:57] <ogra> lool, * include modules.builtin in the binary debs ?? that one ?
[09:58] <lool> ogra: I don't understand what you're commenting on
[09:58] <ogra> your discussion with cooloney
[09:58] <saeed> brb
[09:58] <lool> ogra: Your comment doesn't make any sense in the discussion
[09:58] <cooloney> lool: ok, got you, i just recall that this patch is from you, right?
[09:58] <lool> saeed: You need to have the proper flags when sending the event too
[09:59] <lool> saeed: Specifically, it needs to be a key event
[09:59] <lool> cooloney: It is from me indeed, which is why I recall it
[09:59] <lool> cooloney: It should go together with the modules.builtin backport/cherry-pick you're doing
[10:00] <cooloney> yeah, i noticed that, thanks for reminding me
[10:00] <cooloney> but the SHA on my side is 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
[10:01] <cooloney> roc@roc-desktop:/opt/git/Ubuntu/lucid$ git show 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
[10:01] <lool> cooloney: You're right, it's 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
[10:01] <cooloney> commit 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
[10:01] <cooloney> Author: Loïc Minier <lool@dooz.org>
[10:01] <cooloney> Date:   Wed Feb 3 05:32:45 2010 +0000
[10:01] <cooloney> UBUNTU: Add modules.builtin.bin to prerm rm list
[10:01] <cooloney> BugLink: http://bugs.launchpad.net/bugs/516584
[10:01] <ubot4> Launchpad bug 516584 in linux (Ubuntu) "modules.builtin.bin not removed on package removal (affects: 3) (dups: 1)" [Undecided,Fix released]
[10:01] <lool> cooloney: Must be a copy-paste error, sorry
[10:01] <cooloney> lool: ok, cool. I will cherry pick that to my branch
[10:01] <ogra> which was included already
[10:01] <cooloney> lool: no problem, thanks a lot
[10:01]  * ogra really wonders what you guys are discussing here
[10:02] <cooloney> ogra: oh, really?
[10:02] <ogra> look at the imx changelog, apw usually includes the package fixes frim the linux package
[10:02] <ogra> *from
[10:03] <lool> ogra: It's certainly not in the git log of the fsl-imx51 branch
[10:04] <lool> Besides, it needs to be adapted to apply on debian.fsl-imx51/ anyway
[10:05] <lool> cooloney: I checked the fsl-imx51 and it still needs fixing
[10:05] <cooloney> ogra: lool is right.
[10:05] <lool> cooloney: debian.fsl-imx51/control-scripts/prerm, @files_to_remove
[10:05] <ogra> lool, because there was never a modules.builtin.bin until recntly in imx51
[10:05] <apw> yep i missed that one when i pulled fsl-imx51 togther
[10:05] <lool> ogra: And there is one now, because it was cherry-picked
[10:05] <cooloney> i need to cherry pick that patch with others
[10:05] <ogra> lool, right, since the very last upload
[10:05] <ogra> which i pointed to before
[10:05] <lool> I wonder how many people it takes to convince ogra that I'm right
[10:06] <cooloney> oh, guys, no problem,
[10:06] <cooloney> i will fix that soon,
[10:06] <apw> its in mvl-dove as part of the rebase
[10:06] <lool> cooloney: thanks; not a big deal anyway
[10:06] <lool> Just a leftover file, but it causes a warning on package removal
[10:06] <apw> not in fsl-imx51 cause its a franken kernel
[10:06] <cooloney> apw: right, because mvl-dove is .32 based anyway
[10:06] <lool> apw: Do you have some script to adapt the debian.foo/ pathname when doing these rebases?
[10:06] <apw> yep, cooloney get it to me soon :)
[10:07] <apw> lool, nope, just use vi on the patch
[10:07] <lool> hehe ok
[10:07] <lool> apw: Would it be much work to turn on udebs for versatile?
[10:08] <lool> I'm sure that's something you'd be excited about  :-)
[10:08] <apw> what the heck would we want those for
[10:08] <apw> i am sure the aa's would love a heap of more binary debs to wave though
[10:08] <lool> apw: I don't know for mobile team, but I'd love to point people at debian-installer images to install Ubuntu in qemu
[10:09] <lool> apw: That would allow providing just vmlinux on ports.ubuntu.com
[10:09] <lool> and a d-i initrd
[10:09] <apw> the work is not normally in eanbling them but in getting the result to pass the d-i pass afterwards
[10:09] <apw> if you don't have all modules built
[10:09] <lool> apw: something like http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/dove/ but for versatile
[10:10] <lool> apw: Ack; the work would probably involve adding some Provides to the binary package
[10:10]  * cooloney is vi on the patch file as apw said. heh
[10:10] <lool> apw: Because a lot of modules are builtin in the versatile config
[10:11] <apw> loads of ?'s to be added and you have to build it to find out which ones
[10:11] <lool> apw: The d-i side of things is just commented out for versatile BTW; it's well supported in d-i
[10:11] <lool> apw: Right
[10:11] <lool> something like that
[10:12] <lool> apw: Currently, if we want to pull the official kernel for versatile from lucid, we have to download a .deb and unpack it to get to the vmlinuz file which allows running qemu
[10:13] <apw> i have no objection to udebs or not, they arn't a big bit of the build
[10:13] <lool> So having d-i images would allow people to use them for install, and would also make it easier for e.g. rootstock to pull a kernel
[10:13] <lool> apw: I'd love that
[10:13] <lool> apw: Do you want me to check formally whether there are objections/interest in that from the mobile team?
[10:13] <apw> sure
[10:14] <lool> Ok, mailing ubuntu-mobile@
[10:19] <cooloney> apw: i found lool's patch can not apply to debian.fsl-imx51 directory,
[10:20] <lool> apw: FYI I just tested the in archive linux-image-2.6.32-13-versatile_2.6.32-13.18_armel.deb and it boots fine with lucid and karmic userspace
[10:20] <cooloney> apw: it does not have the whole line 'modules.alias.bin modules.dep.bin modules.symbols.bin' at all
[10:21] <lool> cooloney: You don't have .bin files with your fsl-imx51 kernel?
[10:21] <lool> apw: (I mailed ubuntu-mobile@)
[10:23]  * cooloney wants to punch his head to the wall, messed up his board.
[10:23] <cooloney> i need to reinstall my lucid on my board now
[10:31] <apw> cooloney, then have a look at the debian.master version of that file
[10:31] <apw> there is another patch which pulls the other two in you need as well
[10:33] <apw> cooloney, ironically it was your first patch i think
[10:33] <apw> commit 8b453930465c15f490ea44c2987b0a1bfe71ed66
[10:33] <apw> Author: Bryan Wu <bryan.wu@canonical.com>
[10:33] <apw> Date:   Wed Mar 25 17:31:26 2009 +0800
[10:33] <apw>     UBUNTU: Add 3 missing files to prerm remove file list
[10:35] <apw> cooloney, so you need that commit copied over first, then lool's one
[10:41] <cooloney> apw: that is a good memory for me
[10:41] <cooloney> apw: will do it soon
[10:41] <apw> whenever man
[10:54] <saeed> I changed the button to send EV_KEY instead on EV_PWR
[10:55] <saeed> now I see message "Failed to suspend" (hibernate)
[10:55] <saeed> I'll change the code to KEY_SLEEP instead of KEY_SUSPEND
[10:57] <lool> saeed: Great
[10:57] <lool> saeed: Where do you see the message?
[10:57] <lool> saeed: Are you running gnome-power-manager?
[10:58] <saeed> yes,
[10:58] <saeed> I think it failed to hibernate because the resume  param was wrong
[10:58] <lool> saeed: drivers/acpi/button.c uses KEY_POWER for ACPI_BUTTON_TYPE_POWER, so that seems correct
[10:59] <lool> saeed: Ack
[11:00] <lool> saeed: And it uses KEY_SLEEP for ACPI_BUTTON_TYPE_SLEEP; it doesn't use KEY_SUSPEND
[11:00] <saeed> oh, hibernation is disabled
[11:01] <lool> saeed: Yeah, you certainly don't want KEY_SUSPEND
[11:02] <saeed> ok
[11:02] <saeed> look, we are looking for the folowing behavior
[11:02] <saeed> if button pressed for less that 3 seconds , the system enters standby mode
[11:03] <saeed> othewise we want the system to shutdown
[11:03] <lool> saeed: Ok; so you would send KEY_SLEEP for < 3 secs and KEY_POWER otherwise
[11:03] <saeed> that means driver change, right?
[11:03] <lool> saeed: Oh you would like to implement the 3 secs in userspace?
[11:04] <saeed> yes
[11:05] <saeed> btw, lucid keeps showing the "failed to suspend" again and again
[11:19] <ogra> lool, bug 520028 ... what was the reason for dropping ubuntu-minimal ?
[11:19] <ubot4> Launchpad bug 520028 in project-rootstock "ubuntu-minimal doesn't build correctly for karmic (affects: 1)" [Undecided,New] https://launchpad.net/bugs/520028
[11:20] <ogra> iirc a patch from you dropped it
[11:20] <ogra> (though if its really upstart being at fault, there should be a hard dep)
[11:42] <saeed> guys, the suspend works fine now
[11:43] <saeed> however I wish ubuntu show message that the system going to suspend to ram
[11:43] <ogra> \o/
[11:43] <saeed> the rules file not needed of course
[11:45] <ogra> saeed, /var/log/pm-suspend.log should have something
[11:51] <saeed> ogra: here it is root@lucid-dove:~# cat /var/log/pm-suspend.log  Initial commandline parameters: Tue Jan 11 21:19:32 CST 2011: Running hooks for suspend. /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend:success. /usr/lib/pm-utils/sleep.d/00logging suspend suspend:Linux lucid-dove 2.6.32.3-dove-5.0.0-rc3-00671-g43c704e-dirty #200 Thu Feb 11 13:34:59 IST 2010 armv7l GNx Module                  Size  Used by              
[11:51] <saeed> sorry
[11:51] <saeed> here it is http://paste.ubuntu.com/373887/
[11:52] <ogra> ue Jan 11 21:19:33 CST 2011: performing suspend
[11:52] <ogra> thats the actual suspend
[11:52] <ogra> /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend:success.
[11:52] <ogra> Tue Jan 11 21:19:48 CST 2011: Finished.
[11:52] <ogra> is the final wakeup
[11:53] <saeed> ogra: I was expecting gui  message telling that the system going to suspend
[11:53] <ogra> ah
[11:53] <saeed> because it takce few seconds to do that
[11:53] <ogra> usually the screen fades out immediately
[11:54] <saeed> lool, eric, I see this kernel message when pressing on the button:
[11:54] <saeed> keyboard.c: can't emulate rawmode for keycode 142
=== jiteshs is now known as jitesh_afk
[12:34] <ogra> http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png
[12:34] <ogra> netbook-launcher is on the screen after 35 sec :)
[12:34] <persia> Nice!
[12:35] <persia> That's getting close to boot speeds I find acceptable in my laptop.
[12:35] <persia> What's the suspend/resume delay?
[12:35] <ogra> i think if jockey wouldnt run all the time in the background we'd get another 5 sec speedup
[12:35] <ogra> suspend takes a while to process the scripts, resume is instant
[12:35] <persia> Don't we need jockey?
[12:36] <ogra> we will need it once we have 3D drivers
[12:36] <ogra> the prob is that its *scanning* permanently due to a bug
[12:36] <persia> That's extra nice.  On my netwalker, I get about 2 seconds suspend and 3 seconds to resume (which Sharp advertises as a "3-second boot")
[12:36] <ogra> heh
[12:37] <ogra> i think suspend takes rather five here
[12:37] <persia> Well, I mean, really.  How often to people actually boot.  Even my laptop only gets booted for kernel updates.
[12:37] <ogra> but resume is just up after pressing the button
[12:37] <ogra> probably 1sec
[12:37] <persia> That's nice.
[12:38] <lool> saeed: I'm glad it works  :)
[12:38] <lool> saeed: Did you try emulating the power key as well?
[12:39] <lool> saeed: Will you do this in kernel?
[12:39] <lool> saeed: Concerning the feedback on suspend: a) some devices blink the power led in the kernel, and b) the suspend is supposed to be so quick that you don't need feedback, right?   :-)
[12:39] <saeed> I didn't try the power key
[12:41] <saeed> in karmic the system enters standby immediately
[12:41] <saeed> using echo mem > ..
[12:42] <saeed> regarding the power key,  it's easier for me to do it kernel, but I'm not sure if this is the right way
[12:59] <lool> saeed: I would think that an userspace hack wouldn't get upstream either
[13:00] <lool> saeed: IMO it's a device design problem
[13:00] <lool> saeed: This is going to be in a physical device for which the user experience is going to be "this button can do multiple things"; the button is going to be labelled with or more icons depending on what it does
[13:01] <lool> In another design you would have two buttons
[13:01] <lool> So I don't know whether you're trying to do a generic device design or whether you're trying to demonstrate shutdown and suspend with a single button on a particular design
[13:01] <lool> It's hack either way, but it's really related to your hardware layout
[13:02] <persia> What's the goal again?
[13:03] <lool> The kernel can send events for either a power or a suspend button press
[13:04] <lool> saeed would like a shutdown to happen if pressed more than 3 seconds and a suspend otherwise
[13:04] <persia> But on what does that depend, in terms of user experience.
[13:04] <persia> Ah, yeah, that needs to be a kernel thing.
[13:04] <persia> I'd hope additionally for a hardware shutdown if the key is held longer.  At least I use that on my Netwalker.
[13:04] <persia> (because sometimes software hangs)
[13:05] <persia> So HW differentiation for whether hold > 10s, and kernel differentiation for whether hold > 3s.
[13:06] <persia> But again, why bother shutting down with a button?  Is it that frequent a use-case to turn a device off?
[13:07] <lool> saeed: Or alternatively, call your key "User button 1", send your own event and keycode and write a tool to handle it   ;-)
[13:10] <persia> Um, in that case, just use the power button.
[13:11] <persia> We already have software that can take a power button event and perform various actions, which could be extended to meet the timing case.
[13:11] <lool> It might be simpler to have another software handle a timed key press and call into gpm rather than patching gpm
[13:11] <lool> (and easier to maintain/less intrusive)
[13:12] <persia> I guess.  I just don't like to have too many special HW hacks.
[13:12] <lool> Which is why I'd prefer having it separate
[13:12] <lool> instead of running the hack in gpm
[13:12] <persia> I'd rather enable a use case for a broad spectrum of HW, and have the HW produce something that works with existing software, to preserve user choice.
[13:13] <lool> You can always remap the key in software if you want
[13:13] <persia> Right, that would be the special HW hack: "If you have this board, you need to remap your keys like this: ..."
[13:14] <lool> Well you're proposing to patch GPM to have a mode "If this hardware is detected and button is pressed more than n seconds, do something else"
[13:14] <persia> Adding a fork function for timing in g-p-m would enable this class of behaviour for arbitrary HW which didn't expose a sleep button (and there's lots of that)
[13:14] <lool> I'm proposing to have a separate software which doesn't have the "if you have this hardware" and if people want to replace the software to use gpm, they can either patch gpm or remap thier keys
[13:14] <persia> No.  I'm proposing that g-p-m be patched to be able to have different actions happen for different timing delays in power button presses.
[13:14] <persia> No special HW detection.
[13:15] <lool> I don't think that'd fly
[13:15] <persia> Why not?
[13:15] <persia> I have hardware for three different architectures that doesn't have sleep keys.
[13:15] <lool> We'd have to run and maintain the patch for everybody instead of maintaining a single isolated trampoline
[13:16] <persia> Why wouldn't the patch go upstream?
[13:16] <ogra> dmart, i remember you filed a bug once on building the kernel with thumb2 but i cant find it on LP, do you happen to remember the bug number ?
[13:16] <lool> Well that's my opinion that's it's too specific
[13:16] <lool> Upstream mught have a different opinion
[13:17] <persia> lool: How specific.  Like I said, I have HW for three different architectures with no sleep button, and none of it is saeed's HW.
[13:17] <lool> persia: For instance, why do it for the power button and not the sleep button?
[13:18] <persia> lool: No reason at all.  Generalisation is good.
[13:18] <lool> Then you also need some GUI, more GUI == more confusion
[13:18] <dmart> ogra: can you remember what it was about?  I don't remeber filing a bug on Thumb-2 kernels yet.
[13:18] <persia> Users with both power and sleep would be able to get to all of shutdown, hibernate, suspend, and screen-lock.
[13:19] <ogra> dmart, well, that the kernel should be built with thumb2 (not the config option but the kernel binary being a thumb2 binary)
[13:19] <ogra> i know we reviwed that in dallas and i thought it resulted in a bug you filed
[13:19] <persia> lool: My basic point being that the utility you describe would simply not work for any of my hardware without a sleep button.  To me, this is HW-specific.
[13:20] <dmart> ogra: I don't think I filed a bug.  It's not required that we build the kernel in Thumb-2, but we can try it if you think we're ready.
[13:20] <dmart> ogra: I think it is a config option actually
[13:20] <ogra> dmart, well, apw seems to just research that
[13:21] <apw> yep ... 'we' have a sprint in a half hour on this stuff right?
[13:21] <ogra> having smaller kernels surely helps speed up the boot
[13:21] <ogra> apw, thats more about porting packages :)
[13:21] <ogra> not sure kernel packages were meant there :)
[13:21] <apw> linux was listed, i noticed when i read the announcements
[13:22] <dmart> ogra: Bear in mind that there may be platform-specific drivers with assembler code, so it might not all work out of the box.  I would hope that there's not much of that however.
[13:22] <ogra> ah
[13:22] <dmart> Most of the assembler is in the general arch/arm code though, and that should be OK in the lucid kernel versions.
[13:25] <lool> persia: Technically you could make the utility I describe listen to power button instead and disable GPM
[13:28] <persia> lool: That would address all of my concerns :)
[13:59] <lool> I filed lp #520465 on the qemu/linux/eglibc/glib2.0 issue
[14:00] <ubot4> Launchpad bug 520465 in ubuntu "armel/versatile: glibc detected double-free or corruption (!prev) (affects: 1)" [Undecided,New] https://launchpad.net/bugs/520465
[14:00]  * asac waves
[14:00] <lool> It's not a priority for me, but it would be nice to fix it for lucid
[14:01]  * ogra is here
[14:01] <ogra> lool, its a priority for me to be able to use the archive kernels though
[14:01]  * ogra subscribes
[14:02]  * JamieBen1ett waves back
[14:02] <ogra> ah, armel is subbed already, good
[14:02] <asac> dmart: dyfet: StevenK: persia: ping ;)
[14:02] <dmart> Hi there
[14:02] <dyfet> pong
[14:02]  * persia will be about 10 minutes late
[14:03] <asac> persia: ok. please read the backlog then ;)
[14:03] <asac> anyone else here for the porting sprint?
[14:03] <persia> Always :)
[14:03] <dyfet> dealing also with replacing a furnace this morning :(
[14:03] <asac> what is a furnace?
[14:03]  * asac goes for dictionary
[14:04] <dmart> big firey thing
[14:04] <asac> dyfet: so you cannot attend?
[14:04] <dyfet> http://en.wikipedia.org/wiki/Furnace :)
[14:04] <ogra> oven :)
[14:04] <dyfet> No I can...
[14:04] <asac> good
[14:04] <dyfet> Just annoying distraction ;)
[14:04] <asac> ok
[14:04] <dyfet> and a bit cold this morning ;)
[14:04] <dmart> While we're waiting for persia, people might want to pull up https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
[14:05] <asac> that should be fine ... our excersizes will make you feel hot i am sure ;)
[14:05] <persia> NO reason to wait: I'm loosely about, just distracted for another 5 minutes or so.
[14:05] <ogra> erm
[14:05] <ogra> did anyone notify any MOTUs ?
[14:05] <asac> we announced it on mobile
[14:05] <ogra> given the univers list is HUGE
[14:06] <ogra> i doubt many MOTUs read mobile
[14:06] <asac> and on internal list
[14:06] <dmart> ogra: may not be an issue for the first pass
[14:06] <asac> ogra: we can spread the news to wider forum for the next time
[14:06] <dmart> Partly I want to know what else needs to be documented
[14:06] <lool> dmart: The first pass is not enough to fix all bugs?   ;-)
[14:06] <asac> we have https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
[14:06] <dmart> lool: well, obviously, if you're feeling energetic ;)
[14:06] <ogra> asac, definately should be announced on ubuntu-motu@ next time
[14:06] <asac> which should give us a decent amount of work
[14:07] <asac> ogra: well. i usually dont hunt in random territory ... we could also have it announced on -devel
[14:07] <asac> which most motus are subscribed to too
[14:07] <ogra> yeah
[14:07] <dmart> What's the best way to do this?
[14:07] <dmart> I suggest we pick one package from the list and all take a look, and discuss.
[14:07] <asac> right
[14:07] <asac> i suggest that dmart takes the lead ;)
[14:07] <ogra> either way i dont expect that our litle crew manages all these universe issues
[14:07] <asac> so boost stuff is already done
[14:08] <asac> dmart: maybe we can go by topic?
[14:08] <asac> e.g. today focus on "mov" issues?
[14:08] <dmart> That was going to be my suggestion
[14:08] <dmart> any ideas about which one?
=== lool changed the topic of #ubuntu-arm to: Thumb2 bug squashing party | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
[14:08] <asac> ok lets pick a first mov one
[14:08]  * asac checks list
[14:09] <ogra> mono ! :)
[14:09] <asac> first in list is djvulibre
[14:09] <dmart> maybe start with something simple?
[14:09] <dmart> djvulibre looks like it was a simple one
[14:09] <ogra> yeah
[14:09]  * ogra wasnt serious with mono :)
[14:09] <asac> ok everony get the source ;)
[14:10] <asac> so how do we find the right places?
[14:10] <ogra> grep ?
[14:10] <dmart> mono comes later :)
[14:11] <ogra> *shudder*
[14:11] <asac> djvulibre-3.5.22$ grep -r mov * | pastebinit
[14:11] <asac> http://pastebin.com/f55740dea
[14:11] <dyfet> and mono jit? :)
[14:11] <asac> guess that grep can be tweaked
[14:12] <JamieBen1ett> so is this a mov only problem or does that include mov's such as movq?
[14:12] <ogra> grep -R " mov " * ?
[14:12] <JamieBen1ett> grep -R "mov " *
[14:13] <ogra> yeah
[14:13] <JamieBen1ett> 7 occurances
[14:13] <persia> So we're just looking at ZPCodec.cpp and MMX.cpp
[14:13] <dyfet> And GThreads.cpp?
[14:13] <persia> Can we ignore MMX.cpp, under the assumption that we're not going to take that codepath for HW that doesn't declare MMX?
[14:13]  * persia doesn't see GThreads.cpp from ogra's grep.
[14:13] <JamieBen1ett> so no mov's that use the sp
[14:14] <JamieBen1ett> sorry pc
[14:14] <asac>  grep -r mov.*pc *
[14:14] <asac> libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %1
[14:14]  * dmart was distracted, back now
=== lool changed the topic of #ubuntu-arm to: Thumb2 bug squashing party | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList | https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
[14:15] <asac> so the GThreads.cpp seems to be right match?
[14:15] <asac> dmart: ?
[14:16] <dmart> To find the occurrences, it's probably a good idea to look at the original grep list
[14:16] <dmart> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList?action=AttachFile&do=get&target=search-arm-mov.filt.gz
[14:16] <dmart> (linked from https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList)
[14:17] <dmart> GThreads.cpp is indeed the location of the hit we got.
[14:17] <persia> So GThreads is the only issue, and we can ignore ZPCodec.cpp as well?
[14:17] <dyfet> asac: it's a mov pc, someregister op...a candidate for bx?
[14:17] <asac>  grep djvulibre *
[14:17] <asac> /var/cache/debmirror/pool/main/d/djvulibre/djvulibre_3.5.22-1ubuntu2.dsc
[14:17] <asac>  ./djvulibre-3.5.22/libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %1
[14:17] <asac> persia: only stuff that messes with "pc" is relevant from what i understood
[14:17] <dmart> dyfet: would you like to suggest a fix? ;)
[14:18] <dyfet> Well, it may not expand to a simple fix because the actual mov might be a movl, etc...
[14:18] <dmart> movl?
[14:19] <dyfet> The closest relevant fix might be using a string constant, and maybe #ifdef (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
[14:19] <dyfet> #define ARM_MOVPC "mov%?\t%|pc, %1"
[14:19] <dyfet> #else
[14:20] <dyfet> #define ARM_MOVPC "bx%? , %1" ???  well, its hard to say how this expands exactly
[14:21] <dmart> What did you mean by movl?  This doesn't mean anything to me (at least for arm)
[14:21] <dyfet> Sorry, I meant the mov may not be for pc since it seems like some conditional substitution....thats why I am uncertain
[14:22] <dmart> oooh, that's a new one on me.  What does %? do in gcc asm?
[14:23] <dyfet> Yea that is what I was wondering...
[14:23] <dmart> A good first step could be a stick a #error in there and build (since the code depends on -DCOTHREAD_UNTESTED, which might not be defined in our build?)
[14:24] <asac> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
[14:24] <ogra> AT&T Code ... heh
[14:24] <asac> i dont see anything about %?
[14:25] <dmart> can't find it; maybe it adds the right AT&T operand size suffix.  That wouldn't apply to ARM, but then %? is only present in the ARM version.
[14:25] <ogra> weird
[14:26] <asac> yeah. lets ignore that
[14:26] <dyfet> Then I think the simplest case is we want effectively a "bx %1"...
[14:27] <asac> thats the obvious idea
[14:27] <asac> what does the |pc mean?
[14:27] <ogra> yeah
[14:28] <dmart> Dunno!  I'll see if I can find out from anyone here.
[14:28] <asac> its probably %|
[14:29] <dyfet> asac: I read the original as effectively reducing to "mov pc, %1" but yea, I wondered about that too
[14:29] <asac> right
[14:29] <dmart> It might be the case that GCC can substitute condition codes for %?
[14:29] <dmart> but it's no documented if so
[14:29] <dyfet> But is it even a valid code path?  Its tied to COTHREAD_UNTESTED being defined...
[14:29] <dmart> indeed
[14:29] <dmart> I think the best thing iintially is
[14:29] <dmart> #ifdef __thumb__
[14:30] <dmart> #error "Needs porting to Thumb-2"
[14:30] <dmart> #endif
[14:30] <dyfet> Yes, lets see if it even builds that path first :)
[14:30] <dmart> If this doesn't ftbfs, then someone can worry about it later :)
[14:30] <dyfet> dmart: agreed
[14:30] <asac> dyfet: ok want to create the diff for the file ... and i just upload ;)?
[14:31] <dyfet> well, we have the other mov's to look at too :)
[14:31] <asac> we will see if it fails then in a bit
[14:31] <dmart> OK
[14:31] <asac> dyfet: that was the only mov
[14:31] <dmart> hold on
[14:31] <asac> sure
[14:31]  * asac waits
[14:31] <ogra> dyfet, only "mov, pc"
[14:31] <asac> mov.*pc
[14:32] <dyfet> true....but then if its not explored, there must be another reason for the ftbfs :)
[14:33] <dmart> http://pastebin.ubuntu.com/373995/
[14:33] <asac> dyfet: it currently ftbfs?
[14:33] <dmart> hmmm, guess we should look at the log
[14:33] <dyfet> And since the end of it reaches a #error if none of the paths are explored, it has to be here...but yes, let's look at the log
[14:33] <persia> dyfet: I don't see it at http://qa.ubuntuwire.com/ftbfs/
[14:34] <asac> dmart: right. i wanted dyfet to produce that ... but ok ;) ... let me upload
[14:34] <persia> Um, should we not try a local build first to make sure that fixes it?
[14:35] <ogra> persia, queue is empty
[14:35] <JamieBen1ett> persia: its not a fix, its just a warning in case that code path is taken
[14:35] <dmart> doing one, but it may take some minutes
[14:35] <dyfet> I am going to try a local build quickly...
[14:35] <JamieBen1ett> (or so I understand)
[14:35] <ogra> we can play with the buildds unless they are busy
=== JamieBen1ett is now known as JamieBennett
[14:35] <persia> JamieBennett: Right: it's that I don't tend to like to generate lots of archive churn when it might fail :)
[14:36] <dmart> Our first priority is to get everything building and working in lucid.  Fixing code paths which are not built is nice to have, but putting a #error bomb is a reasonable way of helping ensure it gets fixed at the appropriate time
[14:36] <dyfet> dmart: I think that code path has to be built, otherwise it would fall into a default #error after that section
[14:37] <dmart> ...unless the package is built with -DTHREADMODEL=NOTHREADS
[14:37] <asac> ok can we use a pastebin != ubuntu?
[14:37] <dyfet> Hmm...we could also do that :)
[14:38] <persia> asac: Why?
[14:38] <asac> thats just annoying. you cant wget the plain text because of openid
[14:38] <dmart> any suggestions?
[14:38] <asac> just pastebin.com
[14:38]  * persia thought that was fixed, but tends to have trouble parsing other pastebins
[14:38] <lool> dmart: debian's work
[14:38] <lool> alias debian-paste='pastebinit -b http://paste.debian.net'
[14:38] <asac> every pastebin works ... just paste.ubuntu.com is broken
[14:38] <lool> \o/  :)
[14:38] <asac> i already kicked #is for that ... seems they didnt listen
[14:38]  * asac does that again
[14:38] <lool> persia: It got fixed and borken a couple of days later sadly
[14:39] <lool> asac: It was fixed for a day or two
[14:39] <dmart> I don't know the answer to thathttp://paste.debian.net/59542/
[14:39] <dmart> oops
[14:39] <dmart> http://paste.debian.net/59542/
[14:39] <persia> That's one I can parse cleanly :)
[14:40] <asac> dmart: thanks. i did it manually now
[14:40] <asac> uploaded
[14:41] <dmart>  /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2  -pthread -DTHREADMODEL=POSIXTHREADS      -c GThreads.cpp
[14:41] <dmart>  g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2 -pthread -DTHREADMODEL=POSIXTHREADS -c GThreads.cpp  -fPIC -DPIC -o .libs/GThreads.o
[14:41] <dmart> In file included from DjVuMessageLite.h:74,
[14:41] <dmart>                  from GThreads.cpp:76:
[14:41] <dmart> GString.h:745: note: the mangling of 'va_list' has changed in GCC 4.4
[14:41] <dmart>  g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2 -pthread -DTHREADMODEL=POSIXTHREADS -c GThreads.cpp -o GThreads.o >/dev/null 2>&1
[14:41] <dmart> File seemed to build OK
[14:42] <persia> So we conclude that this code path is never exercised, and just leave the comment as a note?
[14:42] <asac> i uploaded the patch that would catch it for __thumb__
[14:42] <asac> thats ok imo
[14:43] <persia> As it turns out, yes :)
[14:43] <dmart> If it's considered OK to add #error (provided it's for a case we know definitely won't work)
[14:43] <asac> we should upstream that or suggest the right way ... e.g. bx
[14:43] <dmart> yes, it might be a good idea to make the comment clearer
[14:43] <asac> dmart: i think for cases where we cant try the code path its ok to use #error ... otherwise we should obviously fix it
[14:44] <ogra> next package ?
[14:44] <persia> I'm perfectly happy to use #error as a base of test builds, and if we don't hit the code path, replace with a useful comment.
[14:44] <ogra> gmp seems small
[14:44] <dmart> Probably worth discussing this one a bit further first
[14:45] <dmart> persia: Why is a comment (which will go unnoticed) better than #error (which won't)
[14:45] <ogra> well, what if we hit it and have no solution ?
[14:45] <asac> i think #error is fine. we should upstream that so they know
[14:45] <ogra> hope for upstream ?
[14:45] <dmart> #error potentially saves someone a lot of debugging
[14:45] <asac> ogra: we would have a solution. but we cant test it because the code is not used
[14:45] <persia> dmart: I want *both* the comment and the #error : the #error to force it not working if the codepath is hit, and the comment to tell someone why we added that patch.
[14:45] <asac> so should we add something untested? or just ad an error
[14:46] <dmart> Oh, OK.  Yes adding extra explanation in a comment is of course a very good idea :)
[14:46] <asac> persia: right. thats what we did
[14:46] <asac> we can improve the comment on next one though
[14:46] <asac> +#ifdef __thumb__
[14:46] <asac> +#error "This code needs some porting to work correctly in Thumb."
[14:46] <asac> +#endif
[14:46] <asac> maybe point to the porting page
[14:46] <dmart> good idea
[14:46] <asac> anyway. lets move on
[14:46] <asac> gmp ;)
[14:46] <dmart> Since djvulibre is a simple example, I think it's worth discussing how we would fix it (if we needed to)
[14:47] <dmart> Someone suggested bx
[14:47] <dyfet> dmart: yes :)
[14:47] <ogra> dyfet, did
[14:47] <ogra> #define ARM_MOVPC "bx%? , %1"
[14:47] <dmart> ... so far so good, but it's worth taking a step back and looking at the context of this code so we are sure we're doing the right thing
[14:48] <dyfet> Well, I was not sure what the %? was about....but essentially something like that...
[14:48] <asac>                     "mov%?\t%|pc, %1"     // branch to address %1
[14:48] <asac> so it uses that to branch to %1 ... which is .... hmm
[14:48] <dmart> I _think_ we could pretend the %? is not there.  I can't think of anything vital that it would do.
[14:49] <dmart> but best not to alter that aspect of the code in the fix in case it matters
[14:49] <dmart> scrolling up a bit
[14:49] <dmart> static void
[14:49] <dmart> mach_start(mach_state *st1, void *pc, char *stacklo, char *stackhi)
[14:50] <dmart> Scrolling up a bit more, mach_state contains a jmp_buf
[14:50] <dmart> So this looks like a long jump / thread starting function if some sort.
[14:51] <dyfet> Yes, a funny kind of procedure call to start a thread....
[14:51] <dmart> %1 is the argument pc, which is just a pointer
[14:52] <dmart> But it's not a function pointer which is slightly suspicious
[14:52] <dmart> ...because it could be passed a pointer to some data (containing run-time generated code)
[14:52] <asac> dmart: its a func pointer
[14:53] <asac> just not declared explicitly
[14:53] <asac> mach_start(&st1, (void*)th2relay, stack, stack+sizeof(stack));
[14:53] <asac> void th2relay() {
[14:53] <dmart> certainly that's the likely case --- I was just going to suggest seeing how it's called, but you beat me to it :)
[14:53] <asac> and pc is the second argument
[14:54] <asac> ok lets grep for mor mach_start ;)
[14:54] <asac> the other is startone
[14:54] <persia> line 950
[14:54] <asac> which is also a func
[14:54] <asac> persia: right. thats the function where the asm code is in
[14:54] <asac> we are looking for callers now to see if its always a func
[14:55] <asac> so ... based on that is bx %1 still the right thing?
[14:55] <dmart> After a couple of examples, we can be reasonably confident, since passing a function is certainly how we would expect a thread start func to be used.
[14:56] <asac> right
[14:56] <dmart> but I just wanted to highlight the issue
[14:56] <dmart> Oh, btw:
[14:56] <dmart> %? - condition code used only in conditional execution.
[14:56] <dmart> %| - some kind of register prefix and legacy assemblers. Largely irrelevant today.
[14:56] <dyfet> it was a good educational example :)
[14:56] <asac> dmart: where did you find that?
[14:57] <dmart> Um, our tools guys here ;)  I'll try and get it merged in the docs if it's not upstream
[14:57] <asac> ok good. so are we confident enough to replace the error with bx %1? or want to keep the error as its not used?
[14:58] <persia> I think we should keep the error, but maybe add a comment suggesting bx %1 : we can't test the codepath, so we have no way of knowing if our solution works.
[14:58] <dmart> before that, I was going to talk about what would happen if we were passed a data pointer here
[14:58] <persia> Given that it's already uploaded, I think we should leave it alone.
[14:58] <dmart> Maybe someone wants to guess?
[14:58] <asac> ok
[14:59] <asac> dmart: bad things
[14:59] <asac> dmart: trying to call in data memory
[14:59] <JamieBennett> :)
[14:59] <asac> exploitable
[14:59] <dmart> But what if the data is code?  Maybe the caller created a trampoline sequence.  (GCC does this internally for some things)
[15:00] <asac> then it just runs that code?
[15:00] <asac> or is there some protection stuff going on?
[15:00] <dmart> well, you need to synchronise and data and instruction caches and flush the pipeline, so that the code executed is what you wrote.
[15:01] <dmart> This is what the GCC builtin __clear_cache is for (look at the docs)
[15:01] <dmart> ...however, this is not a Thumb-2 specific issue, so we would not expect to need to fix that if it already worked in ARM.
[15:01] <asac> oh cool. so i assume those steps are generated at each "real" function started by gcc?
[15:02] <dmart> Well, the kernel always does this when paging in an executable page
[15:02] <dmart> So for the text sections of programs and libraries, you never need to worry.
[15:03] <dmart> Only self-modifying code or programs which generate code at runtime need to be concerned about this.
[15:03] <asac> ok good info. thanks
[15:03] <asac> ok move on to gmp?
[15:03] <dmart> There certainly were some packages like that in the list...
[15:03] <dmart> still wanted to make one more point:
[15:03] <asac> erlang was marked as "potentially creating code"
[15:03] <asac> sure go ahea
[15:03] <asac> d
[15:04] <dmart> JITs, VMs, interpreters etc. should be treated with extra care for these reasons.
[15:04] <dmart> ...
[15:04] <dmart> anyway, a non-Thumb aware program which generates code an runtime probably generates ARM instruction encodings (not Thumb)
[15:05] <asac> right
[15:06] <dmart> Such packages may need extra attention.  Especially if the generated code may be called by other random (probably Thumb-2) code, or calls out to other functions (also probably Thumb-2) ... it's unlikely to work out of the box
[15:06] <dmart> Anyway, enough on that for now, until we find a real instance ;)
[15:06] <asac> maybe mono ;)
[15:06] <ogra> *shudder*
[15:07] <asac> ok so gmp?
[15:07] <dmart> Going back to the suggestion of how to fix djvulibre
[15:07] <asac> ;)
[15:07] <asac> hehe
[15:07] <asac> endles story it seems
[15:07] <dmart> (I know, nearly finished!)
[15:07] <asac> (but good to have all details first)
[15:07] <dmart> ... we're just trying to jump to a passed function pointer
[15:07]  * persia likes the long explanation, having not much prior understanding
[15:08] <asac> ack
[15:08]  * ogra too
[15:08] <dmart> I thought this would be a good idea --- the wiki page has lots of details, but may not be so easy to understand as an example
[15:09] <dmart> Anyway, BX <register> is definitely the right way to do jump to a function pointer where we don't expect to return.
[15:09] <dmart> So adding a comment to this effect would be a good idea, something like
[15:10] <dmart>  /* instead of "mov pc, <register>", "bx <register>" should be used on ARMv5 and above */
[15:11] <asac> ok let me add that too and upload ... next time i will wait longer ;)
[15:11] <dmart> sorry!
[15:11] <persia> dmart: No need to apologies.  asac is just impatient :)
[15:11] <dmart> I'm sure I can think of something else to add when you're done ;)
[15:12] <dmart> We could add the wiki link for completeness
[15:12] <asac> #ifdef __thumb__
[15:12] <asac> /* instead of "mov pc, <register>", "bx <register>" should be used on ARMv5 and above */
[15:12] <asac> #error "This code needs some porting to work correctly in Thumb: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto"
[15:12] <asac> #endif
[15:12] <asac> thats what i have now ;)
[15:12] <asac> are we happy with that?
[15:12] <dmart> cool, looks good
[15:12] <persia> Seems sufficiently complete.
[15:12] <dmart> Of course, it might have been quicker just to fix it :P  but it helps to educate more people this  way.
[15:13] <asac> itsw really good ... especially since i know that at least persia is eager to work on these things ;)
[15:14] <persia> dmart: The risk with fixing it is that we can't test the code path, so we have no way to know if the "fix" worked.
[15:14]  * dmart spies a volunteer
[15:14]  * persia doesn't really know assembler, and will be slow, but willing
[15:14] <dmart> agreed, it's better not to commit anything we can't test
[15:14] <dmart> only joking
[15:14] <asac> dyfet is definitly a senior volunteer ...
[15:14]  * asac goes with persia 
[15:14] <asac> anyway
[15:15] <asac> so thanks. do we want to look at a second package now?
[15:15] <dmart> Generally best to stay out of assembler as much as possible (it would certainly make this porting job easier)
[15:15] <dmart> Yes, if people want to grab that I'll just fetch a quick cuppa
[15:15] <dyfet> well, in gmp, we have a function return in mpn/arm/copyi/d.asm, and in udiv.asm we find mov pc, lr also...at least to start with :)
[15:17] <JamieBennett> mov's in copyd, udiv and copyi
[15:17]  * JamieBennett goes to get a coffee
[15:18] <ogra> copyd.asm looks like a copy paste job from the wiki :)
[15:18] <dyfet> and copyi.asm...
[15:18] <ogra> yeah, its the same
[15:19] <ogra> all three actually
[15:19] <asac> so who wants to prepare a patch suggestion?
[15:19] <asac> feels like its exactly as on the wiki ;)
[15:20] <dyfet> L(return):
[15:20] <dyfet> #ifdef  __thumb__
[15:20] <dyfet>     bx  lr
[15:20] <dyfet> #else
[15:20] <dyfet>     mov pc, lr
[15:20] <dyfet> #endif
[15:20] <asac> dyfet: on the wiki it uses something else for ifdef
[15:20] <dmart> Hmmm
[15:20] <asac> #ifdef (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
[15:20] <asac> ...
[15:20] <asac> #else
[15:20] <dmart> These are not C files
[15:20] <asac> "bx     lr"
[15:20] <asac> oh right ;)
[15:21] <dmart> Separate assembler files are a bit of a different animal
[15:21] <asac> how annoying
[15:21] <dyfet> Yes, that's right...
[15:21] <ogra> yeah, no ifdef i guess ?
[15:21] <asac> whats the best way to do this if we dont want to do a full copy?
[15:22] <dyfet> well, unless you want to use cpp in front of it, ogra :)
[15:22] <dmart> For assembler files which are preprocessed by the C preprocessor (.S) you can use ifdef in the normal way
[15:22] <dmart> But it looks like these are processed by m4
[15:22] <dmart> So we probably need to get a configure argument passed in somehow
[15:23] <asac> nice
[15:24] <asac> lovely
[15:24] <dyfet> And then use a .ifdef, .else,.endif
[15:24]  * dmart knows nothing about m4
[15:24]  * asac_ had to clone himself
[15:25] <dmart> Assembler macros could work as you suggest
[15:25] <dyfet> L(return):
[15:25] <dyfet> .ifdef  thumb2_config_from_config.m4...
[15:25] <dyfet>     bx  lr
[15:25] <dyfet> .else
[15:25] <dyfet>     mov pc, lr
[15:25] <dyfet> .endif
[15:25] <dyfet>  as a starting point....
[15:25] <dmart> But there are no magic predefined macros in the assembler to tell you what your build target it.
[15:26] <dmart> yep, something like that
[15:26] <dyfet> Yes, so we have to feed it into one of the included files which are generated....
[15:26] <dmart> Or maybe you could have a common macro somewhere else
[15:26] <dmart> .macro return register:req
[15:26] <dmart>         .ifdef <blarg>
[15:26] <dmart>                 bx \reg
[15:26] <dmart>         .else
[15:26] <dmart>         mov pc, \reg
[15:26] <dmart>         .fi
[15:26] <dmart> .endm
[15:27] <dmart> Anyway, that should work
[15:27] <dyfet> that too would be a good idea....
[15:27] <dmart> Exactly how to create the configure argument, I'm not sure
[15:28] <dmart> You could preprocess some C with #ifdefs to check the architecture version and look at the output, e.g.
[15:28] <dyfet> we have to see how config.m4 is created since it includes it...
[15:28] <dmart> #if defined(__ARM_ARCH_4__) || defined(__ARM_ARCH_4T__)
[15:28] <dmart> use_mov
[15:28] <dmart> #else
[15:28] <dmart> use_bx
[15:28] <dmart> #endif
[15:29] <asac_> acinclude.m4
[15:29] <asac_> has GMP_INIT
[15:30] <asac_> i think there are various options ... not sure we should discuss them here
[15:31] <dmart> Agreed, I think everyone understands what's needed.
[15:31] <dmart> Once we've done this once, we can reuse the solution if it's needed again.
[15:31] <dyfet> lets ask this, is there any other porting issue in gmp other than the mov instructions?
[15:31] <dmart> good question --- we should always take a careful look at any assembler which pops up
[15:32] <asac_> "uses mov; also "add" assumes arm"
[15:32] <asac_> thats the comment we had from review
[15:32] <dyfet> yes....thats why I asked :)
[15:32] <asac_> what does add assumes arm mean? dmart ?
[15:32] <dmart> I meant "assumes it's running as ARM instructions and not as Thumb instructions"
[15:33] <asac_> yeah
[15:33] <dmart> There's a bit more info on this on the wiki page at PC and "." arithmetic and position-independent addressing
[15:34] <dmart> But in brief, when you read pc in Thumb, the result is not that same as you'd get if you were executing in ARM.
[15:35] <asac_> ok so we are looking for add.*pc here?
[15:35] <asac_> mpn/arm/invert_limb.asm:	add	r2, pc, #invtab-.-8
[15:35] <dmart> That's the one.
[15:35] <dmart> In ARM, when you read PC, you (usually) get the address of the current instruction + 8
[15:35] <dmart> So this trick gives you the address invtab in r2
[15:36] <asac_> right
[15:36] <asac_> whats the right way to find a good offset?
[15:36] <dmart> But in Thumb, pc is different.  You get <address of current instruction> + 2 or 4 (depending on the alignment of the instruction in memory)
[15:37] <dmart> It is possible to work out the correct offset, but ugly
[15:37] <dmart> ...and you need #ifdefs or other special cases hacks for ARM versus Thumb
[15:37] <dmart> ...
[15:37] <dmart> Fortunately, the assmbler can do it for you
[15:38] <dmart> There's a special pseudo-op to get the address of a nearby label in the text section:
[15:38] <dmart>         adr <reg>, <label>
[15:38] <dmart> The assembler actually assembles
[15:38] <asac_> yeah ... finally found it on porting page ;)
[15:39] <dmart>         add (or sub) <reg>, pc, #<magically determined offset>
[15:39] <asac_> so we use adr r2, #invtab ?
[15:39] <dmart> It's not usual to have the # (it might be a syntax error)
[15:39] <dmart> but otherwise, that's correct
[15:40] <dyfet> yes...and no conditional...
[15:40] <dmart> This is a really old assembler feature, so it ought to be possible to make the change and upstream it as-is
[15:40] <dmart> ...
[15:40] <asac_> so adr would work on arm too?
[15:41] <asac_> feels like
[15:41] <dmart> Yes, the only thing that changes is how the offset is worked out
[15:41] <dmart> A couple of things to watch out for:
[15:42] <dmart> add <reg>, pc, #label - . - 8 is a special case which maps directly to addr
[15:42] <dmart> If the code actually tries to skip the first word after label, e.g.
[15:42] <dmart> add <reg>, pc, #label - . - 4
[15:42] <dmart> ...you'd need to take this into account:
[15:42] <dmart> adr <reg>, label + 4
[15:43] <dmart> But really, the best thing to do is to create another explicit label in the right place and reference that directly.  It's harder to break, that way.
[15:45] <asac_> ok
[15:45] <dmart> ...
[15:45] <asac_> so here we have:
[15:45] <asac_> add     r2, pc, #invtab-.-8
[15:45] <asac_> invtab is a label with short data stuff
[15:46] <asac_> so after that we have the address of the invtab first short in r2?
[15:46] <asac_> or is that not what its supposed to do?
[15:47] <dmart> Yes, I think it wants the address of the first short (i.e., the address of the label invtab) in r2
[15:47] <dmart> (the previous point I made doesn't apply here, but might apply elsewhere)
[15:47] <asac_> so given we already have a label ... just adr r2, #invtab feels ok
[15:47] <asac_> but you said its rather adr r2, invtab ?
[15:48] <dmart> yes, that should work
[15:48] <asac_> what does #invtab mean? maybe it means "relative"
[15:48] <asac_> ß
[15:48] <asac_> ?
[15:48] <asac_> e.g. you add the relative distance of that label to what is currently on pc
[15:48] <asac_>  - 8
[15:49] <dmart> # is just required syntax in some cases, generally before a numeric constant.  Best not to think about it actually meaning something.
[15:49] <asac_> oh right. now i remember about the constant
[15:50] <dmart> ...
[15:50] <dmart> A point to make about out-of-line assembler files
[15:50] <dmart> as does not default to assembling Thumb code
[15:50] <dmart> So this code will be assembled as ARM
[15:50]  * asac back here
[15:51] <dmart> ...
[15:52] <asac> hmm. so you say its all ok? or we should fix the build system to use thumb2?
[15:52] <dmart> It's actually fine for bits of ARM code to exist, so long as they return in the right way (this is what we were talking about earlier), and so long at they are called in the right way.
[15:52] <persia> Is there a reason we shouldn't change the default?
[15:52] <dmart> persia: we did investiate, but changing the default is not really supported and breaks too much stuff
[15:53] <dmart> In any case, Thumb-2 helps to reduce code size, and that's a bit different from speed optimisations.
[15:54] <dmart> If we only built 90% of the codebase in Thumb, that would still give us most of the overall code size benefit.
[15:54] <asac> right
[15:54] <persia> Makes sense.
[15:54] <dmart> So "if it's not broke, don't fix it" is probably the best policy
[15:54] <asac> ok ;)
[15:55] <dmart> ...
[15:55] <asac> so we can scratch most code that is in ssembler
[15:55] <dmart> yes and no
[15:55] <dmart> We still need to be a bit vigilant in places, depending on how the code is used.
[15:56] <dmart> Suppose we had some assembler code which accepted the address of a callback as one of its arguments?  The callback might be the address of a Thumb-2 function
[15:57] <dmart> Similarly we need to return to the caller in the right way (using bx)
[15:58] <dmart> In this case, these look like leaf functions which are called from C (and don't call any other functions), so we just need to make sure the return is correct
[15:58] <asac> ok that makes some sense indeed
[15:58] <dmart> This is why we particularly grepped the archive for things like mov pc, <something>
[15:59] <dmart> This is the classic way to do the equivalent of calling a function via a pointer in C.
[15:59] <asac> yeah
[16:00] <asac> so i dont see this asm snippet returning
[16:00] <dmart> Which bit?
[16:00] <asac> mpn/arm/invert_limb.asm
[16:00] <asac> well. i dont see how to check if it returns properly according to what you have said
[16:01] <dmart> ...
[16:01] <dmart> Ah, good point -- I should explain this one
[16:01] <dmart> ...
[16:01] <dmart> To jump to a value in a register, you can use mov pc, <register>, or preferably bx <register>
[16:02] <asac> yes. thats what happens on the caller side i guess
[16:02] <dmart> Could be, though there's a special procedure call instruction BL <label> (branch with link) which is more likely to be used in that case, as long as the location of the label is known at compile time (usually)
[16:03] <asac> ok. so do we jump back ;)?
[16:03] <dmart> It magically sets the link register (lr) to the correct return address
[16:03] <dmart> ...
[16:03] <asac> ah
[16:03] <dmart> So what happens to that in this function?
[16:04] <dmart> It gets saved on the stack at the beginning:
[16:04] <dmart>                 stmfd   sp!, {r4, lr}
[16:05] <dmart> "STore Multiple Fully Descending {r4 and lr} at sp and update sp"
[16:05] <dmart> On x86 we would say "push"
[16:05] <asac> ok so we have the lr on stack
[16:05] <dmart> ...
[16:05] <asac> and then we jump back like:
[16:05] <asac> ldmfd   sp!, {r4, pc}
[16:05] <asac> ;)
[16:06] <dmart> Indeed, this is the "pop", and we can restore the pc at the same time to get back where we started.
[16:06] <asac> what is r4 used for?
[16:06] <dmart> You might wonder why we don't need to change this to support thumb, whereas the other cases needed a BX
[16:07] <ogra> yes, i was wondering that
[16:07] <dyfet> yes...me too
[16:07] <dmart> On ARMv4T (the earliest version of Thumb), this was indeed necesary.  You had to:
[16:07] <dmart>       pop {r4}
[16:07] <dmart>       pop {r0}
[16:08] <dmart>       bx r0
[16:08] <dmart> (or something like that)
[16:08] <dmart> ...because BX was the only way to switch instruction set
[16:09] <dmart> ...However we don't need to worry about this: from ARMv5 onwards, all the "load pc from memory" instructions switch instruction set as needed, provided that the bottom bit of the return address was set to the right thing.
[16:09] <asac> nice
[16:09] <dmart> So as long as the call side was done right, we're OK
[16:09] <asac> can you explain to me why r4 is involved at all in these things?
[16:09] <asac> stmfd   sp!, {r4, lr} -> ldmfd   sp!, {r4, pc} ?
[16:10] <asac> i would think that its just sp + lr ... and then sp -> pc
[16:10] <dmart> r4 is saved because it's used in the function
[16:10] <dmart> The procedure call standard required you to restore some registers if you change them
[16:11] <dmart> gcc assumes you play nice when generating the code for C functions
[16:11] <asac> oh ... now i see
[16:11] <asac> btw, whats a good arm asm reference?
[16:11] <dmart> Generally, only the first argument of an instruction is modified, so you might expect to see r4 at the start of some instructions, but there is none.
[16:11] <asac> some handy online resource would be great ; )
[16:12] <dmart> Oh, I tell a lie, there is         addcs   r4, r4, #1
[16:12] <dmart> (looks up a documentation link)
[16:12] <asac> addcs   r4, r4, #
[16:12] <asac> rigt
[16:12] <asac> ;)
[16:12] <asac> anyway. i guess there is a special instruction that also modifies r4?
[16:12] <asac> otherwise you wouldnt have started like it ;)
[16:13] <dmart> Yes, I was trying to be clever...
[16:13] <dmart> umull ("Unsigned MULtiply Long") produces a 64-bit result, and so it has two output arguments:
[16:13] <dmart>         umull   lr, r4, ip, d
[16:14] <dmart> bah, our documentation portal seems to be down, but I'll post a link to the ABI docs when I have it
[16:14] <dmart> In brief though:
[16:15] <dmart> If you clobber r4-r11 you need to restore them (and obviously sp needs to be the same as it started off to balance the stack)
[16:15] <dmart> ...
[16:15] <asac> yeah
[16:16] <dmart> Nowadays the stack is supposed to be kept 64-bit aligned, so you might want to check for pushing odd numbers of registers.
[16:16] <dmart> In fact, new code may uselessly save an extra register to achieve this:
[16:16] <asac> registers are 32?
[16:16] <dmart> yes
[16:16] <asac> or different?
[16:16] <asac> ok
[16:16] <dmart> This is only required if you call other functions
[16:17] <dmart> Basically, gcc is allowed to assume that the stack is 64-bit aligned at the entry of every function, and ensures that this is still true when calling functions.
[16:17] <dmart> Is assmbler code, you need to be careful not to mess up this assumption.
[16:18] <dmart> ...
[16:18] <dmart> Final point: is the assmbler code used at all?
[16:18] <dmart> (should have asked this at the beginning ;))
[16:21]  * dmart touches those files and rebuilds
[16:21] <dmart> OK, it looks like that code is used
[16:21] <asac> gmp-impl.h:    (invxl) = mpn_invert_limb (xl);     \
[16:22] <dmart> I wondered if this was ancient optimised code which is no longer used (and a C implementation might have been used instead)
[16:22] <dmart> This is the case in some of the packages on our list (like zip where there's some old code that was written for RiscOS)
[16:22] <asac> i dont see an alterantive impl for that
[16:22] <asac> i would assume its used ;)
[16:23] <asac> so ok. for gmp we have two things:
[16:23] <asac> 1. fix mov in the .asm files (special casing using m4)
[16:24] <asac> 2. fix the invert_limb thing to use adr rather than add
[16:24] <asac> oh
[16:24] <asac> 2. only if we build with thumb
[16:24] <asac> i think we said we are ok to keep it "arm"
[16:25] <dmart> That's true, though since we've spotted it it might be worth fixing anyway, since it's cleaner and won't trap someone trying to migrate this code to Thumb-2.
[16:25] <dmart> But I'm happy either way.  If we don't fix it we could still add a comment.
[16:26] <asac> right. so on top of 2. we need to switch the AS to thumb mode
[16:26] <asac> how is that done?
[16:26] <dmart> My recommendation is: don't bother
[16:26] <asac> ok -mthumb
[16:26] <asac> hmm
[16:26] <asac> dmart: so fix it, but dont switch?
[16:27] <dmart> We could, of course, if it turns out to be easy
[16:27] <asac> right. lets first fix code. and then see if we can switch as easily
[16:27] <asac> if not, leave it alone
[16:28] <asac> since dyfet seemed to be fluent on the m4 stuff i will assign the bug to him ;)
[16:28]  * lool attacked the qemu-kvm armel ftbfs
[16:28] <dyfet> Okay
[16:29] <dmart> If you really want the assembler in Thumb, you need to use assembler directives in the files.
[16:29] <asac> ok updated bug
[16:29] <dmart> -mthumb doesn't really do what we want in this case (as interprets the code as Thumb-1, which means most code written for arm will fail to build anyway)
[16:30] <dmart> I'll try to add some details about this on the wiki
[16:30] <asac> ok thanks
[16:30] <dyfet> in this case we are concerned more with performance than size
[16:30] <asac> ack
[16:31] <asac> but having all thumb2 ready would be nice
[16:31] <dmart> Or ftbfs -> crash -> performance -> size
[16:31] <asac> ok. so we didnt get much done, but i think it was a good start
[16:31] <asac> thanks dmart ;)
[16:32] <asac> i would like to take a break before the call we have in 30
[16:32] <ogra> phew ...
[16:32] <dmart> sure
[16:32] <asac> feel free to continue though
[16:32] <asac> i think ogra dyfet and co are happy ;)
[16:32] <dmart> I think we did enough for today - it was really just to introduce people to the issues
[16:32] <asac> yeah
[16:32] <dmart> I'll try to hang around on IRC, so if in doubt please ask :)
[16:32] <asac> i think it made sure we we are all getting started
[16:32] <dyfet> asac: I have to deal witht the furnace people for a little bit, but yes, I think it was an excellent start
[16:33]  * ogra notices that there are not many leftovers of the asm he once learned a decade or more ago :/
[16:33] <dmart> cool
[16:33] <asac> dyfet: ogra: persia: StevenK: maybe read the porting wiki carefully to get more detailed info. should be easier to read now we got the intro ;)
[16:33] <dmart> ogra: Sort of; more that there's a lot of new stuff though
[16:34] <dmart> comments welcome - it's not 100% complete and was written in a hurry
[16:34] <dmart> I will dump the log of this conversation on the wiki (in advance of tidying it up)
[16:34] <asac> good idea
[16:35] <ogra> lool, can you reestore the topic ?
[16:36] <dmart> thanks everyone
[16:37] <ogra> thanks a lot dmart !
[16:38] <dmart> I'll talk to asac offline about arranging another sprint sometime soon - then people could have a go at porting packages and we can discuss together as needed.
[16:38] <persia> I was just taking a look at insighttoolkit as a potential task, as there's a number of rdeps and rbuilddeps.  It seems to use "mov pctemp, eax" : am I correct that this is a likely false positive hit?
[16:39]  * lool passed   CC    arm-softmmu/exec.o
[16:39] <persia> (because it doesn't seem to be branching with that instruction)
[16:39] <lool> \o/
[16:39] <persia> lool: Nice!
[16:39] <lool> ogra: Is the sprint over?
[16:39] <ogra> lool, congrats !
[16:39] <ogra> yes, it is
[16:39] <dmart> lool: yes, we'll wrap up for now
=== lool changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2
[16:40]  * dmart wonders how to alert everyone on the channel
[16:40] <persia> dmart: alert them to what?
[16:40] <dmart> End of the session.
[16:40] <dmart> I guess changing the topic works OK
[16:40] <persia>  /topic changes are usually sufficient, yes.
[16:40] <dmart> fair enough
[16:41]  * lool channel-wide alert
[16:41] <ogra> heh
[16:41] <dmart> ;)
[16:42] <lool> dmart: Mind taking a look at http://paste.ubuntu.com/374082/?
[16:42] <lool> I built arm-softmmu/qemu-system-arm under armel successfully with it
[16:42]  * lool now attacks a full build
[16:42] <dmart> persia: your mov pctemp, eax in insighttoolkit is almost certainly a false positive.  ARM and x86 both have a "MOV" instruction, but eax is an x86 register name (arm reg names are always two letters, or r<number>)
[16:43] <dmart> lool: what package it that? qemu?
[16:43] <lool> dmart: qemu-kvm, but this patch is against qemu tip
[16:43] <dmart> oh, right
[16:43] <persia> dmart: Thanks for the confirmation.
[16:43]  * persia goes to look for something else
[16:44] <dmart> lool, so spin_lock makes use of testandset ?
[16:45] <lool> dmart: Yes
[16:45] <dmart> Looks sensible to me... I guess the code is already tested on other SMP arches
[16:46] <dmart> lool, should the typedef for spinlock_t be volatile int?
[16:46] <lool> I just tested building, and then only on armel; I think I'm going to apply it to lucid's qemu-kvm and if that works ok, I will submit it upstream
[16:47] <lool> dmart: The other typedefs aren't, but I tend to agree that it would be a good idea
[16:47] <dmart> I think the GCC atomics do the necessary, but I guess it won't hurt to make it volatile
[16:47]  * ogra would actually like to see someone running qemu-system-arm under armel ... heh
[16:48] <lool> dmart: It doesn't make any difference in practice because these are only written to once to init them
[16:48] <lool> e.g. spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;
[16:48] <dmart> The atomics write them, but it probably doesn't have to be volatile for that to work
[16:49] <dmart> http://www.google.com/search?q=itanium+abi+atomic
[16:49] <lool> Ack; I'll submit this as a separate patch when I upstream gcc atomics
[16:49] <dmart> OK
[16:49] <lool> Hopefully it wont take another two months   :-/
[16:51] <dmart> For anyone still listening, the procedure call standard and other ABI docs for ARM can be found on
[16:51] <dmart> http://infocenter.arm.com/
[16:52] <dmart> Browse to RealView software development tools -> Application Binary Interface -> Procedure Call Standard for the ARM Architecture (etc.)
[16:55] <persia> Only saeed left :)
[16:56] <persia> So, the next one I picked (lwp) seems to only have "mov pc, r0" in a .S file.  We decided to leave those alone, because they are going to end up as armel instructions anyway, right?
[17:04] <lool> I have a funny error
[17:05] <lool> /home/ubuntu/qemu/qemu-kvm-0.12.2/fpu/softfloat-native.c:373: error: impossible constraint in 'asm'
[17:05] <lool> The code is: http://paste.ubuntu.com/374093/
[17:07] <persia> And float_relation_* are essentially constants?
[17:09] <lool> I guess
[17:10] <lool> It's technically possible to reach float_relation_unordered for some float numbers such as nan
[17:10] <ogra> lool, btw, i think amitk said ppoll pselect are upstream now
[17:10] <ogra> (in mainline)
[17:10] <lool> Indeed
[17:11] <lool> and I'm adding a patch to stop them from barking
[17:11] <lool> I wonder whether we should just backport this stuff instead
[17:11] <ogra> just quieting it or implementing them ?
[17:11]  * ogra doesnt mid either since there is a properl fallback in libc afaik
[17:12] <ogra> (referring to your patch)
[17:12] <lool> It's just very noisy right now
[17:12] <ogra> yep, i rarely see that, rootstock hides such stuff
[17:13] <ogra> but in chroot tests its annoying, i agree
[17:21] <lool> It's not trivial to backport the pselect6() impl
[17:21] <lool> It depends on at least two other commits
[17:29] <lool> git cherry-pick is broken for me for some reason
[17:31] <lool> In fact git is completely borken hmm
[17:36] <ogra> use bzr ... i always told you :)
[17:36]  * ogra hides
=== jds is now known as Hoonse
[17:37] <Hoonse> i am back =)
[17:37] <Hoonse> hi guys
[17:40] <lool> wow
[17:40] <lool> I'm failing at backporting it because *it's already in*
[17:40] <ogra> heh
[17:50] <lool> Does someone have a rough idea of how long it takes to boot dove lucid?
[17:52]  * ogra can only give numbers for imx
[17:52] <ogra> its roughly after 40sec at the full desktop
[17:52] <ogra> (netbook-desktop that is)
[18:00] <Hoonse> i think i will make the rootfs new... what do i have to add to --seed when i want the gnome gui and not the xfce4?
[18:03] <ogra> Hoonse, depends, full ubuntu would be ubuntu-desktop
[18:03] <ogra> i think an upstream plain gnome flavour was only added in karmic
[18:03] <siji> hi ogra,
[18:03] <ogra> that would be gnome-staciatella then iirc
[18:04] <Hoonse> thanks.... ok this will be a long time AGAIN for waiting till the script is finished =)
[18:04] <ogra> well, upgrade your host to karmic ;) its way faster
[18:04] <Hoonse> for what projects do you all use the BeagleBoard?
[18:04]  * ogra doesnt use a beagle ... its collecting dust on the shelf
[18:05] <Hoonse> but you bought it for a reason? or just for the reason to collect dust =)
[18:06] <ogra> i got it handed by somebody
[18:07] <Hoonse> well i think this is an awesome piece of hardware...  the best since the microkopter project...
[18:09] <ogra> it is ...
[18:25] <Hoonse> orga: guess what... today i also installed the wireless-tools and the network-manager... =)
[18:27] <armin76> quick
[18:32] <persia> Hoonse: So everything is working for you now?
[18:32] <persia> armin76: ?
[18:40] <lool> suihkulokki: I'm looking at linux-user/syscall.c, and see I'd need to add some copy_from_user_timespec and to_user and pselect would very much be like select; I find macros would be a bit long and ugly, and real functions would add a small performance penalty, do you see a way we could share the code yet keep it readable and fast?
[18:51] <lool> suihkulokki: Also, is it ok to unconditionally use the hosts' pselect or do I have to check whether it's available and support arches where it's not?
[18:51] <zumbi> lool: is this croco?
[19:00] <lool> zumbi: It's just qemu-linux-user
[19:00] <lool> Not specific to croco
[19:01] <lool> croco rocks, I need to resume working on its integration
[19:01] <lool> Just haven't taken the time
[19:03] <zumbi> yes :-)
[19:03] <zumbi> it rocks! time is always the problem
[19:20] <Meizirkki> Hi all
[19:21] <Meizirkki> Is the Karmi ffmpeg NEON accelerated?
[19:21] <Meizirkki> Karmic*
[19:22] <Meizirkki> Or is there a specific ppa for it ?
[19:23] <armin76> Meizirkki: its not
[19:23] <Meizirkki> I heard there was ppa with NEON accelerated ffmpeg somewhere ..?
[19:24] <jds> is there a special command line "sentence" for autologin on ubuntu (no username and password type in)
=== jds is now known as Hoonse
[19:25] <persia> Hoonse: Depends on the desktop environment, but there's usually a way to select autologin from the greeter control tool.
[19:26] <Hoonse> xfce4 is the desktop enviroment...
[19:26] <Meizirkki> NCommande, were you dealing neon wccelerated ffmpeg ?
[19:27] <Hoonse> oh sh.. it seems that the network-manager isnt happy with my WEP key...
=== bjf is now known as bjf-afk
[19:33] <Meizirkki> lool ?
[19:34] <Meizirkki> did you have the ppa containing ffmpeg w/ neon optimizations?
[19:48] <Meizirkki> armin76, does the lucid version have neon acceleration ?
[19:52] <armin76> Meizirkki: ubuntu doesn't nor will use neon afaik
[19:54] <Meizirkki> ok, thanks
[20:03] <Hoonse> is it normal that network manager takes reeeaaallllyyy long to connect to a wifi network and a few times shows up the question about the wep key when always entered?!?
[20:09] <Hoonse> omg this sucks... -.-
[20:56] <lool> asac: oo.o works again on armel??
[20:57] <lool> When was that fixed?
[20:59] <lool> ogra: Do you know?  ^
[21:01] <ogra> lool, it still carries the hack
[21:06] <lool> ogra: thanks for confirming
[21:06] <ogra> welcome
[21:17] <lool> You guys have any recent bootchart on armel hardware?
[21:17] <ogra> http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png netbook launcher is up after ~40sec
[21:18] <ogra> well, visible after about 35
[21:18] <ogra> disregard the panel and stuff, there are applets missing so its starting delayed atm popping up errors
[21:21] <lool> thanks
[21:21] <lool> ogra: that's with SD?  or SATA rotational hard disk?
[21:21] <ogra> SATA
[21:21] <ogra> rotational
[21:29] <amitk> ogra: ppoll is upstream in 2.6.32
[21:32] <NCommander> armin76: ping. Is OOo known to work on Gentoo with ARMv6/ARMv7 optimizations?
[21:36] <suihkulokki> lool, huh?
[21:36] <suihkulokki> NCommander: do you plan to fix OOo build on gcc 4.4?
[21:36] <ogra> suihkulokki, he does :)
[21:36] <NCommander> suihkulokki: I'm going to take a stab at it :-)
[21:36] <lool> suihkulokki: Sorry, context was implementing pselect in qemu/linux-user
[21:37] <NCommander> suihkulokki: I fixed thunderbird. This codebase can't be much worse
[21:37]  * NCommander feels like those might be famous last words
[21:37] <ogra> NCommander, its just way bigger  ... and the issue is in uno
[21:38] <NCommander> ogra: right, I'm reading through the channel logs from that era to remember the detials
[21:38] <NCommander> *details
[21:38] <suihkulokki> lool, unconditional should be ok, the kernel will just give a err if not supported
[21:39] <ogra> well, it should be supported across the board now
[21:39] <lool> Ok; I was wondering whether it was ok to require recent linux-headers
[21:39] <lool> but pselect is old indeed
[21:39] <lool> some platforms might not have it, I wonder whether it's in the headers in this case
[21:39] <suihkulokki> NCommander: I think OOo is worse ;) good luck, that fix would be appreceated.
[21:39] <ogra> ++
[21:40] <NCommander> suihkulokki: I assume its also broken in Debian?
[21:40] <lool> Yes
[21:40] <NCommander> suihkulokki: does building with gcc 4.3 fix the issue? (just for a reference point)
[21:40] <ogra> NCommander, yes
[21:41] <suihkulokki> NCommander: yes. iirc it was a binutils rather than gcc issue
[21:41] <ogra> its clearly a toolcahin issue
[21:41] <NCommander> ogra: right, I'm just getting up to speed. I was working on Thunderbird during most of the OOo fun
[21:43] <lool> As I personally recall, we realized that downgrading both binutils and gcc helped, but when we bisected binutils we found another bug which ended up not fixing oo.o
[21:44] <lool> ogra: well it could be an oo.o issue too
[21:44] <lool> oo.o is using some quite special toolchain API and has a copy of some unwind headers stuff, it's really an awfully complex piece of code
[21:44] <ogra> lool, i doubt it, but it could be indeed
[21:45] <lool> ogra: The code which crashes in openoffice is the one converting C stacks to uno stacks
[21:45] <lool> so it's very low-level stuff
[21:45] <ogra> yeah
[21:45] <lool> Anyway we'll see
[21:45] <suihkulokki> iirc the toolchain people were suggesting it is OOo issue
[21:46] <suihkulokki> it was mentioned on debian list
[21:46] <NCommander> suihkulokki: debian-arm?
[21:46] <lool> I think so as well
[21:46]  * NCommander probably should subscribe to that :-)
[21:46] <lool> It might be that oo.o has to be updated in lockstep with some very deep toolchain API
[21:47] <suihkulokki>  NCommander that or debian-release
[21:48] <ogra> NCommander, you should definately be on debian-arm (and if its only for seeing the shiny new netbook stuff they are discussing there :) )
[21:49] <NCommander> ogra: I was on d-arm, I think I accidenlty unsubscribed myself when I purged out mailing lists I didn't read anymore
[21:49] <asac> NCommander: your call ;)