Experimental Physics and
Industrial Control System

mdavidsaver via Core-talk <[email protected]> · Wed, 28 Aug 2019 22:41:40 -0000

Though I don't think it has any effect on the proposed changed, I'd like
to clarify my confusion.

I don't see anything on this page about "another translation unit".  In
fact I see:

> If there are no definitions in the same translation unit, then the
tentative definition acts as an actual definition with the initializer =
0 (or, for array, structure, and union types, = {0}).

In fact the GCC docs for -fno-common state:

> Unix C compilers have traditionally allocated storage for uninitialized global variables
> in a common block. This allows the linker to resolve all tentative definitions of the
> same variable in different compilation units to the same object, or to a non-tentative
> definition. This is the behavior specified by -fcommon, and is the default for GCC on
> most targets. On the other hand, this behavior is not required by ISO C, and on some
> targets may carry a speed or code size penalty on variable references. 

https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-
Options

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1841692

Title:
  Non-VME RTEMS targets should define pdevLibVME

Status in EPICS Base:
  Fix Committed
Status in EPICS Base 7.0 series:
  Fix Committed

Bug description:
  Support modules that build IOCs with drivers that call devLib routines
  can't be compiled on non-VME RTEMS targets such as RTEMS-pc386 since
  the linker fails to find the symbol pdevLibVME. The build *only* fails
  for RTEMS targets though, other non-VME targets such as Windows or
  darwin will quite happily compile and link the IOC code. This makes
  the authors of support modules have to jump through hoops to ensure
  they don't build IOCs for targets that will fail, or to just let the
  build fail (many sites don't build for RTEMS anyway).

  The RTEMS implementation of devLibVMEOSD.c uses pre-processor
  conditionals to only define the devLibVME *pdevLibVME pointer inside
  #if defined(__PPC__) || defined(__mcf528x__)

  We could make life much easier for module authors by adding this:

  diff --git a/modules/libcom/src/osi/os/RTEMS/devLibVMEOSD.c b/modules/libcom/src/osi/os/RTEMS/devLibVMEOSD.c
  index 0a96bad..b8f79e7 100644
  --- a/modules/libcom/src/osi/os/RTEMS/devLibVMEOSD.c
  +++ b/modules/libcom/src/osi/os/RTEMS/devLibVMEOSD.c
  @@ -350,7 +350,12 @@ static void unsolicitedHandlerEPICS(int vectorNumber)
           );
   }

  -#endif /* defined(__PPC__) && defined(mpc750) */
  +#else /* !defined(__PPC__) && !defined(__mcf528x__) */
  +
  +/* No known VME interface here, provide a dummy */
  +devLibVME *pdevLibVME;
  +
  +#endif /* defined(__PPC__) || defined(__mcf528x__) */

   /*
    * Some vxWorks convenience routines

  With that change (which is identical to the osi/os/default version),
  the non-VME RTEMS targets will build exactly the same as the
  workstation OS targets; an IOC that calls devLib will now compile,
  although it obviously won't actually work if booted.

  Any objections?

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1841692/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System