I am trying to build gdb for armv6 architecture. I will be compiling this package on a Fedora Linux-Intel x86 box. I read the process of installing the gdb, like
Download the source pachage
run configure -host
make
But I got lost in the process because I was not able to make out what will be the host, target, needed for the configure script.
I need to basically be able to debug programs running on armv6 architecture board which runs linux kernel 2.6.21.5-cfs-v19. The gdb executable which I intend to obtain after compilation of the source also needs to be able to run on above mentioned configuration.
Now to get a working gdb executable for this configuration what steps should I follow?
We (www.rockbox.org) use the arm target for a whole batch of our currently working DAPS. The target we specify is usually arm-elf, rather than arm-linux.
Be careful with arm-linux vs. arm-elf, eg.
http://sources.redhat.com/ml/crossgcc/2005-11/msg00028.html
arm-elf is a standalone toolchain which does not require an underlying OS. So you can use
it to generate programs using newlib
arm-linux is a toolchain targetted to generate code for linux OS running on an ARM machine
We sometimes say arm-elf is for "bare metal".
Unfortunately there's another "bare metal" target arm-eabi and no one knows what the difference between these two exactly is.
BTW,
The gdb executable which i intend to obtain after compilation of the source,also needs to be able to run on above mentioned configuration.
Really? Running GDB on an ARM board may be quite slow.
I recommend you either of
Remote debugging of the ARM board from an x86 PC
Saving a memory core on the ARM board, transferring it to an x86 PC and then inspecting it there
Cf.
http://elinux.org/GDB
Cross-platform, multithreaded debugging (x86 to ARM) with gdb and gdbserver not recognizing threads
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/remote-debugging
target/host is usually the target tool chain you would be using (mostly arm-linux)
Related
What's the difference between gdbserver and remote gdb (i.e. over SSH)?
Why do they coexist? The Unix philosophy suggests the software should do one thing well, i.e. debug local programs.
It seems to me that gdb violates this principle by doing another thing in addition to that - interacting with gdbserver.
gdbserver is smaller than GDB and has fewer dependencies, so it can be run on a system which is resource constrained such that GDB itself can't be run. Or maybe GDB just can't be run for some other reason, e.g. the target platform doesn't have Python, and you want to use some of the Python features of GDB.
Next, but kind of related, the target platform might not be the same architecture as the host platform (on which GDB runs), maybe compiling GDB, Python, syntax-highlighting libraries, etc for a small target isn't what you want to do with your time, instead you can just compile gdbserver, and then run GDB on your local machine.
Finally, though gdbserver is useful in itself, it also serves as a useful mechanism to test GDB's remote serial protocol support. This protocol is documented in the GDB manual and allows software other than gdbserver to interact with GDB, for example OpenOCD, and QEMU, both support GDB's remote protocol, this allows GDB to debug baremetal targets on which neither GDB, nor gdbserver could ever run.
You are correct to observe that this basically means that GDB has two methods of debug, its native target support, and its remote target support. If we wanted to be ideologically pure then we could (in theory) remove the native target support from GDB, and just make use of the gdbserver in all cases, i.e. when you try to debug a program on the local machine, GDB would automatically start gdbserver, connect to it, and debug through that interface. I don't expect to see that change any time soon though.
We've got this legacy Fortran code running on a board with an A9 processor, and I've noticed some funny behavior when using gdb. Threads continue to run when it is in all-stop mode, and it seems gdb crashes when you switch it to non-stop mode. It also can't do watchpoints on symbols in the Fortran code, not sure if that's due to the port or the binaries not belonging to the same toolchain. You can set a watchpoint on the address cast as a C type, however.
We've got toolchain binaries from CodeSourcery installed to the stage directory during the rootfs build, then as part of our application build Linaro binaries overwrite some of the libraries in the targetroot. The libraries that are overwritten are (some of?) the only ones needed by the application and the ones it is linked against (libstdc++, libgfortran, and libpthread).
Using either gdb from CodeSourcery or Linaro seems to function equivalently, though I didn't try setting hardware assisted watchpoints with the Linaro compiler. Neither seem to be configured to work outside the documented behavior, which unless I'm mistaken what I've observed runs counter to it.
So is this fine? I mean, it runs, but if gdb is at least slightly broken I don't know what other utilities would be. I'd like to see about making use of Eclipse+Photran and TCF Agent, and I was looking into where the CodeSourcery toolchain came from, which led me to Yocto. I've been trying some builds with Yocto at home, and I'm wondering if it's worth my time to bring in a VM with all of this set up to try run our application with the toolchain built into the rootfs from the ground up.
Probably too late to switch anything over but if I can just have a smoother environment under which to work then I can just toss the source back into our current solution when it's time to turn in a fix.
I compiled and ran a C++ program using Eclipse on my MacBook Pro. I now need to convert the Unix executable to a windows executable. How do I go about this? Specifally, how do I get this code to run on a Windows machine from the command prompt?
The only way you can get the unix executable to run on a Windows system is using a virtual machine (Something like VMWare or VirtualBox). This isn't REALLY running it on Windows, of course, it's setting up a UNIX system on Windows and running it on that UNIX system.
The executables (and the needed runtime environment) are vastly different between the two systems, you can't just run executables from one on the other.
Your only other option is to setup Eclipse on your Windows system and compile the application there.
You cannot "convert" an executable, you need to recompile for your target system. If you are using a GCC toolchain that is set up for Eclipse and there is no Mac specific code, it should be as easy as moving the project over, setting it up in Eclipse, and recompiling it. If that is too much of a hassle, you can consider setting up a Makefile and using MingW or Cygwin, or even Visual Studio if you'd like. If there is Mac specific code, then you need to look up the appropriate Windows documentation, or use something cross-platform like GTK+ or Qt.
I am working on a C, project which uses ffmpeg library.
Currently I'm working on windows platform, and I'll be cross compiling the project for Linux ARM.
With that background, I have few basic questions.
If I use ANSI C++, I can be sure that, I'll be able to cross compile the project using corresponding compilers [ MSVC, MingW ]
But ..
If I'm using "Win32" and other "Windows" specific APIs in my project, how does the cross compiler will handle it, to make the project able to run on Linux.
Similarly, If I'm using Linux specific "features" in my project, how does the cross compiler will handle it, to make the project able to run on Windows.
When you cross-compile, the code that is being cross-compiled must use APIs that are available on the target platform (ie, the one that it will eventually run on). A cross-compiler does not magically give access to Win32 APIs when its output is run on a Linux machine; it is the same as compiling the code on the target machine, but means you don't need to actually do so. You could achieve the same thing, in other words, by just running a native (non-cross) compiler on an ARM Linux box, but you'd need a powerful enough ARM box to run the compiler.
That said, in principle, you could cross-compile to Linux while using winelib to provide win32 APIs. Not sure how well it works on ARM though - it's only really meant to be used on x86.
Finally, note that cross-compiling tends to be quite complex even in the best of times. It may make your life simpler to cross-compile from x86 Linux to ARM Linux instead of x86 Windows to ARM Linux - while it's possible to do cross-OS and cross-platform builds, the less variables you have changing the simpler things will be.
If you use Winapi, your project will not be able to run on Linux.
How can a cross compilation setup be achieved to allow compiling Cell Linux programs on a Windows PC using the cygwin toolchain? The cygwin tools provide a GNU compiler to use in building the cross compiler, and associated tools for the build process e.g. rpm, cpio, make, flex, bison and so on.
I am moderately confident this is possible, but unaware of anyone who has actually done this. It has already been done for x86 Linux, but I wish to use Windows, without requiring the use and overhead of a virtual machine running an entire 2nd operating system.
The Cell Linux toolchain is a patched GNU toolchain, with C and C++ compilers for the PPU and SPU processors, and associated binutils. The sources for the Cell Linux SDK for Cell Linux can be found here. The source RPMS here have build scripts for use with the rpmbuild tool on Linux.
The specific question is: how can a set of Cell Linux GNU compilers for the PPU and SPU processors be built, on Windows, using Cygwin.
I've never done it, so I can't give you step by step instructions, but I can give you a general idea.
The instructions you linked will serve as a pretty good outline, but there will be definite changes.
For the host PC, you can install gcc and other build tools from MinGW or cygwin. That will give you the windows native parts of your toolchain.
Then you'll need to download the sources for the cell portions of the toolchain and compile them (with the appropriate options, --target, etc.) using the build environment you just installed.
Then you download and compile the sources for libspe2, and you're done.
But I'll warn you - it sounds easier than it is. Be prepared to spend a lot of time on it.
Since you can already do this on Linux x86, why don't you just install Linux a virtual machine? Also, what might be even easier, is to install Portable Ubuntu for Windows. It runs Linux alongside Windows using coLinux. Although this may not be optimal, it is probably much easier than trying to compile everything on Windows.
the ps2dev toolchain can easily be set up under cygwin
http://ps2dev.org/ps3/Tools/Toolchain
You should be able to build a canadian cross compiler on Linux that runs on windows and creates code for PS3. Have a look at the excellent crosstools from Dan Kegel.
Did you check if the Cell/PS3 devtools for windows/cygwin work for you?
A set of tools compiled to run on Windows via Cygwin can now be found on Sourceforge.
Mike Acton has a long, detailed article on cross-compiling for PS3 Linux on his Cell Performance blog.
It may be a bit out of date, but the bits on setting up the toolchain and various SDKs might prove handy.