Helping GDB to find symbols

Helping GDB to find symbols

[Jacques-Olivier Goussard]

Hi all
I hope that the proper list to send this...
I have the following pb: I shipp products with no debug information,
so when a customer has a core dump, I need to fall back on assembly
output to try to tackle the pb. 
As I have access to the source code and the debug-compiled product,
I was wondering if there was a mean to *help* GDB and provide it with
some of the debug info.
For ex, let say the prg crashed in function A, then GDB should be able
to calculate the address of the args to A in the non-debug core. Then,
finding the function in the debug-compiled library (may be with a little
help), it should be able to load the defs of the args and show the values 
of each args properly.
Is there a way to do that, or is this an enhancement to be added or is it
a totally new idea that nobody thought about before (unlikely I guess) ?
May be it can not be done ?

	Jacques-Olivier

Jacques-Olivier Goussard
Software Developer
jgoussard@nuance.com
Tel: (514) 732 4918 

Re: Helping GDB to find symbols

[Eli Zaretskii]

On Mon, 30 Apr 2001, Jacques-Olivier Goussard wrote:

> I hope that the proper list to send this...
> I have the following pb: I shipp products with no debug information,
> so when a customer has a core dump, I need to fall back on assembly
> output to try to tackle the pb. 
> As I have access to the source code and the debug-compiled product,
> I was wondering if there was a mean to *help* GDB and provide it with
> some of the debug info.

Doesn't it work to say "gdb yourprog core", where `yourprog' is the 
unstripped binary and `core' is the core file you get from your 
customers?

RE: Helping GDB to find symbols

[Jacques-Olivier Goussard]

> On Mon, 30 Apr 2001, Jacques-Olivier Goussard wrote:
> 
> > I hope that the proper list to send this...
> > I have the following pb: I shipp products with no debug information,
> > so when a customer has a core dump, I need to fall back on assembly
> > output to try to tackle the pb. 
> > As I have access to the source code and the debug-compiled product,
> > I was wondering if there was a mean to *help* GDB and provide it with
> > some of the debug info.
> 
> Doesn't it work to say "gdb yourprog core", where `yourprog' is the 
> unstripped binary and `core' is the core file you get from your 
> customers?
No. I guess it gets mixed up in the addresses and offsets. The stacktrace
for example is quite different when I switched to the non-debug to
debug binaries (exec and dynamic libraries).

	Jacques-Olivier

Re: Helping GDB to find symbols

[Andrew Cagney]

Jacques-Olivier Goussard wrote:
> 
> Hi all
> I hope that the proper list to send this...
> I have the following pb: I shipp products with no debug information,
> so when a customer has a core dump, I need to fall back on assembly
> output to try to tackle the pb.
> As I have access to the source code and the debug-compiled product,
> I was wondering if there was a mean to *help* GDB and provide it with
> some of the debug info.
> For ex, let say the prg crashed in function A, then GDB should be able
> to calculate the address of the args to A in the non-debug core. Then,
> finding the function in the debug-compiled library (may be with a little
> help), it should be able to load the defs of the args and show the values
> of each args properly.
> Is there a way to do that, or is this an enhancement to be added or is it
> a totally new idea that nobody thought about before (unlikely I guess) ?
> May be it can not be done ?

Check the command ``symbol-file'' in the user documentation.  It should
do exactly what you want.

	Andrew

RE: Helping GDB to find symbols

[Eli Zaretskii]

On Mon, 30 Apr 2001, Jacques-Olivier Goussard wrote:

> > Doesn't it work to say "gdb yourprog core", where `yourprog' is the 
> > unstripped binary and `core' is the core file you get from your 
> > customers?
> No. I guess it gets mixed up in the addresses and offsets. The stacktrace
> for example is quite different when I switched to the non-debug to
> debug binaries (exec and dynamic libraries).

Hmm?  I don't understand how is this possible: all the addresses in a
stripped program should be exactly like in an unstripped one.
Otherwise, you won't be able to debug the core dump which originated
from an unstripped program.

Am I missing something?

What is your object file format and debug info format, btw?

Re: Helping GDB to find symbols

[Eli Zaretskii]

On Mon, 30 Apr 2001, Andrew Cagney wrote:

> > For ex, let say the prg crashed in function A, then GDB should be able
> > to calculate the address of the args to A in the non-debug core. Then,
> > finding the function in the debug-compiled library (may be with a little
> > help), it should be able to load the defs of the args and show the values
> > of each args properly.
> > Is there a way to do that, or is this an enhancement to be added or is it
> > a totally new idea that nobody thought about before (unlikely I guess) ?
> > May be it can not be done ?
> 
> Check the command ``symbol-file'' in the user documentation.  It should
> do exactly what you want.

In what way is this different from "gdb program core"?  If the
difference is important, I think the manual lacks an explanation of
that difference.

RE: Helping GDB to find symbols

[Jacques-Olivier Goussard]

> From: Eli Zaretskii [ mailto:eliz@is.elta.co.il ]
> On Mon, 30 Apr 2001, Jacques-Olivier Goussard wrote:
>
> > > Doesn't it work to say "gdb yourprog core", where `yourprog' is the
> > > unstripped binary and `core' is the core file you get from your
> > > customers?
> > No. I guess it gets mixed up in the addresses and offsets. The
> stacktrace
> > for example is quite different when I switched to the non-debug to
> > debug binaries (exec and dynamic libraries).
>
> Hmm?  I don't understand how is this possible: all the addresses in a
> stripped program should be exactly like in an unstripped one.
> Otherwise, you won't be able to debug the core dump which originated
> from an unstripped program.
>
> Am I missing something?
>
> What is your object file format and debug info format, btw?

I do not think the addresses are the same in stripped and unstripped: just
run
nm on the same library for debug and non-debug build and you'll see the
symbols are not at the same address.
The symbol-file cmd may be what I need, but it's not complete: it uses the
symbols of the provided file insteed of the ones of the exec, so that you
should be able debug one lib for ex, but you lose the symbols of the rest...
I can live with that, but it would be nice to have a cmd that would just
load
as much symbol defs as possible from a set of files. For ex,
assume liba.so and libb.so contains the definitions of structures A and B.
In debug mode, gdb is able to understand
(gdb) p *(A*) <addressofaA>
(gdb) p *(B*) <addressofaB>
and display the content of address 'meaningfully'. In non debug mode, you
loose
this possibility. I just want to be able to point gdb to where it could find
the
definitions of symbol A and B, so that the 2 previous cmds will be
understood
even in non debug mode (at the best, GDB would also use them to display the
stack trace with the args to the functions disposed as in debug mode).
Does it make sense ?
	Jacques-Olivier

Re: Helping GDB to find symbols

[Andrew Cagney]

Eli Zaretskii wrote:

> > Check the command ``symbol-file'' in the user documentation.  It should
> > do exactly what you want.
> 
> In what way is this different from "gdb program core"?  If the
> difference is important, I think the manual lacks an explanation of
> that difference.

They should have the same net effect.

	Andrew

RE: Helping GDB to find symbols

[Daniel Berlin]

On Tue, 1 May 2001, Eli Zaretskii wrote:

>
> On Mon, 30 Apr 2001, Jacques-Olivier Goussard wrote:
>
> > > Doesn't it work to say "gdb yourprog core", where `yourprog' is the
> > > unstripped binary and `core' is the core file you get from your
> > > customers?
> > No. I guess it gets mixed up in the addresses and offsets. The stacktrace
> > for example is quite different when I switched to the non-debug to
> > debug binaries (exec and dynamic libraries).
>
> Hmm?  I don't understand how is this possible: all the addresses in a
> stripped program should be exactly like in an unstripped one.
> Otherwise, you won't be able to debug the core dump which originated
> from an unstripped program.

Right. I'm with you here. This makes no sense.
>
> Am I missing something?
No,. You are exactly right. He should be able to just use the debug
version with the cor efile.


Unless, of course, his non-debug versions are compiled with different
optimization flags, than his debug versions.
That would do it, I think.
>
> What is your object file format and debug info format, btw?
>

Re: Helping GDB to find symbols

[Eli Zaretskii]

> From: "Jacques-Olivier Goussard" <jgoussard@nuance.com>
> Date: Tue, 1 May 2001 09:06:05 -0400
> 
> 
> I do not think the addresses are the same in stripped and unstripped

I agree with others: this could only happen if you compiled the two
versions with different code optimization/generation switches.
Otherwise, the addresses should be identical, and you should be able
to use the core file created by the stripped executable and symbols
from an unstripped executable.

RE: Helping GDB to find symbols

[Daniel Berlin]

On Tue, 1 May 2001, Jacques-Olivier Goussard wrote:

>
>
> > From: Eli Zaretskii [ mailto:eliz@is.elta.co.il ]
> > On Mon, 30 Apr 2001, Jacques-Olivier Goussard wrote:
> >
> > > > Doesn't it work to say "gdb yourprog core", where `yourprog' is the
> > > > unstripped binary and `core' is the core file you get from your
> > > > customers?
> > > No. I guess it gets mixed up in the addresses and offsets. The
> > stacktrace
> > > for example is quite different when I switched to the non-debug to
> > > debug binaries (exec and dynamic libraries).
> >
> > Hmm?  I don't understand how is this possible: all the addresses in a
> > stripped program should be exactly like in an unstripped one.
> > Otherwise, you won't be able to debug the core dump which originated
> > from an unstripped program.
> >
> > Am I missing something?
> >
> > What is your object file format and debug info format, btw?
>
> I do not think the addresses are the same in stripped and unstripped: just
> run
> nm on the same library for debug and non-debug build and you'll see the
> symbols are not at the same address.

This is incorrect.
In fact, it's a law in gcc that using -g shouldn't change the code
generation.  They won't accept patches that violate this.

So the symbol addresses are the same.

If they aren't for you, you must be compiling the non-debug build with
optimization, and the debug build without optimization, or something of
the sort.

gdb ./debug-file core should work fine, even if the core is generated
from the non-debug versio.

I do it all the tie.

--Dan

RE: Helping GDB to find symbols

[Nicolas.Thery]

> I do not think the addresses are the same in stripped and unstripped:
just
> run
> nm on the same library for debug and non-debug build and you'll see the
> symbols are not at the same address.

What do you mean by debug and non-debug builds?

Are you sure that both builds are done with exactly the same compiler flags
(except -g)?

In particular if the non-debug build uses -O but the debug one doesn't, the
generated
code will be different and so will the symbol's addresses.

Nicolas



**********************************************************************
Symbian Ltd is a company registered in England and Wales with registered number 01796587 and registered office at 19 Harcourt Street, London, W1H 4HF, UK.
This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@symbian.com and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************