I am wishing to debug 32 bit nacl exe on mac platform. I couldnt debug it out since on mac platform i couldnt find a 32bit nacl-gdb. Has anyone successfully done it?
GDB for Native Client was released in Pepper 23, so first check that you're using the Pepper 23 version of the NaCl SDK or newer. (To download any new versions of the SDK, issue ./naclsdk update from your nacl_sdk directory. When it's done, you should see a pepper_23 directory (or newer). Use the tools in that directory.)
In the SDK the GDB binaries are in these locations (example based on Pepper 23):
nacl_sdk/pepper_23/toolchain/mac_x86_glibc/bin/i686-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_glibc/bin/x86_64-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_newlib/bin/i686-nacl-gdb
nacl_sdk/pepper_23/toolchain/mac_x86_newlib/bin/x86_64-nacl-gdb
The two i686-nacl-gdb are in fact just symbolic links to the two x86_64-nacl-gdb. The x86_64-nacl-gdb binaries will allow you to debug both 32-bit and 64-bit x86 NaCl targets. On the Mac, though, Chrome is always 32-bit and will always run the 32-bit .nexe, even if your OS or machine is 64-bit.
Both the newlib and the glibc toolchain contains a complete set of tools; this is why you have two x86_64-nacl-gdb binaries. Currently, these two do not differ, but for your own sanity it's probably easiest to use the GDB in the same directory as the tools used for your build.
There is some additional guidance at https://developers.google.com/native-client/devguide/devcycle/debugging#gdb. The all-important thing is to pass the flag --enable-nacl-debug to Chrome or activate it under about:flags in Chrome. This will cause Chrome to wait for the debugger to connect before executing Native Client content.
Related
I've got some experience in programming for Windows environment but I need to develop a "Kiosk" (I've heard that this is the right name) on a BeagleBone Black. I'm totally new to Linux and also new to the tools I'm going to use. Until the last couple of months, I developed with VB6 and C++Builder only.
Right now I have Eclipse, MinGW and wxWidgets working on my Windowns 7 64-bits PC, and the BeagleBone Black booting a Debian 7.8 with LXDE.
I need to setup a tool-chain to compile for the BeagleBone Black. I tried really hard and have read at least hundred pages, but still I've not figured it out.
From This Site I've learnt that it's possible to compile for Linux from Windows, which could be the perfect solution. If not possible, I already have a Virtual Machine running Ubuntu (but I can change it if needed) ready for Eclipse and other stuff installation.
I'm still lost about what tool-chain to use/build with. This site seems to have already built a tool-chain, but there's no indication to where to go from there. I understand that I should now compile the wxWidgets with this tools, but I'm unsure and also I don't want to mess-up my current working setup in Windows 'cause I missed a switch or a path.
I see how this question was asked more than one time, but I didn't find one that is up-to-date so I'm asking it again.
How to make a tool-chain to compile a GUI application, from Windows using Eclipse, MinGW and wxWidget for a BeagleBone Black running Debian and LXDE?
You need a compiler that runs on Windows and produces binaries for the target platform (Debian arm).
You need a SDK (headers, libs) for the target platform.
The MinGW-64w wiki describes how to build MinGW cross-compiler and build environment.
You can also look at SO: C++ cross-compiler from Windows to Linux.
Another technique is Canadian Cross, like Google makes its Android NDK for Windows host. At first you should setup Linux build machine. Then build GCC and binutils that will run on Windows machine and will produce binaries for Debian arm. Then copy built toolchain to Windows Cygwin or MSYS environment.
Ideally, I want to compile our QT-based apps, which also link other third-party libraries, on 64-bit Linux using GCC, but for a 64-bit Windows target. Again ideally, I want the result to run on 64-bit Windows without any additional runtime support, just as if we had compiled the same source code in Visual Studio. Is this possible with MinGW-w64?
I have successfully used MinGW-w64 to compile simple apps with GCC on Windows. I'm not sure how much of the MinGW-w64 installation is runtime support for executables as opposed to support for the GCC compilation environment. I did attempt to run a WinGW-w64 hello world executable on an installation of Windows without MinGW-w64, but had missing dll errors. This tells me that some runtime support was necessary, but I would like to know more precisely what is required.
If you don't want to install Windows, I think the best way is using a Virtual Machine. That's because even if the source code compiles for Windows, how could it be verified to run? You will need a real target environment to finally test your application.
From a complexity point of view, I think setting up a Windows machine (VM or not) and the necessary environment for Qt is a whole lot simpler than cross compiling bug hunting afterwards.
You can install Qt on the installed Windows, copy your project there, compile it and see the results in the real environment. This way you can cope with the minor differences when porting from one OS to another easily.
Nothing stops you from developing on Linux. You can do the entire development on Linux and just test the code on the prepared Windows by compiling and running. Sending the code to the Windows environment is simple by using git. The development process can be like :
Make a repository of your application, clone the repository both on Linux and Windows
Do the Major development on Linux and push
Pull on Windows from time to time, compile, test and make minor fixes and then push
I am using Qt 5.3 on Windows 8.1 64 bit and Ubuntu 14.04. Compared to Ubuntu, debugging on Windows takes ages.
Why is there such a huge difference? Do I need to set up anything special on Windows?
It is likely you're having this behaviour because your debugger can't find the debugging symbols for Windows-internal libraries. By default, they are not part of your Windows Installation or Qt Creator.
There are two ways to obtain them:
If you are behind a fast internet connection: Set up a symbol server from where symbols can be loaded on demand: http://qt-project.org/doc/qtcreator-3.0/creator-debugger-engines.html#setting-the-symbol-server-in-windows
Otherwise: Download the Debugging Symbols for Windows (usually part of the Windows SDK) from the Microsoft Homepage and configure your debugger to use the symbols from there. Usually you just specify a cache directory as in step 1 and install the symbols to that very folder.
If you are debugging win32 code under x64 then there is a big chance you are doing it with x64 version of CDB, which CAN debug x86 binaries, but does it awfully slow.
The solution is to install Debugging Tools For Windows (from Windows SDK) and switch your debugger to the correct version. In this case - x86. The debugger will instantly become highly responsive.
MY code will be deployed on FreeBSD. Would I be able to code using VS2010 in Win7? can this be done on Linux using gcc? or do I need to have freebsd installed on my laptop.
I plan on buying a new ultrabook and not sure FreeBSD will support the drivers or wireless. What the best practice here? VMs?
Thanks mods.
You can just write code in Visual Studio, however you will not be able to compile and run it in Windows, unless you are only using standard libraries.
To compile and test your code you need a FreeBSD somewhere.
I have never used FreeBSD on a laptop, so I can't say if dualbooting it with Windows is a good idea.
The best thing would be if you had access to a test server with the same configuration as your production server (i.e. same FreeBSD version, same packages, etc.). Then you could write code in VS, check it into a repository, SSH to the server, update a local copy of the source there and build.
If that is not an option, I recommend setting up a virtual environment. Download VirtualBox, obtain FreeBSD and install it on the VM. Set up port forwarding for SSH and then the process is pretty much the same as with a separate server. You may have to make some additional tweaks depending on the nature of the work you'll be doing.
Here is a setup I have used in cases where I am not using any OS specific library.
On your Windows 7 machine develop your application as usual without using MFC/ATL etc. If you are linking to external libraries/APIs you will have to use one which is portable across Windows and Linux (e.g. Boost libraries). Do not use pre-compiled headers (stdfax.h) or any other option which is Windows specific.
Get VirtualBox and install your favorite OS (FreeBSD in this case) and your favorite tool chain (gcc clang)
Share the disk/folder you are developing your app in the Windows file system so that it is visible in VirtualBox. In Ubuntu they end up in the /media/sf_Folder.
Compile in FreeBSD in VirtualBox. You will need to have an alternative make system setup in parallel in addition to the stuff Visual Studio creates. Make sure you do not have any conflicts in the way the directories used by the build system (to store object files etc.) between FreeBSD and Windows. You can try out this http://code.google.com/p/make-it-so/ to convert your VS solutions to gcc makefiles.
This way you can continue to use your favorite IDE and also rebuild on your target *ix OS on the same machine.
gcc + gvim + ( ( ctags with omnicppcomplete ) or ( clang with clang_complete ) and STL + Boost.
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.