RE: Regarding Map Files

RE: Regarding Map Files

[Sachin O. Agrawal]

Hi

We have two options. One is clear and we are using it. i.e.
Program logs its own flow to debug log which can be enabled
and disabled. There are some problems with this approach

1) Size of debug log. Its cumbersome for support engineer
   or customer to enable logging, duplicate bug and ship
   the huge logs to developer site. Further its a pain
   for developers to trace log entries.

2) Bug which appears while logging is off may not appear
   when the same is enabled even though it can be
   duplicated.

3) Size of executables.

Second approach is that when program finds an error condition
or OS reports to it through signals, programs calls an internal
function which then only logs few numbers which are nothing
but return addresses on the stack. These numbers will be emitted
only in case of bugs. They are definitely shorter than the core dump
given by OS. I agree the core dump already contains these numbers
we are interested in. This is the first obstacle in this approach.

Now second obstacle is that once we have these numbers corresponding
to an optimized executable, is it possible to figure out approximate
range of line numbers in the source code.

Utilities like 'gdb' and 'addr2line' gives this information if these
numbers correspond to the unoptimized executables with debugging info.
For optimized versions can one use map files generated by linker?

First obstacle has a solution in Windows as there is a specific call
for getting stack trace. For second obstacle one need to manually
trace the map files generated by VC++ linker. A tool can be easily
written for the same.

--
Thanks
Sachin
--



> -----Original Message-----
> From: Shridhar Bhat [mailto:penguin@pspl.co.in]
> Sent: Thursday, December 20, 2001 7:28 PM
> To: Sachin O. Agrawal
> Cc: Devendra Badhani (E-mail)
> Subject: RE: Regarding Map Files
> 
> 
> Hi Sachin,
> 
> If the program can detect error conditions on its own then you
> could definitely do this. But the problem is that when the
> program does something wrong, in most cases, it is the OS
> which detects this error and creates the core dump. So, program
> would have no way to figure this out. If you could modify the
> OS (or the run time system) to send a special signal to the 
> program, which the program could catch and intelligently 
> create its own stack trace, then it would work.
> 
> Correct me if I am wrong.
> 
> -Shridhar.
> 
> On Thu, 20 Dec 2001, Sachin O. Agrawal wrote:
> 
> :>Hello,
> :>
> :>Actually my intention is to find the functions and approximate
> :>range of line numbers in sources given an address.
> :>
> :>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).
> :>
> :>Support engineer or customer will mail these numbers instead of
> :>big and huge core dump to the developers. Developers will then
> :>trace out using map files the backtrace. I agree this trace
> :>won't be as accurate as backtrace reported by debugger but
> :>at least it is better than huge logging.
> :>
> :>--
> :>Thanks
> :>Sachin
> :>--
> :>
> :>
> :>-----Original Message-----
> :>From: ananda.motte@philips.com [mailto:ananda.motte@philips.com]
> :>Sent: Thursday, December 20, 2001 6:34 PM
> :>To: sachin_agrawal@persistent.co.in
> :>Subject: Re: Regarding Map Files
> :>
> :>
> :>
> :>Basically it tells you in what portions of memory your 
> .text .rodata .bss
> :>.data and other sections (read GNU manual) and their 
> respective symbol
> :>contents are loaded and relocated to in case your image 
> address is different
> :>from the load address.
> :>
> :>Ir Motte dit Falisse Ananda
> :>Embedded Software Engineer
> :>Portable Audio
> :>Philips Semiconductors Leuven, Belgium
> :>
> :>> -----Original Message-----
> :>> From: Sachin O. Agrawal [mailto:sachin_agrawal@persistent.co.in]
> :>> Sent: Thursday, December 20, 2001 6:05 PM
> :>> To: 'binutils@sources.redhat.com'
> :>> Subject: Regarding Map Files
> :>>
> :>>
> :>> Hello,
> :>>
> :>> With -M or -Map option to the ld linker, we can create a map file.
> :>> Does any one knows how to interpret them?
> :>>
> :>> --
> :>> Thanks
> :>> Sachin
> :>> --
> :>
> :>
> 
> 

Re: Regarding Map Files

[Ian Lance Taylor]

"Sachin O. Agrawal" <sachin_agrawal@persistent.co.in> writes:

> I am able to generate a map file and interpret the same.
> Is there already a tool which can parse these files and
> provide me the information I need?

No.

Ian

RE: Regarding Map Files

[Sachin O. Agrawal]

> If that is unacceptable for some reason, then you can indeed use the
> map file to map addresses to functions.  Personally, I think the
> format is pretty obvious, but then I'm obviously biased.  Each output
> section is listed starting in column 0, with name, VMA, and size.
> Each input section is listed starting in column 1 with section name,
> VMA, size, and input file name.  Each global symbol is listed with
> nothing in the first column, then the VMA and the symbol name.
>
> Just pick some address, and find it in the map file.  You'll see the
> file and section it came from, and the global symbols from that file
> with their address.

I am able to generate a map file and interpret the same.
Is there already a tool which can parse these files and
provide me the information I need?

> If you still don't get it, ask a specific question rather than a
> general one.

Thanks!!! Ian. At least now I am sure that this is possible.
Please go through a separate thread regarding stack back trace.

--
Thanks
Sachin
--

Re: Regarding Map Files

[Ian Lance Taylor]

"Sachin O. Agrawal" <sachin_agrawal@persistent.co.in> writes:

> > > 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.

My understanding is that you want to get the stack backtrace from
units in the field, which you then analyze yourself.  So just build
the executable with full debugging information, and then strip the
version that you send out.  When you get a stack backtrace from the
field, use the executable you saved which has the full debugging
information.

If that is unacceptable for some reason, then you can indeed use the
map file to map addresses to functions.  Personally, I think the
format is pretty obvious, but then I'm obviously biased.  Each output
section is listed starting in column 0, with name, VMA, and size.
Each input section is listed starting in column 1 with section name,
VMA, size, and input file name.  Each global symbol is listed with
nothing in the first column, then the VMA and the symbol name.

Just pick some address, and find it in the map file.  You'll see the
file and section it came from, and the global symbols from that file
with their address.

If you still don't get it, ask a specific question rather than a
general one.

Ian

RE: Regarding Map Files

[Sachin O. Agrawal]

> > 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
--

Re: Regarding Map Files

[Ian Lance Taylor]

"Sachin O. Agrawal" <sachin_agrawal@persistent.co.in> writes:

> Actually my intention is to find the functions and approximate
> range of line numbers in sources given an address.

Look at addr2line.

> 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.

Ian

RE: Regarding Map Files

[Sachin O. Agrawal]

Hello,

Actually my intention is to find the functions and approximate
range of line numbers in sources given an address.

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).

Support engineer or customer will mail these numbers instead of
big and huge core dump to the developers. Developers will then
trace out using map files the backtrace. I agree this trace
won't be as accurate as backtrace reported by debugger but
at least it is better than huge logging.

--
Thanks
Sachin
--


-----Original Message-----
From: ananda.motte@philips.com [mailto:ananda.motte@philips.com]
Sent: Thursday, December 20, 2001 6:34 PM
To: sachin_agrawal@persistent.co.in
Subject: Re: Regarding Map Files



Basically it tells you in what portions of memory your .text .rodata .bss
.data and other sections (read GNU manual) and their respective symbol
contents are loaded and relocated to in case your image address is different
from the load address.

Ir Motte dit Falisse Ananda
Embedded Software Engineer
Portable Audio
Philips Semiconductors Leuven, Belgium

> -----Original Message-----
> From: Sachin O. Agrawal [mailto:sachin_agrawal@persistent.co.in]
> Sent: Thursday, December 20, 2001 6:05 PM
> To: 'binutils@sources.redhat.com'
> Subject: Regarding Map Files
>
>
> Hello,
>
> With -M or -Map option to the ld linker, we can create a map file.
> Does any one knows how to interpret them?
>
> --
> Thanks
> Sachin
> --

Regarding Map Files

[Sachin O. Agrawal]

Hello,

With -M or -Map option to the ld linker, we can create a map file.
Does any one knows how to interpret them?

--
Thanks
Sachin
--