Re: Unix compiling and linking options
From: Paul Pluzhnikov (ppluzhnikov-nsp_at_charter.net)
Date: 03/31/05
- Next message: collinm: "Re: Problem to read on a serial port"
- Previous message: Roger Leigh: "Re: buffer/vm cache, turn off for a specific file ?"
- In reply to: djake_at_excite.it: "Re: Unix compiling and linking options"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 31 Mar 2005 07:56:28 -0800
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.
- Next message: collinm: "Re: Problem to read on a serial port"
- Previous message: Roger Leigh: "Re: buffer/vm cache, turn off for a specific file ?"
- In reply to: djake_at_excite.it: "Re: Unix compiling and linking options"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|