[Simh] OpenBSD (5.6) issues

Mark Pizzolato - Info Comm Mark at infocomm.com
Sun Jan 11 18:26:51 EST 2015


On Tuesday, November 11, 2014 at 11:53 AM, Mark Pizzolato wrote:
> On Tuesday, November 11, 2014 at 12:45 AM, Cory Smelosky wrote:
> [...]
> > > It looks like you are having isues witg word size. Your machine
> > > seems
> > confusef about word size issues. I386 amd64 and  x86?_64 all sem ro
> > show  up.
> > >
> >
> > Hmmm, strange it only appears in the (probably-less-maintained)
> simulators.
> > ;););)
[...]
> Actually, the PC complaints are name collisions with readline components
> which are dynamically loaded.  It seems that some readline dependent
> libraries export a variable PC which collides with the PC defined in the
> simulator.  Since scp's use of readline usage is very simple, I'm pretty sure
> that the existence of the name collision doesn't actually cause a problem.
> 
> This issue will occur with any simulator which has a global variable PC defined.
> Many/most simulators have a PC register, but this is often defined as a macro
> which refers to an element of an array:
> For example, the PDP11 has:
> #define PC R[7]
> In this case, there is no global variable called PC which exists in the linker
> observed name space, and thus no warning happens when readline is
> dynamically loaded at simulator startup.
> 
> I believe that this is completely safe to ignore.

Umm... Urrr... Well... 

Actual usage of a simulator with a global variable named PC shows that my statement: "I believe that this is completely safe to ignore." was WRONG and the warning about the size is really just the tip of the iceberg.  All simulators which have a global variable called PC will have operational issues when readline is dynamically loaded EVEN IF no warning is issued.  This affects other platforms beyond OpenBSD as well.

As it turns out, about 10 of the 42 current simulator binaries are affected by this.

The relatively easy fix is a one line addition to the simname_defs.h file to avoid the issue:

     #define PC    PC_Global               /* Rename of global PC variable to avoid namespace conflicts on some platforms */

This avoids the problem without making wholesale changes to any other source modules.  The only downside is that if a simulator developer is using a symbolic debugger, any references made to examine the variable from the debugger must use the PC_Global name instead of PC.  Since most of these simulators are relatively mature, running under a symbolic debugger is a relatively rare activity these days.

I've checked in the above change to all the relevant simulators.

- Mark


More information about the Simh mailing list