[Simh] trouble selecting VAX ethernet on CentOS

[Michael L. Umbricht]

Like this? 

Usually I do not type any arguments on the command line and just default
load a vax.ini file which maps the disk images. But even if I don't load
vax.ini it gives the same results.

-mikeu


[root at rigel vms]# gdb ./vax
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-50.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
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 "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mikeu/Downloads/simhv38-2/vms/vax...done.
(gdb) run vax.ini
Starting program: /home/mikeu/Downloads/simhv38-2/vms/vax vax.ini
[Thread debugging using libthread_db enabled]

VAX simulator V3.8-2
NVR: buffering file in memory
[New Thread 0x7ffff7fe0700 (LWP 4575)]
[New Thread 0x7fffd6e64700 (LWP 4576)]
RQ2: unit is read only
[New Thread 0x7fffd6462700 (LWP 4577)]
RQ3: unit is read only
[New Thread 0x7fffd5a60700 (LWP 4578)]
Listening on port 2020 (socket 13)
Modem control activated
Auto disconnect activated
sim> at xq eth1
libpcap version 1.0.0

Program received signal SIGSEGV, Segmentation fault.
0x00000000004533e1 in eth_open (dev=Cannot access memory at address
0x7fff00366877
) at sim_ether.c:1454
1454	  savname = eth_getname(num, temp);
Missing separate debuginfos, use: debuginfo-install
glibc-2.12-1.47.el6_2.5.x86_64
libpcap-devel-1.0.0-6.20091201git117cb5.el6.x86_64
ncurses-devel-5.7-3.20090208.el6.x86_64
ncurses-libs-5.7-3.20090208.el6.x86_64 readline-devel-6.0-3.el6.x86_64
(gdb) bt
#0  0x00000000004533e1 in eth_open (dev=Cannot access memory at address
0x7fff00366877
) at sim_ether.c:1454
Cannot access memory at address 0x7fff00366e77
(gdb) bt full
#0  0x00000000004533e1 in eth_open (dev=Cannot access memory at address
0x7fff00366877
) at sim_ether.c:1454
        bufsz = <error reading variable bufsz (Cannot access memory at
address 0x7fff00366e3b)>
        errbuf = <error reading variable errbuf (Cannot access memory at
address 0x7fff00366d2f)>
        temp = <error reading variable temp (Cannot access memory at
address 0x7fff0036692f)>
        savname = <error reading variable savname (Cannot access memory
at address 0x7fff00366e3f)>
        num = <error reading variable num (Cannot access memory at
address 0x7fff00366e4b)>
        msg = <error reading variable msg (Cannot access memory at
address 0x7fff00366e4f)>
Cannot access memory at address 0x7fff00366e77
(gdb) 


> -------- Original Message --------
> Subject: Re: Re: [Simh] trouble selecting VAX ethernet on CentOS
> From: Michael Bloom <mabloom at dslextreme.com>
> Date: Sun, February 26, 2012 9:00 pm
> To: Jan-Benedict Glaw <jbglaw at lug-owl.de>
> Cc: "Michael L. Umbricht" <mike at umbricht.org>, 
> "simh at trailing-edge.com" <simh at trailing-edge.com>, Mark Pizzolato - Info
> Comm <Mark at infocomm.com>
> 
> 
> On 01/-10/-28163 11:59 AM, Jan-Benedict Glaw wrote:
> > Are all object files built with -g and is the `vax' binary not
> > stripped? Then you'd just run it with gdb:
> >
> > $ gdb ./vax .....
> >
> > Then do your work (->  make it segfault) and when you're back at GDB's
> > prompt, use the `bt' command to show us where it's breaking.
> 
> It may be obvious, but in case it is not,  don't replace the "....." 
> with simh arguments.  That would produce a "No such file or directory" 
> message.
> 
> Instead, after typing:
> 
> $ gdb ./vax
> 
> run the program with
> 
> (gdb) run Program_Arguments
> 
> where <Program_Arguments> are the arguments you would normally provide 
> on the command line to simh.
> 
> Then, follow the rest of Jan-Benedict's instructions (make it segfault, 
> and get a backtrace).  Actually, after typing "bt", it might help to 
> also say "bt full",  to provide additional information (about local 
> variable values), without cluttering up the initial backtrace.
> 
> - Michael