qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: REQEST FEEDBACK Re: How to test the performance quid c++ broker
Date Fri, 25 Jul 2014 17:13:45 GMT
On Fri, 2014-07-25 at 12:13 -0400, Alan Conway wrote:
> On Fri, 2014-07-25 at 16:47 +0100, Fraser Adams wrote:
> > ...
> > My vote would be to default to the most optimised/operational-quality 

I agree with this, but I strongly believe that operational-quality
includes debugging symbols.

Operational systems *will* have problems and without debug symbols
somewhere, core dumps are next to useless.

I think it's important to note that systems vendors usually ship
debugging symbols - I know that Red Hat do, Microsoft do, and I'm pretty
sure that Sun used to too.

Now these debugging symbols are usually not kept in the executables
themselves, but in separate files which are split apart in the product
build. For RHEL/Fedora there are -debuginfo packages that give you
source and symbols.

> ...
> > If the RelWithDebInfo is exactly as fast then that's probably OK, but if 

To be honest I wouldn't have chosen the exact default flags for the
different builds that the CMake developers have chosen - these are (for

Debug: -g
Release: -O3 -DNDEBUG
RelWithDebInfo: -O2 -g -DNDEBUG
MinsizeRel: -Os -DNDEBUG

I think it makes almost no sense to build without debugging info, so I'd
change Release to "-O3 -g -DNDEBUG". Although -O3 often makes
optimisations that confuse a debugger at least you'd get a stack trace.

My personal favourite would be "-Os -g" - Often, paradoxically, (though
you need to benchmark) optimising for space speeds up your code more
than optimising for speed. Philosophically I don't think you should ever
turn assertions off either, so I'd not include -DNDEBUG.

In any case, I think the difference between -O2 and -O3 is small. But I
strongly assert that debug symbols are an important end-user deployment
feature, for when things go wrong (and of course they will eventually).

> > I'm honest I believe that the default should really be to build 
> > something that a user might want to ship in an operational 
> > mission-critical system and I'm not personally keen on the idea of 
> > shipping with debug symbols or anything else that could potentially 
> > increase an attack vector.

I fail to see how shipping symbols to code that is open source changes
the attack surface even if you subscribe to "security by obscurity".


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message