Fw: Insight build problems

Fw: Insight build problems

[Stephen Warren]

Forwarded from another account to attempt to get around the ORB blockades
on both my work and home accounts.....

----- Original Message -----
From: Stephen Warren <swarren@wwwdotorg.org>
To: <insight@sourceware.cygnus.com>
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/