On Fri, 8 Aug 2008 04:39:17 +0100, Pedro Alves wrote: > Anyone able to test this? Eli? So, I took a few hours today to build a GDB on DJGPP. After some hacks and patches, I succeeded. This is what is looks like with the attached patches installed: bash-2.04$ ./gdb ./gdb GNU gdb (GDB) 6.8.50.20080808-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i586-pc-msdosdjgpp --target=djgpp". For bug reporting instructions, please see: ... (gdb) start Temporary breakpoint 1 at 0x1f8c: file ../../gdb/gdb.c, line 28. Starting program: c:/djgdb/src/djgpp/gdb/./gdb.exe Temporary breakpoint 1, main (argc=1, argv=0x36da0c) at ../../gdb/gdb.c:28 28 memset (&args, 0, sizeof args); (gdb) info threads * 1 Thread
main (argc=1, argv=0x36da0c) at ../../gdb/gdb.c:28 (gdb) kill Kill the program being debugged? (y or n) y (gdb) info threads (gdb) n The program is not being run. (gdb) Here is a description of what I've done to build gdb on DJGPP: I used a Windows XP machine. Downloaded DJGPP 2.03, bash 2.04, and all the needed dependencies to build GDB from djgpp's ftp archive. These are all the zips I downloaded and installed. Most likelly a couple aren't needed, though. bnu217b.zip djlsr203.zip fil41d.zip gwk316b.zip rhid15ab.zip bnu217s.zip djtst203.zip find41b.zip gwk316d.zip rhid15as.zip bsh204br2.zip em2005b.zip find41d.zip m4-149b.zip sed415b.zip bsh204d.zip em2005li.zip flx254b.zip m4-149d.zip sed415d.zip bsn23b.zip em2005s1.zip gcc423b.zip mak3791b.zip shl2011b.zip bsn23s.zip em2005s2.zip gdb611b.zip objc423b.zip shl2011d.zip dif287b.zip faq230b.zip gpp423b.zip pakk023b.zip txi412b.zip dif287d.zip faq230s.zip grep253b.zip pakk023s.zip txt20b.zip djdev203.zip fil41b.zip grep253d.zip pdcur33b.zip txt20d.zip I didn't need to use the special djunpack to rename gdb's sources to 8.3 format, since I was under bash + winxp, which sees long filenames. bash-2.04$ gcc -v Using built-in specs. Target: djgpp Configured with: /v203/gcc-4.23/configure djgpp --prefix=/dev/env/DJDIR --disable-nls --disable-werror --enable-languages=c,c++,fortran,objc,obj-c++,ada Thread model: single gcc version 4.2.3 I configured gdb out of tree with: ../src/configure \ --target=i586-pc-msdosdjgpp \ --host=i586-pc-msdosdjgpp \ --build=i586-pc-msdosdjgpp I to pass target,host to force a native build. The default of not passing any argument to configure, ended up building with target=i586-pc-msdosdjgpp host=i386-pc-msdosdjgpp, which, being different, triggeres a cross build, which excludes go32-nat.c. About the first patch: - The readline bits, the patch explains what's needed. Here's the error log gcc -DHAVE_CONFIG_H -I. -I../../readline -DRL_LIBRARY_VERSION='"5.1"' -O0 -g3 -c ../../readline/support/wcwidth.c In file included from ../../readline/support/wcwidth.c:9: c:/djgpp/include/wchar.h:24: error: expected '=', ',', ';', 'asm' or '__attribut e__' before 'typedef' ../../readline/support/wcwidth.c: In function 'wcwidth': ../../readline/support/wcwidth.c:130: warning: comparison is always false due to limited range of data type ../../readline/support/wcwidth.c:130: warning: comparison is always true due to limited range of data type make.exe: *** [wcwidth.o] Error 1 - libbfd cc1.exe: warnings being treated as errors ../../bfd/archive.c: In function '_bfd_archive_bsd_update_armap_timestamp': ../../bfd/archive.c:2314: warning: comparison between signed and unsigned time_t in djgpp is unsigned int, armap_timestamp is long. There's a comment at the definition of armap_timestamp, claiming that it isn't time_t until more compilers support it. - libiberty: I get this error when building libiberty: rm -f needed-list; touch needed-list; \ for f in atexit calloc memchr memcmp memcpy memmove memset rename strchr strerro r strncmp strrchr strstr strtol strtoul tmpnam vfprintf vprintf vfork waitpid bc mp bcopy bzero; do \ for g in ; do \ case "$g" in \ *$f*) echo $g >> needed-list ;; \ esac; \ done; \ done c:\djgpp\tmp/dj750000: line 1: syntax error near unexpected token `;' c:\djgpp\tmp/dj750000: line 1: `rm -f needed-list; touch needed-list; for f in atexit calloc memchr memcmp memcpy memmove memset rename strchr strerror strncmp strrchr strstr strtol strtoul tmpnam vfprintf vprintf vfork waitpid bcmp bcopy bzero; do for g in ; do case "$g" in *$f*) echo $g >> needed-list ;; esac; done; done' make.exe[2]: *** [needed-list] Error 2 I can't tell what's going on here. Maybe it's related to using make 3.79.1. I just hacked the Makefile to just touch the needed-list file and do nothing else with it. There's a comment in the makefile claining this is needed for libstdc++. For some reason, maybe related to the above, a few libiberty objects are not being built and archived: I manually added snprintf.o, vasprintf.o, asprintf.o and vsnprintf.o to REQUIRED_OFILES to libiberty's generated Makefile. I don't plan to persue to proper fix for these issues. GDB changes: - DJGPP 2.03 doesn't come bundled with stdint.h, but I downloaded it djgpp's cvs (from the web frontend to CVS actually), and install it manually. Seems to work fine. The build complains about not finding stdint.h. DJGPP 2.03 doesn't come bundled with stdint.h, but we should be picking up stdint.h from gdb/gnulib. There seems to be a build order dependency going wrong. We configure gdb/gnulib before starting to build gdb/, but we build gdb/ before gdb/gnulib. I had to cd to build/gdb/gnulib, and "make" it. This creates a gdb/gnulib/stdint.h, and also gdb/gnulib/string.h with memmem declared in it, which is needed to compile target.c, due Then I can come back to build/gdb, and continue building. This is using GNU Make 3.79.1, which is what prebuilt at djgpp's download site. It seems to be that even if we don't support auto-dependencies with this make version, it should still build gnulib before gdb. Actually, I just tried with GNU Make 3.81 on linux, and I see the same issue. - "missing sentinel in function calls" warnings: NULL is not a pointer in djgpp. GCC was barking on a few concat calls. - cp-name-parse.y Needed to include config.h, so HAVE_DECL_SNPRINTF was defined, so libiberty.h declares snprintf. - go32-nat.c: There was a bit of bit rot around. GCC complains about attribute packed like so: cc1.exe: warnings being treated as errors ../../gdb/go32-nat.c:1292: warning: 'packed' attribute ignored for field of type 'unsigned char' ../../gdb/go32-nat.c:1301: warning: 'packed' attribute ignored for field of type 'unsigned char' make.exe: *** [go32-nat.o] Error 1 Just removed the attribute from the offending fields. Are the GDB parts of patches OK? I checked that x86_64-unknown-linux-gnu still builds OK. -- Pedro Alves