Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021 
<== Date ==> <== Thread ==>

Subject: RE: EPICS base mods
From: <freddie.akeroyd@stfc.ac.uk>
To: <anj@aps.anl.gov>
Cc: core-talk@aps.anl.gov
Date: Fri, 9 Dec 2016 16:48:45 +0000
Sorry - wrong link, should be https://msdn.microsoft.com/en-us/library/aa260783(VS.60).aspx

Freddie

-----Original Message-----
From: Akeroyd, Freddie (STFC,RAL,ISIS) 
Sent: 09 December 2016 16:47
To: 'Andrew Johnson'
Cc: EPICS core-talk
Subject: RE: EPICS base mods

Hi Andrew,

I've generally used pdb files recently as the debug information is then separate from the main program file you have a choice if you wish to install it, but it's also there somewhere if you need to load it in a debugger later and you can also store them on a separate "symbol server" for debugger use. You can embed pretty much the same information directly inside the object file itself though, this article lists the different sorts of things that can get included with the various options available:
 
https://msdn.microsoft.com/en-us/library/windows/desktop/ee416588(v=vs.85).aspx

Epics currently builds pdb files in debug mode on windows with Visual Studio, but leaves then in the O.* directory. My motivation for wishing to include them (or some other debugging information) in release/optimised builds too stemmed from a recent issue I had with a pcaspy crash on one machine here, the version of pcaspy from PyPi had no debugging information so I was unable to tell from the debugger traceback where in the bundled CA library it came from. I built it locally in release mode with debug symbols, but got no crash of course. If it would be preferred to keep the default release build small, then I think it would be useful to have something like a site configuration macro to enable "add debug symbols with optimise " to make it easy to add and deploy the additional debugger information.      

I hadn't really thought about cross comping for windows, but I agree that any pdb rules would need to be tied to visual studio only. Your suggested ENABLE_PDB option in (4) sounds a good way to do this. 

1. I did a couple of dll release builds of epics base on my desktop with and without pdb, with pdb it took 6 minutes and without it took about 30 seconds less. There is more than just compiling going on in epics base, but it doesn't look to have added too large an overall overhead on my desktop. The main thing you notice is disk space, pdb files can be quite big e.g. Com.dll  300kB  Com.pdb 2MB 
  
2. Thanks 

3. No problem

4. If you have created a pdb file you probably want to install it, so associating /Zi and ENABLE_PDB make sense. I say "probably want to install" as if you are debugging on your own desktop, it will pick up the pdb from O.* anyway, but if you only deploy "bin" etc to the beamlines then you would then be missing the pdb files without an install to bin rule. 

Regards,

Freddie

-----Original Message-----
From: Andrew Johnson [mailto:anj@aps.anl.gov]
Sent: 08 December 2016 22:26
To: Akeroyd, Freddie (STFC,RAL,ISIS)
Cc: EPICS core-talk
Subject: Re: EPICS base mods

Hi Freddie,

On 12/07/2016 05:22 PM, freddie.akeroyd@stfc.ac.uk wrote:
> I've added a couple of local mods we have to a PR against my GitHub 
> fork of epics base which I wonder if you might consider for the 
> official epics base release
> 
> https://github.com/FreddieAkeroyd/epics-base/pull/1
> 
> * one is just a simple buffer too small fix (which did actually cause 
> me a crash when I mistyped something in a gateway access security
> file)

Fixed - I actually bumped it to 40 characters. That change will be in the final Base-3.14.12.6 and Base-3.15.5 releases next week.

> * I find it very useful to always build and install pdb files on 
> windows, and include rules for this. At the moment the install 
> decision is based on an INSTALL_PDB macro
> * (I've also generated some additional /NODEFAULTLIB flags that I 
> found useful, but they may a bit risky to deploy without more 
> widespread testing)

We support cross-building Windows applications on Linux using MinGW, and I'm not sure how some of your changes might affect that build configuration, since GCC doesn't generate .pdb files. I think we're a bit too close to the release to merge these more intrusive changes, although I'm not rejecting them out-right. As I don't often develop on Windows I don't know much about pdb files; if they're useful I don't object to building and installing them, but would it make sense to have them be optional?

I do have a few specific questions/comments:

1. What are the build-time implications of creating pdb files? I'm fine with creating them when HOST_OPT=NO, which is meant to be the debug configuration, but I'm not quite so convinced about doing that when HOST_OPT=YES if they're going to slow down the compile/link steps.

2. Your STATIC_LDFLAGS_EXTRA_YES/NO variables can be named just STATIC_LDFLAGS_YES/NO instead; the win32 config file is overriding a setting in CONFIG_COMMON that already chooses between those two based on the value of HOST_OPT.

3. I need to think a bit about your RULES_BUILD changes. I would prefer to keep the install rules generic if possible, so I'll see if I can work out an alternative approach which doesn't require adding .exe rules.

4. The name of your switch INSTALL_PDB is perilously close to the usage in RULES_FILE_TYPE so I'll probably want to modify that name to call it something else (it might make sense to use it to enable the -Zi flags too, so something like ENABLE_PDB may be a better choice).

Thanks,

- Andrew

--
Arguing for surveillance because you have nothing to hide is no different than making the claim, "I don't care about freedom of speech because I have nothing to say." -- Edward Snowdon


References:
Re: EPICS base mods Andrew Johnson
RE: EPICS base mods freddie.akeroyd

Navigate by Date:
Prev: RE: EPICS base mods freddie.akeroyd
Next: Build failed in Jenkins: epics-base-3.15 #299 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021 
Navigate by Thread:
Prev: RE: EPICS base mods freddie.akeroyd
Next: Build failed in Jenkins: epics-base-3.15 #299 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021 
ANJ, 09 Dec 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·