[Simh] trouble selecting VAX ethernet on CentOS

[Michael Bloom]

Uggh.  It looks like you are on a system that doesn't set up usable (for 
the purposes of debugging)  stack frames.

I didn't see a "-fomit-frame-pointer" in your compilation, but  if you 
are using a recent gcc (>=4.6, or maybe just set up that way on CentOS 
for the hell of it), then that's the default on your system.

Add -fno-omit-frame-pointer to your gcc command, rebuild SIMH, and then 
try running under gdb again.

The presence of frame pointers should help gdb find what's in each stack 
frame.

Also, while you are in gdb, try listing the lines around 1454. Unless I 
missed the release announcement, 3.8.2 is a pre-release, so the lines 
you have may not be the same as the ones others have, so people can't go 
by just line numbers to see where you are.

- Michael


On 02/26/2012 09:05 PM, Michael L. Umbricht wrote:
> 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