This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: Regarding Map Files
- From: "Sachin O. Agrawal" <sachin_agrawal at persistent dot co dot in>
- To: "'Ian Lance Taylor'" <ian at airs dot com>
- Cc: <binutils at sources dot redhat dot com>, <ananda dot motte at philips dot com>, "'Devendra Badhani \(E-mail\)'" <deven at pspl dot co dot in>, "'Shridhar Bhat \(E-mail\)'" <penguin at pspl dot co dot in>
- Date: Fri, 21 Dec 2001 10:13:34 +0530
- Subject: RE: Regarding Map Files
- Reply-to: <sachin_agrawal at persistent dot co dot in>
> > Actually my intention is to find the functions and approximate
> > range of line numbers in sources given an address.
>
> Look at addr2line.
This works only when debugging info is available.
>
> > Usually all commercial products use logging to trace their code
> > flow in case of error at customer site. My opinion is that in
> > error conditions program itself can log stack back trace just
> > like a debugger (but within an optimized code).
>
> Note that doing a stack backtrace on optimized code is nontrivial in
> the general case. It's obviously possible, and gdb does it, but in
> general you either need debugging information to describe the stack
> frame or you need to disassemble the code to work out the stack frame.
> A running program generally doesn't have easy access to the debugging
> information, and it's hard to disassemble code backward.
>
> Of course if you are using a processor which uses a consistent frame
> pointer, and you don't compile with -fomit-frame-pointer, then it's
> not too tough.
We can compile without -fomit-frame-pointer. Since it is more beneficial
than the compile/run time and space overhead of normal logging.
As regard to processor, the specifications are already fixed at design time
for embedded systems or for appliances. x86 family as a dedicated 'ebp'
register for the same.
--
Thanks
Sachin
--