Experimental Physics and
Industrial Control System

On Jun 10, 2021, at 8:19 AM, Zimoch Dirk (PSI) <dirk.zimoch at psi.ch> wrote:

Hi Andrew,

 

I cannot use --gc-keep-exported  or --gc-sections:

unrecognized option '--gc-keep-exported'

--gc-sections and -r may not be used together

 

Adding 'MUNCH_LDFLAGS += -whole-archive' does not help because before softIoc.munch is made with the flag, softioc has already been made without it.

 

Adding 'OP_SYS_LDFLAGS += -whole-archive' works, but it applies to all *TestHarness.munch as well.

 

The size of softIoc grows only slightly but some TestHarnesses grow significantly.

 

softIoc.munch: 2.3 -> 2.5 MB

softIocPVA.munch: 8.8 -> 11 MB

caTestHarness.munch: 7.9 -> 9.1 MB

pvaTestHarness.munch: 6.4 -> 7.9 MB

pvDbTestHarness.munch: 6.5 -> 11 MB

pvdTestHarness.munch: 4.3 -> 5.1 MB

 

Comparing the two softIoc.nm files, I see the additional functions and classes, e.g. vxDev*, fdManager, epicsJob*, epicsMessageQueueReceiveWithTimeout, epicsMessageQueueSendWithTimeout, epicsTempFile, epicsThreadPool*, symFindByNameAndTypeEPICS, symFindByNameEPICS, yajl_gen_*

In particular the whole VME stuff was missing.

 

Pulling in unwanted full system libraries like libc is no issue for vxWorks. It does not implicitly link to any other libraries.

 

I finally resolved to adding this to my CONFIG_SITE.Common.vxWorksCommon:

OP_SYS_LDFLAGS += $(OP_SYS_LDFLAGS_$@)

OP_SYS_LDFLAGS_softIoc = -whole-archive

OP_SYS_LDFLAGS_softIocPVA = -whole-archive

 

Dirk

 

 

Von: Johnson, Andrew N. <anj at anl.gov> 
Gesendet: Mittwoch, 9. Juni 2021 18:46
An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Betreff: Re: softiIoc and softIocPVA incomplete on VxWorks (and others?)

 

On Jun 9, 2021, at 11:03 AM, Zimoch Dirk (PSI) <dirk.zimoch at psi.ch> wrote:

 

It has always been a problem. I used to use iocCoreLibrary.munch instead of softIoc.munch for that reason (before I found out how to fix it). I will try your suggestions tomorrow.

 

Does APS (or anyone else) use softIoc.munch from base or your own ioc App? With an ioc App the new flag should not affect you.

 

I guess we only really use them for test purposes, so maybe that wouldn’t be an issue for us. However I would still prefer that these kinds of flag go into the target-specific files in configure/os rather than the Makefiles that build soft IOCs. I suspect having them in a central place might be helpful for you too, in case someone brings in or builds a special IOC binary since they wouldn’t have to know/remember to add the flag to their Makefile.

 

Unfortunately it doesn’t look like the VxWorks 6.9 version of ld supports the --gc-keep-exported flag that Michael suggested. It does have this, but it’s not obvious if/how it’s getting enabled:

 

`--gc-sections'

`--no-gc-sections'

     Enable garbage collection of unused input sections.  It is ignored

     on targets that do not support this option.  The default behaviour

     (of not performing this garbage collection) can be restored by

     specifying `--no-gc-sections' on the command line.

 

     `--gc-sections' decides which input sections are used by examining

     symbols and relocations.  The section containing the entry symbol

     and all sections containing symbols undefined on the command-line

     will be kept, as will sections containing symbols referenced by

     dynamic objects.  Note that when building shared libraries, the

     linker must assume that any visible symbol is referenced.  Once

     this initial set of sections has been determined, the linker

     recursively marks as used any section referenced by their

     relocations.  See `--entry' and `--undefined'.

 

     This option can be set when doing a partial link (enabled with

     option `-r').  In this case the root of symbols kept must be

     explicitely specified either by an `--entry' or `--undefined'

     option or by a `ENTRY' command in the linker script.

 

- Andrew

 

 

Von: Johnson, Andrew N. <anj at anl.gov> 
Gesendet: Mittwoch, 9. Juni 2021 17:51
An: Zimoch Dirk (PSI) <dirk.zimoch at psi.ch>
Cc: EPICS core-talk <core-talk at aps.anl.gov>
Betreff: Re: softiIoc and softIocPVA incomplete on VxWorks (and others?)

 

Hi Dirk, 

On Jun 9, 2021, at 3:35 AM, Zimoch Dirk (PSI) via Core-talk <core-talk at aps.anl.gov> wrote:

 

On VxWorks, softIoc.munch and softioc.PVA.munch are statically linked. As normal with static linkage, only those symbols actually used in the program are copied into the program. While this is usually totally sufficient, it becomes a problem when the statically linked program dynamically loads plugins as possible with 'dlload' (or 'ld' on VxWorks).
Those dynamically loaded plugins may use EPICS functions that are defined but not used in EPICS Base itself, resulting in load errors like this:
Warning: module 0x76a130 holds reference to undefined symbol epicsMessageQueueReceiveWithTimeout.

I have seen this on VxWorks only, as this is the only platform where I use static linkage with dynamic loading of modules. But I guess that other platforms may be affected as well. As I have never seen any complaints about this behavior, I may be the only one who uses softIoc this way.

Anyway, the problem is easy to fix, and I would appreciate to have the fix included future EPICS releases:
Add the linker flag -whole-archive when building softIoc/softIocPVA.
I have added PROD_LDFLAGS_vxWorks = --whole-archive to modules/database/src/std/softIoc/Makefile and modules/pva2pva/pdbApp/Makefile.
Maybe this or something similar (I don't know the corresponding Windows linker flag) should be done not only for VxWorks but for all statically built versions.

 

Is there a recent change that has caused this, or has it always been a problem?

 

Could you instead try adding the --whole-archive flag to either MUNCH_LDFLAGS or OP_SYS_LDFLAGS in your Base configure/os/CONFIG_SITE.Common.vxWorksCommon file. It’s only your site which needs that flag, and I don’t know what effect it will have on the memory needed by our VxWorks IOCs (APS does not use dynamic loading of plugins on any IOC architecture).

 

- Andrew

 

-- 

Complexity comes for free, simplicity you have to work for.

 

-- 

Complexity comes for free, simplicity you have to work for.