|
Home > Archive > Unix Programming > March 2005 > Unix compiling and linking options
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Unix compiling and linking options
|
|
| djake@excite.it 2005-03-30, 7:22 pm |
| COMPILING:
Is there under Unix an equivalen of pdb windows files to have
debugging symbols extern to the executable file?
LINKING:
More over, is there under Unix a linking option equivalent to
/DEBUG and /OPT:REF? (the second option in Win tell even if the linker
find /DEBUG option it should bring in only the function the program
call directly).
THANKS:
Thanks to anyone.
| |
| Paul Pluzhnikov 2005-03-30, 7:22 pm |
| djake@excite.it writes:
> Is there under Unix an equivalen of pdb windows files to have
> debugging symbols extern to the executable file?
No. The "standard" UNIX practice is to strip(1) executables before
shipping them.
> More over, is there under Unix a linking option equivalent to
> /DEBUG and /OPT:REF? (the second option in Win tell even if the linker
> find /DEBUG option it should bring in only the function the program
> call directly).
Since (for archive libraries) the linker will bring in the object
file (from the library) only if it contains referenced
functions/data, and since the object file (and not some other
"external" file) contains the debug info, I think it already works
roughly the same way as '/DEBUG /OPT:REF'.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| djake@excite.it 2005-03-31, 8:12 am |
| > No. The "standard" UNIX practice is to strip(1) executables before
> shipping them.
Ok, if I want an high speed and high performance executable (to do this
with cc I should use -O option) and have symbols included (to do this I
should use -g option) I could use both.
In this way when my customer call me saying a process crash, i get the
core files and debug in source code. Not assebler! But at the same time
my customer have an high speed and high performance process.
I can make a similar thing in Windows, but in Unix i found this
explanation in man pages:
-O
Enables the optimization phase. This phase clashes with -g
but
has lower precedence: the optimization phase is disabled if
both are specified.
So I can't use both -O and -g
Now I ask you: how can i have both the advantage of an high speed
high performance process and have symbols included for crash debugging?
Thanks very much
| |
| Chuck Dillon 2005-03-31, 6:21 pm |
| djake@excite.it wrote:
>
>
> Ok, if I want an high speed and high performance executable (to do this
> with cc I should use -O option) and have symbols included (to do this I
> should use -g option) I could use both.
> In this way when my customer call me saying a process crash, i get the
> core files and debug in source code. Not assebler! But at the same time
> my customer have an high speed and high performance process.
> I can make a similar thing in Windows, but in Unix i found this
> explanation in man pages:
>
> -O
> Enables the optimization phase. This phase clashes with -g
> but
> has lower precedence: the optimization phase is disabled if
> both are specified.
>
> So I can't use both -O and -g
>
> Now I ask you: how can i have both the advantage of an high speed
> high performance process and have symbols included for crash debugging?
>
> Thanks very much
>
As Paul mentioned the norm in the UNIX world is to ship optimized and
stripped binaries. Optimization and symbolic debugging are conflicting
needs and most compilers treat them as mutually exclusive as your man
page indicates. Any compiler that supports a compromise of
optimization and debugging capability is also going to compromise
performance. You can have the linker generate a map when you build the
production binary to help in post mortem trouble shooting.
Having said that you could try gcc whoes manpage states the following
in their description of the -g switch...
"Unlike most other C compilers, GNU CC allows you to
use `-g' with `-O'. The shortcuts taken by opti-
mized code may occasionally produce surprising results:
some variables you declared may not exist at
all; flow of control may briefly move where you did not
expect it; some statements may not be executed
because they compute constant results or their values
were already at hand; some statements may execute
in different places because they were moved out of loops."
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| Paul Pluzhnikov 2005-03-31, 6:21 pm |
| djake@excite.it writes:
> In this way when my customer call me saying a process crash, i get the
> core files and debug in source code. Not assebler!
For this to work, you'll need not only the 'core', but also a system
with the *exact* same shared libraries (patches and all), or you
would not be able to interpret the 'core'.
Some details here:
http://au.sun.com/news/onsun/2001-12/tech_tips.html
In practice, you'll be quite unlikely to be able to interpret the
'core' correctly on any system other then the one it was produced on.
What I do is ask the customer to run whatever debugger commands I
would have performed. The output, coupled with non-stripped
executable, is sufficient to understand where the crash happened.
> Now I ask you: how can i have both the advantage of an high speed
> high performance process and have symbols included for crash debugging?
Use 'gcc -g -O2 ...' as Chuck Dillon suggested.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|