From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stephen Warren" To: Subject: Fw: Insight build problems Date: Thu, 19 Aug 1999 23:34:00 -0000 Message-id: <004701beead7$1f28fa40$ac690118@frmt1.sfba.home.com> X-SW-Source: 1999-q3/msg00088.html Forwarded from another account to attempt to get around the ORB blockades on both my work and home accounts..... ----- Original Message ----- From: Stephen Warren To: Sent: Thursday, August 19, 1999 11:21 PM Subject: Insight build problems > I'm attempting to build/use Insight-19990816 on a Cygwin box. > > I'm running B20.1 with the 19990115 Cygwin patch to get rid of those > make/fork crashes, running under Windows95 4.00.950b. > > I'm attempting to cross-debug to a MIPS system running the PMON monitor. > I'm compiling all my own tools (binutils 2.6.1, gcc 2.8.1, insight) from > scratch (from FSF ftp site). Insight in particular was configured as: > > cd /mips-tools-build/insight-19990816 > ./configure --prefix=/mips-tools --target=mips-mips-elf > > I had to do a few things to get the software to compile. > > 1) > > Add cygpath to convert from DOS to Unix path, for the GNU LD > determination: > > {bfd,opcodes}/configure: > > ac_prog=ld > if test "$ac_cv_prog_gcc" = yes; then > # Check if gcc -print-prog-name=ld gives a path. > echo $ac_n "checking for ld used by GCC""... $ac_c" 1>&6 > echo "configure:1366: checking for ld used by GCC" >&5 > ac_prog=`($CC -print-prog-name=ld) 2>&5` > ac_prog=`cygpath -p -u "$ac_prog"` // ADD THIS LINE > case "$ac_prog" in > # Accept absolute paths. > > I guess this is all auto-generated from configure.in using autoconf, so > the real fix is in autoconf? The problem this solve is that gcc prints a > DOS style path > C:\CYGNUS\CYGWIN~1\H-I586~1\BIN\..\lib\gcc-lib\i586-cygwin32\egcs-2.91.57\ > ..\..\..\..\i586-cygwin32\bin\ld.exe which can't be executed for the > is-ld-a-gnu-ld test later, so it assumes that ld isn't GNU ld and things > start to go wrong (i.e. the makefile is configure to use the MS linker). > > I tried searching the configure.in and my autoconf directory for instances > of the text 'LIB /OUT:' which is part of the command string used for the > MS linker and couldn't find it, so I can't work out where the patch should > really be. Perhaps the insight snapshot was built with a different > autoconf than I have (2.13) > > 2) > > When compiling the simulator, I get errors whilst processing > sim/mips/tx.igen about something being unimplemented. I solved this by > commenting out the inclusion of this file in mips.igen right near the end > of > the file: > > :include:::m16.igen > file://:include:::tx.igen COMMENT THIS LINE > :include:::vr.igen > > 3) > > During the build process (maybe the install), a number of scripts are > called > as $(srcdir)/../../script, which evaluates to ./../../script (e.g. in the > bfd directory IIRC). For some reason, I get errors such as: > > ./../../script: Can't find ./../.././../../script > > [Actually, I fixed this by using just the cygwin1.dll from the latest > cygwin snapshot, although the make-crashing-in-fork bug or similar popped > up once with this whereas 19990115 had been rock solid] > > > > > Now for some questions: > > 1) > > When I installed the 19990115 snapshot of cygwin, I extracted it to > C:\cygnus\cygwin-b20\H-i586-cygwin32, since that's the only place where a > bin and lib directory would match up with the archive. I then ended up > with as pre-existing i586-cygwin32 and a new i586-pc-cygwin32 directory > under there. Should I copy the contents of the new directory over the old, > or delete the old? > > 2) > > If I run gdb as: > > mips-mips-elf-gdb hw.bin > > then the bottom-left box (filename) on the bottom window isn't populated > at all. > > If I then go to the file menu, then use the open option on the same > binary, it is populated and the source appears. If I then attempt to > change the third box (source mode) to mixed, I get an error message: > > Error: can't read "Cname": no such variable. I dont' recall this error > with Mumit's pre-compiled x86 native Insight. > > with stack trace: > > can't read "Cname": no such variable > while executing > "info exists _map($Cname,pc=$addr)" > (object "::.srcwin0.srcwin.container.pane1.childsite.con" method > "::SrcTextWin::FillMixed" body line 85) > invoked from within > "FillMixed t $tagname $filename $funcname $line $addr $pc_addr $lib" > ("MIXED" arm line 2) > invoked from within > "switch $current(mode) { > SOURCE { > FillSource t $tagname $filename $funcname $line $addr $pc_addr $lib > } > ASSEMBLY { > FillAssembly..." > (object "::.srcwin0.srcwin.container.pane1.childsite.con" method > "::SrcTextWin::location" body line 22) > invoked from within > "location $current(tag) $current(filename) $current(funcname) > $current(line) $current(addr) $pc(addr) $current(lib)" > (object "::.srcwin0.srcwin.container.pane1.childsite.con" method > "::SrcTextWin::mode_set" body line 16) > invoked from within > "$twin mode_set $new_mode $go" > (object "::.srcwin0.srcwin" method "::SrcWin::mode" body line 4) > invoked from within > "::.srcwin0.srcwin mode .srcwin0.srcwin.container.pane3.childsite.con.mode > MIXED" > (in namespace inscope "::SrcWin" script line 1) > invoked from within > "namespace inscope ::SrcWin {::.srcwin0.srcwin mode} > .srcwin0.srcwin.container.pane3.childsite.con.mode MIXED" > ("after" script)errorCode is NONE > > 3) > > None of the options in the target configuration window appear to work with > my embedded system (running Algorithmics PMON). Some claim to connect, but > don't show any data in e.g. the registers and memory windows (didn't try > the others) > > However, I can connect using the following commands in the gdb console > window: > > set remotebaud 9600 > target lsi com1 > > and then I can debug just like regular gdb from the console. Note that I'm > running at 9600 just to make sure serial overruns aren't causing problems. > I'm hoping to go to full 115200 when everything is sorted... Note > howevever that while I was trying out the GUI remote config dialog box, I > tried selecting 57600 and it wouldn't even open the serial port that > fast... > > BUT: The GUI windows seem unaware that gdb is connected e.g.: > > In the main source window, the step buttons are disabled. > > If I start a new source window, the buttons are enabled, but as soon as I > step once, they are then disabled. > > I can keep doing this as many times as I've tested, with a new window for > each step. > > Thanks for any help. If anyone needs any more debug info etc., I should be > able to grab it. > > -- > Stephen Warren, Software Engineer, Mediamatics, Fremont, CA > mailto:swarren@mediamatics.com http://www.mediamatics.com/ > mailto:swarren@wwwdotorg.org http://www.wwwdotorg.org/