From: Darren G. <ts...@ya...> - 2005-04-13 19:05:04
|
With NFS over 802.11for the gumstix, it's got me thinking about gdb again. The top-level makefile has a GDB_ VERSION, and the make directory has gdb.mk, but I don't understand the buildroot make system well enough to figure out why it doesn't seem to be building gdb. Has anyone built gdb targeted for and hosted on ARM? I tried a few months ago to build the latest gdb hosted on x86 and targeted for ARM, with some small success, I was able to talk to gdbserver running on the gumstix over 802.11. It was funky and didn't always find symbols correctly, but I could step through code much of the time. It would be really nice to have gdb turn-on-able somewhere similar to the TARGET options in the top level Makefile. Would anyone like to collaborate on that? |
From: <tho...@bt...> - 2006-08-23 15:05:21
|
Has anyone ever been able to get gdb to work? Either natively or using gdbserver. I have tried as many different combinations of binutils versions & gcc versions and gdb versions as I could and tried switching between static linking & dynamic linking, including & excluding debug symbols, playing with floating point emulation & softfloat libraries. I've never got it working and have pretty much given up now. The most common problem is when running a "hello world" program inside gdb/gdbserver, the program gets a SIGILL - Illegal instruction. If someone has got this working, could you please let me know what version of gcc, binutils & gdb you were using? Even better, forward me a copy of your uClibc & buildroot .config files please? Cheers, Tom |
From: Craig H. <cr...@hu...> - 2005-04-13 19:14:19
|
Try the existing "gdb_target" TARGET. C On Apr 13, 2005, at 12:05 PM, Darren Gibbs wrote: > With NFS over 802.11for the gumstix, it's got me thinking about gdb > again. The top-level makefile has a GDB_ VERSION, and the make > directory has gdb.mk, but I don't understand the buildroot make > system well enough to figure out why it doesn't seem to be building > gdb. > > Has anyone built gdb targeted for and hosted on ARM? I tried a few > months ago to build the latest gdb hosted on x86 and targeted for ARM, > with some small success, I was able to talk to gdbserver running on > the gumstix over 802.11. It was funky and didn't always find symbols > correctly, but I could step through code much of the time. It would > be really nice to have gdb turn-on-able somewhere similar to the > TARGET options in the top level Makefile. Would anyone like to > collaborate on that? > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Darren G. <ts...@ya...> - 2005-04-13 23:38:22
|
OK... for some reason I thought that all of the possible targets were included in the top-level makefile, with some just commented out. Now I see you can add all kinds of things from the make directory. Is there any reason to use/not-use gdb 6.2 over 6.1.1? On Apr 13, 2005, at 12:13 PM, Craig Hughes wrote: > Try the existing "gdb_target" TARGET. > > C > > On Apr 13, 2005, at 12:05 PM, Darren Gibbs wrote: > >> With NFS over 802.11for the gumstix, it's got me thinking about gdb >> again. The top-level makefile has a GDB_ VERSION, and the make >> directory has gdb.mk, but I don't understand the buildroot make >> system well enough to figure out why it doesn't seem to be building >> gdb. >> >> Has anyone built gdb targeted for and hosted on ARM? I tried a few >> months ago to build the latest gdb hosted on x86 and targeted for >> ARM, with some small success, I was able to talk to gdbserver running >> on the gumstix over 802.11. It was funky and didn't always find >> symbols correctly, but I could step through code much of the time. >> It would be really nice to have gdb turn-on-able somewhere similar to >> the TARGET options in the top level Makefile. Would anyone like to >> collaborate on that? >> >> >> >> ------------------------------------------------------- >> SF email is sponsored by - The IT Product Guide >> Read honest & candid reviews on hundreds of IT Products from real >> users. >> Discover which products truly live up to the hype. Start reading now. >> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@hu...> - 2005-04-14 16:37:26
|
On Apr 13, 2005, at 4:38 PM, Darren Gibbs wrote: > OK... for some reason I thought that all of the possible targets were > included in the top-level makefile, with some just commented out. Now > I see you can add all kinds of things from the make directory. > > Is there any reason to use/not-use gdb 6.2 over 6.1.1? I'd guess that 6.2 was less tested whenever it was that line was put into the Makefile. I'd probably try the latest 6.2.x and see if that works. C |
From: Darren G. <ts...@ya...> - 2005-04-14 19:26:25
|
I decided to try gdb 6.2.1. Getting it to build required termcap so I added a makefile for that (pasted below in case anyone else is interested). I also had to copy the "gumstix-buildroot/sources/gdb/6.2" directory to 6.2.1. The gdb binary is almost 2MB so I guess it ought not to install in the root/usr/bin directory... I'll report back on whether it actually works now that I've got it building :) ############################################################# # # libtermcap # ############################################################# # TERMCAP_SOURCE:=termcap-1.3.1.tar.gz TERMCAP_SITE:=ftp://ftp.gnu.org/gnu/termcap TERMCAP_DIR:=$(BUILD_DIR)/termcap-1.3.1 $(DL_DIR)/$(TERMCAP_SOURCE): $(WGET) -P $(DL_DIR) $(TERMCAP_SITE)/$(TERMCAP_SOURCE) libtermcap-source: $(DL_DIR)/$(TERMCAP_SOURCE) $(TERMCAP_DIR)/.unpacked: $(DL_DIR)/$(TERMCAP_SOURCE) zcat $(DL_DIR)/$(TERMCAP_SOURCE) | tar -C $(BUILD_DIR) -xf - $(SOURCE_DIR)/patch-kernel.sh $(TERMCAP_DIR) $(SOURCE_DIR) termcap*.patch touch $(TERMCAP_DIR)/.unpacked $(TERMCAP_DIR)/.configured: $(TERMCAP_DIR)/.unpacked (cd $(TERMCAP_DIR); rm -rf config.cache; \ $(TARGET_CONFIGURE_OPTS) \ CFLAGS="$(TARGET_CFLAGS)" \ ./configure \ --target=$(GNU_TARGET_NAME) \ --host=$(GNU_TARGET_NAME) \ --build=$(GNU_HOST_NAME) \ --prefix=/usr \ ); touch $(TERMCAP_DIR)/.configured $(TERMCAP_DIR)/libtermcap.a: $(TERMCAP_DIR)/.configured $(MAKE) $(JLEVEL) -C $(TERMCAP_DIR) $(STAGING_DIR)/lib/libtermcap.a: $(TERMCAP_DIR)/libtermcap.a $(MAKE) prefix=$(STAGING_DIR) -C $(TERMCAP_DIR) install libtermcap: $(STAGING_DIR)/lib/libtermcap.a libtermcap-clean: -$(MAKE) -C $(TERMCAP_DIR) clean libtermcap-dirclean: rm -rf $(TERMCAP_DIR) |
From: Darren G. <ts...@ya...> - 2005-04-14 19:45:11
|
Seems to work fine so far... I made a bin directory at the same level as the gumstix-buildroot and my project directories. I mounted the enclosing directory as /usr/local on the gumstix. So I (and gdb) can get to my source, and adding /usr/local/bin to my path on the gumstix make gdb (and other large executables) available. On Apr 14, 2005, at 12:26 PM, Darren Gibbs wrote: > I'll report back on whether it actually works now that I've got it > building :) |