From mark at codesourcery.com Mon Dec 7 00:55:52 2009 From: mark at codesourcery.com (Mark Mitchell) Date: Sun, 06 Dec 2009 16:55:52 -0800 Subject: Want to be a Sourcerer? Message-ID: <4B1C5298.6060900@codesourcery.com> Since you're on this mailing list, we know you're interested in Sourcery G++. If you'd like to be a Sourcerer, and help develop, enhance, and optimize the GNU toolchain, the Eclipse IDE, and other aspects of Sourcery G++ -- or if you'd like to help people use these tools by working on examples, documentation, and support for new CPUs -- please visit: http://www.codesourcery.com/company/jobs and see if there's a spot for you. If you work for a CodeSourcery customer, please be aware that CodeSourcery does not hire from its customers. Therefore, we will not consider your application unless you are willing to speak with your management about your intention to seek employment elsewhere. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From pan.jordan at gmail.com Mon Dec 14 11:22:11 2009 From: pan.jordan at gmail.com (Pan Jordan) Date: Mon, 14 Dec 2009 19:22:11 +0800 Subject: 4.4-45 install fail in Ubuntu 9.10 x86-64 Message-ID: Dear sir, I just have my AMD64 workstation install Ubuntu 9.10 x86-64. Then I use the same way what I install in i386 VM, but it just stop after launch the CodeSourcery graphic screen and then return to hold on console mode. How to resolve this problem? Best regards Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ams at codesourcery.com Mon Dec 14 11:49:26 2009 From: ams at codesourcery.com (Andrew Stubbs) Date: Mon, 14 Dec 2009 11:49:26 +0000 Subject: [superh-gnu-discuss] 4.4-45 install fail in Ubuntu 9.10 x86-64 In-Reply-To: References: Message-ID: <4B262646.1050505@codesourcery.com> On 14/12/09 11:22, Pan Jordan wrote: > I just have my AMD64 workstation install Ubuntu 9.10 x86-64. Then I use > the same way what I install in i386 VM, but it just stop after launch > the CodeSourcery graphic screen and then return to hold on console mode. > How to resolve this problem? I don't know why the graphical installer might not work? I suggest you try to use the non-graphical installer, as follows, from the CodeSourcery knowledge base (available to registered users): ----- You can run the installer in console mode by invoking it with the -i console command-line option. For example: E:\> sourceryg++-4.2-143-arm-none-eabi.exe -i console It takes a few moments for the installer to start up. When running in console mode, you still have control of all installation parameters (such as the location where Sourcery G++ is installed). You can also use the -i console command-line option to run the Sourcery G++ uninstaller in console mode. ----------- If that doesn't work for you, then try a manual installation using the "IA32 GNU/Linux TAR" package from here: http://www.codesourcery.com/sgpp/lite/superh/portal/release1041 I hope that helps Andrew Stubbs CodeSourcery From wmat at naoi.ca Wed Dec 16 02:01:30 2009 From: wmat at naoi.ca (Bill Traynor) Date: Tue, 15 Dec 2009 21:01:30 -0500 Subject: [superh-gnu-discuss] 4.4-45 install fail in Ubuntu 9.10 x86-64 In-Reply-To: References: Message-ID: On Mon, Dec 14, 2009 at 06:22, Pan Jordan wrote: > Dear sir, > > I just have my AMD64 workstation install Ubuntu 9.10 x86-64. Then I use the > same way what I install in i386 VM, but it just stop after launch the > CodeSourcery graphic screen and then return to hold on console mode. How to > resolve this problem? > > Hi Jordan, I just successfully installed "Sourcery G++ Lite 4.4-45 for SuperH GNU/Linux" on my Ubuntu 9.1 x86_64 machine using the GUI Installer. Did you verify the MD5 Checksum of the binary you downloaded matches the one on the download page here: http://www.codesourcery.com/sgpp/lite/superh/portal/release1041 Also, the graphical installer is incompatible with the dash shell, which is the default on Ubuntu. You can reconfigure to a supported shell using: sudo dpkg-reconfigure -plow dash Install as /bin/sh? No Let me know if you're still having problems. Cheers Bill Best regards > Jordan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.damm at gmail.com Mon Dec 28 05:02:20 2009 From: magnus.damm at gmail.com (Magnus Damm) Date: Mon, 28 Dec 2009 14:02:20 +0900 Subject: mplayer argument parsing segfault with 4.4-45 Message-ID: Hi all, I'm using a static mplayer to test some kernel multimedia code, and I've ran into an issue with 4.4-45. The older 4.3-143 fails during build. The "good" old KPIT toolchain 4.2.1-SH4-LINUX_v0702 (gnush4_linux_v0702_rc-1-1.i386.tar.gz) is however working just fine. With 4.4-45 I can build the binary just fine, but during runtime I get a segfault. No options are passed to the cross gcc so I assume it's building for sh4a. To trigger a segfault pass "-tv outfmt=nv12" to mplayer. Omitting "-tv outfmt=nv12" removes the segfault. / # /mplayer -tv outfmt=nv12 tv://1 Segmentation fault I can reproduce this on real sh4a hardware and using qemu-sh (from gentoo app-emulation/qemu-0.9.1). Let me know if you need any additional information. Thanks! / magnus - - - Build and running instructions: 1. Get mplayer svn r30131 2. Apply the attached patch 3. Perform configure (replace _ with your prefix, use the attached good_options-vidix file): ./configure --cc=_gcc --as=_as --ar=_ar --host-cc=gcc --target=sh-linux --prefix=/ `cat ../good_options-vidix` 4. Run make: make EXTRALIBS="-lpthread -lm -static" 5. Execute binary on target or in qemu-sh4 mplayer -tv outfmt=nv12 tv://1 -------------- next part -------------- A non-text attachment was scrubbed... Name: mplayer-r30131-no-ass-fix-20091228b.patch Type: application/octet-stream Size: 807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: good_options-vidix Type: application/octet-stream Size: 2973 bytes Desc: not available URL: From mark at codesourcery.com Mon Dec 28 17:32:39 2009 From: mark at codesourcery.com (Mark Mitchell) Date: Mon, 28 Dec 2009 09:32:39 -0800 Subject: [superh-gnu-discuss] mplayer argument parsing segfault with 4.4-45 In-Reply-To: References: Message-ID: <4B38EBB7.40603@codesourcery.com> Magnus Damm wrote: > / # /mplayer -tv outfmt=nv12 tv://1 > Segmentation fault This might indicate a compiler bug, but of course it might also indicate a problem with mplayer. As the compiler becomes more aggressive in optimizing, it tends to expose more problems in existing applications. For us to investigate this, you'll have to produce a test case that shows what code you think is being miscompiled. That includes: 1. Preprocessed source code (obtained with -save-temps) for the file in question. 2. All command-line options used to compile that code. 3. Which function in the resulting object file you think has been miscompiled and why. Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From magnus.damm at gmail.com Tue Dec 29 08:32:35 2009 From: magnus.damm at gmail.com (Magnus Damm) Date: Tue, 29 Dec 2009 17:32:35 +0900 Subject: [superh-gnu-discuss] mplayer argument parsing segfault with 4.4-45 In-Reply-To: <4B38EBB7.40603@codesourcery.com> References: <4B38EBB7.40603@codesourcery.com> Message-ID: Hi Mark, On Tue, Dec 29, 2009 at 2:32 AM, Mark Mitchell wrote: > Magnus Damm wrote: > >> / # /mplayer -tv outfmt=nv12 tv://1 >> Segmentation fault > > This might indicate a compiler bug, but of course it might also indicate > a problem with mplayer. ?As the compiler becomes more aggressive in > optimizing, it tends to expose more problems in existing applications. Right, and mplayer is not exactly the most bug free piece of software around. > For us to investigate this, you'll have to produce a test case that > shows what code you think is being miscompiled. ?That includes: > > 1. Preprocessed source code (obtained with -save-temps) for the file in > question. > 2. All command-line options used to compile that code. > 3. Which function in the resulting object file you think has been > miscompiled and why. Thanks for the instructions. I mainly wanted to report the issue and make it possible for someone else to reproduce it. I'd like to get rid of the old KPIT compiler if possible and this is the only case left. The mplayer source is fairly large so I suspect that the issue needs to be tracked down further. Do you have any pointer to a more fine grained step by step document that can be followed to produce these things for you? I'm quite busy though so I'm afraid I'll just add this to my TODO list for now. Thanks, / magnus From wmat at naoi.ca Tue Dec 29 13:51:32 2009 From: wmat at naoi.ca (Bill Traynor) Date: Tue, 29 Dec 2009 08:51:32 -0500 Subject: [superh-gnu-discuss] mplayer argument parsing segfault with 4.4-45 In-Reply-To: References: <4B38EBB7.40603@codesourcery.com> Message-ID: On Tue, Dec 29, 2009 at 03:32, Magnus Damm wrote: > Hi Mark, > > On Tue, Dec 29, 2009 at 2:32 AM, Mark Mitchell > wrote: > > Magnus Damm wrote: > > > >> / # /mplayer -tv outfmt=nv12 tv://1 > >> Segmentation fault > > > > This might indicate a compiler bug, but of course it might also indicate > > a problem with mplayer. As the compiler becomes more aggressive in > > optimizing, it tends to expose more problems in existing applications. > > Right, and mplayer is not exactly the most bug free piece of software > around. > > > For us to investigate this, you'll have to produce a test case that > > shows what code you think is being miscompiled. That includes: > > > > 1. Preprocessed source code (obtained with -save-temps) for the file in > > question. > > 2. All command-line options used to compile that code. > > 3. Which function in the resulting object file you think has been > > miscompiled and why. > > Thanks for the instructions. I mainly wanted to report the issue and > make it possible for someone else to reproduce it. I'd like to get rid > of the old KPIT compiler if possible and this is the only case left. > Thanks Magnus, I was able to reproduce the segfault using your instructions. > > The mplayer source is fairly large so I suspect that the issue needs > to be tracked down further. Do you have any pointer to a more fine > grained step by step document that can be followed to produce these > things for you? I'm quite busy though so I'm afraid I'll just add this > to my TODO list for now. > I see if I can investigate this a little further as well. > > Thanks, > > / magnus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Tue Dec 29 16:21:55 2009 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 29 Dec 2009 08:21:55 -0800 Subject: [superh-gnu-discuss] mplayer argument parsing segfault with 4.4-45 In-Reply-To: References: <4B38EBB7.40603@codesourcery.com> Message-ID: <4B3A2CA3.3020202@codesourcery.com> Magnus Damm wrote: > The mplayer source is fairly large so I suspect that the issue needs > to be tracked down further. Do you have any pointer to a more fine > grained step by step document that can be followed to produce these > things for you? I'm quite busy though so I'm afraid I'll just add this > to my TODO list for now. The first technique is to mix object files between the good and bad builds. Build the whole thing with both compilers, but then link half of the object files from the good build with the other half from the bad build. Continue to bisect things until you have a bad object file. If you're lucky, that's a small object file with just one or two functions in it, and it will be obvious what's been miscompiled -- or what's buggy in the source code. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713