Experimental Physics and
Industrial Control System

Rong Huang via Tech-talk <tech-talk at aps.anl.gov> · Wed, 20 Dec 2023 14:38:48 -0600

I chose to set the arch in EPICS modules as "linux-arm" because I
thought in the earlier version of EPICS base (3.14.12.8), there is
only the option of linux-arm, and it does not recognize aarch64.

Rong

On Wed, Dec 20, 2023 at 2:05 PM Érico Nogueira Rolim
<erico.rolim at lnls.br> wrote:
>
> On 20/12/2023 15:29, Mark Rivers wrote:
> > This is the command that compiles asynPortDriver.cpp, which is where the try/catch block is:
> >
> > /usr/bin/g++ -c  -D_GNU_SOURCE -D_DEFAULT_SOURCE           -DUNIX  -Dlinux     -O3 -g   -Wall           -fPIC -MMD -I. -I../O.Common -I. -I../../asyn/drvAsynSerial/os/Linux -I../../asyn/drvAsynSerial/os/default -I.. -I../../asyn/asynDriver -I../../asyn/asynGpib -I../../asyn/drvAsynSerial -I../../asyn/interfaces -I../../asyn/miscellaneous -I../../asyn/asynPortDriver/exceptions -I../../asyn/asynPortDriver -I../../asyn/asynPortClient -I../../asyn/devEpics -I../../asyn/asynRecord -I../../asyn/vxi11 -I../../asyn/gsIP488 -I../../asyn/ni1014 -I../../asyn/devGpib -I../../include/os/Linux -I../../include    -I/epicsioc/used/epics/synApps/ipac-2-15/include  -I/epicsioc/used/epics/synApps/seq-2-2-7/include -I/epicsioc/used/epics/base-3.14.12.8/include/os/Linux -I/epicsioc/used/epics/base-3.14.12.8/include      -I/usr/include/tirpc  ../../asyn/asynPortDriver/asynPortDriver.cpp
> >
> > This is the output when it builds the testAsynPortDriver application:
> >
> > /usr/bin/g++ -o testAsynPortDriver  -L/epicsioc/used/epics/synApps_5_8_3_14_8/asyn-R4-30/lib/linux-arm -L/epicsioc/used/epics/base-3.14.12.8/lib/linux-arm -Wl,-rpath,/epicsioc/used/epics/synApps_5_8_3_14_8/asyn-R4-30/lib/linux-arm -Wl,-rpath,/epicsioc/used/epics/base-3.14.12.8/lib/linux-arm                     testAsynPortDriver_registerRecordDeviceDriver.o testAsynPortDriverMain.o    -ltestAsynPortDriverSupport -lasyn -lrecIoc -lsoftDevIoc -lmiscIoc -lrsrvIoc -ldbtoolsIoc -lasIoc -ldbIoc -lregistryIoc -ldbStaticIoc -lca -lCom
> >
> > I don't see anything unusual here, these look like the standard options.
>
>
> One I thing I noticed, though I don't think it should matter, is that
> the build is defining the arch as "linux-arm", even though this is an
> aarch64 machine, as can be seen in the GDB output (size of pointers,
> location of libraries and name of debug packages for libraries). The
> version of epics-base in use doesn't seem to be aware of aarch64 at all.
>
>
>  > 0x0000fffff78d6650 in __pthread_kill_implementation () from
> /usr/lib64/libc.so.6
>
>  > ...
>
>  > glibc-2.34-83.el9_3.7.aarch64 keyutils-libs-1.6.3-1.el9.aarch64
>
>
> >
> > I will be very interested to see what happens when you run the exact same versions of each module on the linux-x86_64 architecture, rather than linux-arm.
> >
> > Mark
> >
> > -----Original Message-----
> > From: Rong Huang <ronghuang at ls-cat.org>
> > Sent: Wednesday, December 20, 2023 11:45 AM
> > To: Mark Rivers <rivers at cars.uchicago.edu>
> > Cc: Érico Nogueira Rolim <erico.rolim at lnls.br>; tech-talk at aps.anl.gov
> > Subject: Re: quadEM-R7-0 ParamValNotDefined
> >
> > Hello Mark,
> >
> > The attached file is the complete output of a "re-compiling" of asyn-R4-30.
> >
> > Thanks,
> > Rong
> >
> > On Wed, Dec 20, 2023 at 10:22 AM Mark Rivers <rivers at cars.uchicago.edu> wrote:
> >> Rong,
> >>
> >> Can you send the complete output when rebuilding the asyn module?  We can then see what compiler flags are being used.
> >>
> >> Mark
> >>
> >>
> >> -----Original Message-----
> >> From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Rong Huang via Tech-talk
> >> Sent: Wednesday, December 20, 2023 9:59 AM
> >> To: Érico Nogueira Rolim <erico.rolim at lnls.br>
> >> Cc: tech-talk at aps.anl.gov
> >> Subject: Re: quadEM-R7-0 ParamValNotDefined
> >>
> >> Perhaps this information is related to your conversation. In my VM, the printout of "g++ --version" is:
> >>
> >> g++ (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2)
> >> Copyright (C) 2021 Free Software Foundation, Inc.
> >> This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >>
> >> Thanks,
> >> Rong
> >>
> >> On Wed, Dec 20, 2023 at 6:40 AM Érico Nogueira Rolim <erico.rolim at lnls.br> wrote:
> >>> On 20/12/2023 06:34, Ralph Lange via Tech-talk wrote:
> >>>
> >>> On Wed, 20 Dec 2023 at 01:23, Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> wrote:
> >>>>
> >>>>
> >>>> Note that it is calling paramVal::getInteger in a try/catch block that explicitly catches the exception you are getting, ParamValNotDefined.  So I don't understand why this is causing your program to terminate, rather than simply catching the error and return and error status.
> >>>>
> >>>>
> >>>>
> >>>> It seems like perhaps there is something different about the way C++ exception handling works with the linux-arm architecture?  No one has ever reported this error before, but most people are using linux-x86_64.
> >>>
> >>> Just poking...
> >>>
> >>> Inside the ARM toolchain doc [1] I found that
> >>>> The ARM compilation tools fully support C++ exception handling. However, the compiler does not support this by default. You must enable C++ exception handling with the --exceptions option.
> >>> Far too obvious to be the cause, is it?
> >>>
> >>>
> >>> I don't think that it would be, because any reasonable Linux ARM system would be using GNU (or Clang) compilers, not the ARM compiler suite. "--exceptions" doesn't look like a GCC option either, and Linux userspace as a whole would be broken if built with "-fno-exceptions".
> >>>
> >>>
> >>>
> >>> Cheers,
> >>> ~Ralph
> >>>
> >>> [1] https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-Details/C---exception-handling#:~:text=The%20ARM%20compilation%20tools%20fully,%2D%2Dno_exceptions%20for%20more%20information.
> >>>
> >>>
> >>>
> >>> Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
> >>>
> >>> Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.
>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System