guessing where address belongs to

I have large running app, and some address X, which is a
valid pointer.
I'd like to find out what object it belongs to, at least
approximately.

Is there command to have gdb guess which memory object this
address belongs to (which function ... which stack frame ..
which static
object .. which head object )?

Thanks
Yakov

On Tue, 2008-03-04 at 21:42 +0200, Eli Zaretskii wrote:
> > Date: Tue, 4 Mar 2008 10:15:42 +0200
> > From: "Yakov Lerner" <iler.mlgmail.com>
> > 
> > Is there command to have gdb guess which memory
object this
> > address belongs to (which function ... which stack
frame .. which static
> > object .. which head object )?
> 
> I think you want "info symbol".

That will help -- if the address is associated with a
symbol.
For stack and heap pointers it's not always helpful.

I don't think there is a single command to do what you want,

but "info target" will be helpful -- it will show
all loaded
sections and their memory ranges.  You can fit the address
into
one of them (if it fits).  "info file" is an alias
for this
(I think).

This shows the sections for shared libraries too, which is a
plus.


Maybe if you can mock up a spec for what it is you want, 
it wouldn't be that difficult to implement a new command
for it...

On Wed, Mar 5, 2008 at 9:51 PM, Michael Snyder
<msnyderspecifix.com> wrote:


>
>
>
> On Tue, 2008-03-04 at 21:42 +0200, Eli Zaretskii
wrote:
> > > Date: Tue, 4 Mar 2008 10:15:42 +0200
> > > From: "Yakov Lerner"
<iler.mlgmail.com>
> > >
> > > Is there command to have gdb guess which
memory object this
> > > address belongs to (which function ... which
stack frame .. which static
> > > object .. which head object )?
I meant "heap object"

>
>
>
> >
> > I think you want "info symbol".
>
> That will help -- if the address is associated with a
symbol.
> For stack and heap pointers it's not always helpful.
>
> I don't think there is a single command to do what you
want,
> but "info target" will be helpful -- it will
show all loaded
> sections and their memory ranges.  You can fit the
address into
> one of them (if it fits).  "info file" is an
alias for this
> (I think).
>
> This shows the sections for shared libraries too, which
is a plus.
>
>
> Maybe if you can mock up a spec for what it is you
want,
> it wouldn't be that difficult to implement a new
command
> for it...


Ok, I will try to spec it. Regarding guessing of the
"heap objects", I have this question:

Gdb has no integration with malloc, correct ?
Gdb has no  way of enumerating all malloced
 pieces ("heap objects"), correct ?

Or gdb does have a way of guessing which "heap
object" some address X (that points inside the heap)
belongs to ?

Yakov

"Yakov Lerner" <iler.mlgmail.com> writes:

> Gdb has no integration with malloc, correct ?
> Gdb has no  way of enumerating all malloced
>  pieces ("heap objects"), correct ?
>
> Or gdb does have a way of guessing which "heap
> object" some address X (that points inside the
heap) belongs to ?

The details are highly dependent on the malloc
implementation.  There is
no way to find that out without intimate knowledge of the
implementation.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwabsuse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg,
Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5
214B 8276 4ED5
"And now for something completely different."

On Thu, Mar 6, 2008 at 12:05 PM, Andreas Schwab
<schwabsuse.de> wrote:
> "Yakov Lerner" <iler.mlgmail.com> writes:
>
>  > Gdb has no integration with malloc, correct ?
>  > Gdb has no  way of enumerating all malloced
>  >  pieces ("heap objects"), correct ?
>  >
>  > Or gdb does have a way of guessing which
"heap
>  > object" some address X (that points inside
the heap) belongs to ?
>
>  The details are highly dependent on the malloc
implementation.  There is
>  no way to find that out without intimate knowledge of
the
>  implementation.

You don't need details of malloc guts for that.

It's enough to hook to the entry and return  from
malloc,free,realloc.

Yakov

On Thu, 2008-03-06 at 07:38 +0200, Yakov Lerner wrote:


> Ok, I will try to spec it. Regarding guessing of the 
> "heap objects", I have this question:
> 
> Gdb has no integration with malloc, correct ? 
> Gdb has no  way of enumerating all malloced 
> pieces ("heap objects"), correct ?
> 
> Or gdb does have a way of guessing which "heap 
> object" some address X (that points inside the
heap) belongs to ?


Nope -- the heap is just a big opaque blob.
GDB has no knowledge of what's inside it, and in fact
you're doing well if you can figure out where and how big
it is.

On Thu, 2008-03-06 at 11:05 +0100, Andreas Schwab wrote:
> "Yakov Lerner" <iler.mlgmail.com> writes:
> 
> > Gdb has no integration with malloc, correct ?
> > Gdb has no  way of enumerating all malloced
> >  pieces ("heap objects"), correct ?
> >
> > Or gdb does have a way of guessing which
"heap
> > object" some address X (that points inside
the heap) belongs to ?
> 
> The details are highly dependent on the malloc
implementation.  There is
> no way to find that out without intimate knowledge of
the
> implementation.

Yep, and there's no marriage between any given platform
and any given malloc implementation.  Replacing the malloc
from glibc is a fairly common thing to do, for instance.

So gdb really has no idea what's in there...

On Thu, 2008-03-06 at 12:45 +0200, Yakov Lerner wrote:
> On Thu, Mar 6, 2008 at 12:05 PM, Andreas Schwab
<schwabsuse.de> wrote:
> > "Yakov Lerner" <iler.mlgmail.com> writes:
> >
> >  > Gdb has no integration with malloc, correct
?
> >  > Gdb has no  way of enumerating all malloced
> >  >  pieces ("heap objects"), correct
?
> >  >
> >  > Or gdb does have a way of guessing which
"heap
> >  > object" some address X (that points
inside the heap) belongs to ?
> >
> >  The details are highly dependent on the malloc
implementation.  There is
> >  no way to find that out without intimate
knowledge of the
> >  implementation.
> 
> You don't need details of malloc guts for that.
> 
> It's enough to hook to the entry and return  from
malloc,free,realloc.

Yep, and there are tools that do that -- but gdb isn't one
of them.

OTOH, it would be possible to set user breakpoints at malloc
and 
free, and then write user gdb commands to collect whatever 
information you want...