I made a patch for ltrace that adds support for Thumb-2. There's not much to it, but it allows me to trace applications built for Cortex-A8. Without it, users will experience this bug:
https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/639796
Unfortunately, it appears that the upstream tree is not well-maintained. I posted it to the mailing list for the project, but others' patches have been ignored for many months. However, my post precipitated another contributor to offer to maintain the package.
I also posted this patch as the proposed solution for the above LP bug, which should allow Linaro to benefit from the work without worrying about upstream. In fact, a new version of the package appears to have been released that includes my patch (0.5.3-2ubuntu6). Please give this updated package a whirl and let me know if there is more work to be done.
Thoughts? Unless I hear feedback from others, I will assume that this tool now works for Cortex-A[89] and move on to other tasks.
On 10/04/2010 12:05 PM, Zach Welch wrote:
I made a patch for ltrace that adds support for Thumb-2. There's not much to it, but it allows me to trace applications built for Cortex-A8. Without it, users will experience this bug:
https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/639796
Unfortunately, it appears that the upstream tree is not well-maintained. I posted it to the mailing list for the project, but others' patches have been ignored for many months. However, my post precipitated another contributor to offer to maintain the package.
I also posted this patch as the proposed solution for the above LP bug, which should allow Linaro to benefit from the work without worrying about upstream. In fact, a new version of the package appears to have been released that includes my patch (0.5.3-2ubuntu6). Please give this updated package a whirl and let me know if there is more work to be done.
Thoughts? Unless I hear feedback from others, I will assume that this tool now works for Cortex-A[89] and move on to other tasks.
The patch looks fine to me. IIRC, there is a testsuite in ltrace. Do we want to add a testcase for this bug? It is good if we can run ltrace testsuite.
On Mon, Oct 4, 2010 at 10:26 PM, Yao Qi yao.qi@linaro.org wrote:
On 10/04/2010 12:05 PM, Zach Welch wrote:
I made a patch for ltrace that adds support for Thumb-2. There's not much to it, but it allows me to trace applications built for Cortex-A8. Without it, users will experience this bug:
https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/639796
Unfortunately, it appears that the upstream tree is not well-maintained. I posted it to the mailing list for the project, but others' patches have been ignored for many months. However, my post precipitated another contributor to offer to maintain the package.
I also posted this patch as the proposed solution for the above LP bug, which should allow Linaro to benefit from the work without worrying about upstream. In fact, a new version of the package appears to have been released that includes my patch (0.5.3-2ubuntu6). Please give this updated package a whirl and let me know if there is more work to be done.
Thoughts? Unless I hear feedback from others, I will assume that this tool now works for Cortex-A[89] and move on to other tasks.
The patch looks fine to me. IIRC, there is a testsuite in ltrace. Do we want to add a testcase for this bug? It is good if we can run ltrace testsuite.
Hi Zach. I'd like to give the Secondary Projects idea[1] a spin on this. The goal is to make any improvements we've done available early and then be superseded by upstream in the future. This is especially relevant when upstream is quiet like with ltrace.
Could you please: * Mention the idea to upstream to see if anyone disagrees * See if anyone upstream has other ARM or x86 patches to include * Test under ARM Thumb-2, i686, and x86_64 * Spin a tarball to go out with the 2010.11 release.
Ubuntu has already picked up your change so there's no need for binary builds. Please spend some time on the testsuite to see how ARM and x86 compare and to make sure the suite runs as part of the Ubuntu build.
Give me a yell on IRC or email if you need any help,
-- Michael [1] https://wiki.linaro.org/WorkingGroups/ToolChain
On Tue, Oct 05, 2010, Michael Hope wrote:
Could you please:
- Mention the idea to upstream to see if anyone disagrees
- See if anyone upstream has other ARM or x86 patches to include
- Test under ARM Thumb-2, i686, and x86_64
- Spin a tarball to go out with the 2010.11 release.
NB: If we spin a tarball which is more than an upstream snapshot (e.g. we include patches from the mailing-list), we should rename it (for instance "ltrace-linaro")
Ubuntu has already picked up your change so there's no need for binary builds. Please spend some time on the testsuite to see how ARM and x86 compare and to make sure the suite runs as part of the Ubuntu build.
We could provide backports of the fixed package to lucid for instance
I wonder whether we should start some list of target distros for which we build binaries like this one, or valgrind or qemu or simply the toolchain
On Wed, Oct 6, 2010 at 12:20 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Oct 05, 2010, Michael Hope wrote:
Could you please: * Mention the idea to upstream to see if anyone disagrees * See if anyone upstream has other ARM or x86 patches to include * Test under ARM Thumb-2, i686, and x86_64 * Spin a tarball to go out with the 2010.11 release.
NB: If we spin a tarball which is more than an upstream snapshot (e.g. we include patches from the mailing-list), we should rename it (for instance "ltrace-linaro")
Hmm. There's a conflict there. One requirement is to be 'traceable back to the upstream version'. If we pick up random patches then that is hard and calling it ltrace-linaro makes sense. However, we also want later upstream ltrace release to automatically obsolete ours.
If we release a 'ltrace-linaro', which turns into the Ubuntu package 'ltrace-linaro', can it be superseded by a later 'ltrace' release?
I wonder whether we should start some list of target distros for which we build binaries like this one, or valgrind or qemu or simply the toolchain
I'm talking about similar things with Steve Langaseck. My minimum is GCC and GDB native and cross on Ubuntu Lucid. Past that would be Fedora, then openSUSE, then Windows 7. I'd like the Ubuntu packages to actually be Debian packages that work well with Ubuntu.
-- Michael
On 10/05/2010 01:56 PM, Michael Hope wrote:
On Wed, Oct 6, 2010 at 12:20 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Oct 05, 2010, Michael Hope wrote:
Could you please:
- Mention the idea to upstream to see if anyone disagrees
- See if anyone upstream has other ARM or x86 patches to include
- Test under ARM Thumb-2, i686, and x86_64
- Spin a tarball to go out with the 2010.11 release.
NB: If we spin a tarball which is more than an upstream snapshot (e.g. we include patches from the mailing-list), we should rename it (for instance "ltrace-linaro")
Hmm. There's a conflict there. One requirement is to be 'traceable back to the upstream version'. If we pick up random patches then that is hard and calling it ltrace-linaro makes sense. However, we also want later upstream ltrace release to automatically obsolete ours.
If we release a 'ltrace-linaro', which turns into the Ubuntu package 'ltrace-linaro', can it be superseded by a later 'ltrace' release?
Personally, I think the simplest/best solution will be to encourage upstream to release a new version. At the very least, I would like to see all of the needed patches make it into an official upstream Git tree, which presently seems unlikely to happen soon without some help. Certainly, I believe that Linaro should avoid maintaining this type of secondary project indefinitely, and that is exactly what I see happening unless something changes with the upstream project.
I sent an e-mail to the ltrace-devel list today to encourage one of the recent contributors to begin preparing a new tree for the purposes of release, as he has been waiting patiently for almost a year in the hope that the maintainer will reappear and handle that task. There are literally dozens of patches that basically have been ignored during the past year which I think deserve to be committed, so I also directly encouraged the ltrace community to consider adopting a new maintainer and begin moving forward again. At the very least, I have turned the situation into a fire for the current maintainer that can't be ignored.
Meanwhile, I have been trying to determine why I am getting lots of segfaults when running the test suite on an ARM test machine. On the upside, the x86 test suite works fine after a couple of the outstanding patches were applied to my tree, but they didn't solve the problems that I am seeing on ARM. I will continue to investigate these issues and brace myself for the possibility that I might need to spin a Linaro release.
I wonder whether we should start some list of target distros for which we build binaries like this one, or valgrind or qemu or simply the toolchain
I'm talking about similar things with Steve Langaseck. My minimum is GCC and GDB native and cross on Ubuntu Lucid. Past that would be Fedora, then openSUSE, then Windows 7. I'd like the Ubuntu packages to actually be Debian packages that work well with Ubuntu.
I presume this will all be readily automated?
On Wed, Oct 6, 2010 at 11:33 AM, Zach Welch zwelch@codesourcery.com wrote:
On 10/05/2010 01:56 PM, Michael Hope wrote:
On Wed, Oct 6, 2010 at 12:20 AM, Loďc Minier loic.minier@linaro.org wrote:
On Tue, Oct 05, 2010, Michael Hope wrote:
Could you please: * Mention the idea to upstream to see if anyone disagrees * See if anyone upstream has other ARM or x86 patches to include * Test under ARM Thumb-2, i686, and x86_64 * Spin a tarball to go out with the 2010.11 release.
NB: If we spin a tarball which is more than an upstream snapshot (e.g. we include patches from the mailing-list), we should rename it (for instance "ltrace-linaro")
Hmm. There's a conflict there. One requirement is to be 'traceable back to the upstream version'. If we pick up random patches then that is hard and calling it ltrace-linaro makes sense. However, we also want later upstream ltrace release to automatically obsolete ours.
If we release a 'ltrace-linaro', which turns into the Ubuntu package 'ltrace-linaro', can it be superseded by a later 'ltrace' release?
Personally, I think the simplest/best solution will be to encourage upstream to release a new version. At the very least, I would like to see all of the needed patches make it into an official upstream Git tree, which presently seems unlikely to happen soon without some help. Certainly, I believe that Linaro should avoid maintaining this type of secondary project indefinitely, and that is exactly what I see happening unless something changes with the upstream project.
Agreed. We have members specifically asking for ltrace so if upstream dont't react in a reasonable time frame then we'll have to. Note that Linaro secondary projects are not maintained but may be useful to others.
I sent an e-mail to the ltrace-devel list today to encourage one of the recent contributors to begin preparing a new tree for the purposes of release, as he has been waiting patiently for almost a year in the hope that the maintainer will reappear and handle that task. There are literally dozens of patches that basically have been ignored during the past year which I think deserve to be committed, so I also directly encouraged the ltrace community to consider adopting a new maintainer and begin moving forward again. At the very least, I have turned the situation into a fire for the current maintainer that can't be ignored.
I'm happy for you to spend up to a man-week helping upstream with this process.
Meanwhile, I have been trying to determine why I am getting lots of segfaults when running the test suite on an ARM test machine. On the upside, the x86 test suite works fine after a couple of the outstanding patches were applied to my tree, but they didn't solve the problems that I am seeing on ARM. I will continue to investigate these issues and brace myself for the possibility that I might need to spin a Linaro release.
Good, thanks.
-- Michael
On Tue, Oct 05, 2010, Zach Welch wrote:
Personally, I think the simplest/best solution will be to encourage upstream to release a new version.
Fully agreed! (I think we're only having this conversation because of the feedback that upstream didn't seem to be around anymore)
On 10/05/2010 04:10 PM, Loïc Minier wrote:
On Tue, Oct 05, 2010, Zach Welch wrote:
Personally, I think the simplest/best solution will be to encourage upstream to release a new version.
Fully agreed! (I think we're only having this conversation because of the feedback that upstream didn't seem to be around anymore)
With open source, an upstream always exists: just make a new fork. Indeed, I see that as a possible outcome with ltrace; however, I hope the original author will surface long enough to pass the reigns gracefully.
On Wed, Oct 06, 2010, Michael Hope wrote:
Hmm. There's a conflict there. One requirement is to be 'traceable back to the upstream version'. If we pick up random patches then that is hard and calling it ltrace-linaro makes sense. However, we also want later upstream ltrace release to automatically obsolete ours.
That's fair; I guess changing just the upstream version to carry linaro, e.g. 0.5.3+linaro1, would work.
It might be easier to just drop a patch at the packaging level and not worry about releasing a tarball, but I certainly imagine how you came to rolling a tarball as that's more elegant to release than a patch
If we release a 'ltrace-linaro', which turns into the Ubuntu package 'ltrace-linaro', can it be superseded by a later 'ltrace' release?
Well it would be more work than the version trick above
Note however that you don't really know whether the next ltrace will have the patch or not, or a different patch. It's also hard to make sure you don't supersede an upstream version you didn't intend to supersede, or vice-versa: upstream could pick any next version number they like, and it might be earlier or later than yours.
linaro-toolchain@lists.linaro.org
-
Loïc Minier -
Michael Hope -
Yao Qi -
Zach Welch