AMD64 Hardware Watchpoints

AMD64 Hardware Watchpoints

[Giles Hall]

Hi,

Does gdb 6.4 support hardware watchpoints on AMD64?  If it does, why 
would gdb still be falling back to software watchpoints?  Could it be an 
alignment issue?

Thanks,
-g

Re: AMD64 Hardware Watchpoints

[Daniel Jacobowitz]

On Thu, Sep 14, 2006 at 11:04:16AM -0400, Giles Hall wrote:
> Does gdb 6.4 support hardware watchpoints on AMD64?  If it does, why 

Yes.

> would gdb still be falling back to software watchpoints?  Could it be an 
> alignment issue?

You've probably asked it to watch something that can't be watched using
a hardware watchpoint, e.g. wrong size or not in memory.  Please post
an example, and then we can see.

-- 
Daniel Jacobowitz
CodeSourcery

preserving gdb symbols

[Lee]

Sorry, one more painful shared library symbol
question.

When I have a customer's machine core, I can open the
core with something like 

gdb --readnow /usr/bin/myapp core.1234

gdb then reads the binaries to read in the needed
symtabs 

I now have every symbol in memory that I need for what
I am doing.  

Currently i have to use a script to read all of the
loaded statements, parse it, and pipe that out and tar
up all of the needed libraries so that I can get
matching binaries for shared libraries and have a
useful core to read. This is usually in the order of
60 to 100 shared libraries).  We ofcourse are doing
this on HPUX, linux (redhat and suse), and solaris. 
So getting every vendor to change their core format
while probably the best option, is not very likely.

So my question is first of all is there any way I can
just save all of the symbol information I have in
memory, so that I can reload it when reading the core
on a different machine.   

If not, then we are still stuck with always having to
have the exact shared library to read the symbols
from.
The gnu_debug_link is even worthless as u have to read
that out of the actual shared library, its not in the
core. 

I modified solib_read_symbols.  I changed it so that
if you added a switch on gdb's command line then each
time a call was made to solib_read_symbols I then kept
the file.  In my case I used the command interface to
exec tar.  A person could tack them on the end of the
core file, or create your own package in whatever
format is generally acceptable.  Would a solution of
anything like this be acceptable to get back into the
gdb source ?

Lee



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: preserving gdb symbols

[Daniel Jacobowitz]

On Thu, Sep 14, 2006 at 10:49:09AM -0700, Lee wrote:
> Currently i have to use a script to read all of the
> loaded statements, parse it, and pipe that out and tar
> up all of the needed libraries so that I can get
> matching binaries for shared libraries and have a
> useful core to read.

Just try "info shared".  It'll work even if you don't have the
libraries physically present (well, on most systems).

> So my question is first of all is there any way I can
> just save all of the symbol information I have in
> memory, so that I can reload it when reading the core
> on a different machine.   

No.  Save the files instead.

> I modified solib_read_symbols.  I changed it so that
> if you added a switch on gdb's command line then each
> time a call was made to solib_read_symbols I then kept
> the file.  In my case I used the command interface to
> exec tar.  A person could tack them on the end of the
> core file, or create your own package in whatever
> format is generally acceptable.  Would a solution of
> anything like this be acceptable to get back into the
> gdb source ?

I think you could relatively easily do this as a wrapper script
that invoked GDB.  We already ship one such (for gcore); if
you wanted to add another, I think that would be reasonable.

-- 
Daniel Jacobowitz
CodeSourcery

RE: preserving gdb symbols

[Michael Snyder]

>> So my question is first of all is there any way I can
>> just save all of the symbol information I have in
>> memory, so that I can reload it when reading the core
>> on a different machine.   
>
> No.  Save the files instead.

Actually, I have a vague nagging memory to the effect that
it used to be possible to do that.  We've been thru a number
of cycles of "what can we do about the long time it takes 
to read in symbols?"  Seems like one attempt was to read them
in once and then save them, so you could get them more-or-less
instantly on subsequent sessions.

Re: preserving gdb symbols

[Daniel Jacobowitz]

On Thu, Sep 14, 2006 at 11:14:57AM -0700, Michael Snyder wrote:
> Actually, I have a vague nagging memory to the effect that
> it used to be possible to do that.  We've been thru a number
> of cycles of "what can we do about the long time it takes 
> to read in symbols?"  Seems like one attempt was to read them
> in once and then save them, so you could get them more-or-less
> instantly on subsequent sessions.

Yes - this was what mmalloc was for.  But, the code hadn't worked in
quite a while, and has been deleted from recent versions.  I think
it still needed the actual files, though.

-- 
Daniel Jacobowitz
CodeSourcery

RE: preserving gdb symbols

[Michael Snyder]

I am not sure if I understand what your goal is.
Is it that you want to package up the core file, 
together with all (or some) of the shared libraries
on which it depends, for later debugging on a different
machine?

Seems like you could get at least some of that info
by running ldd on the exec file.  

Are you sure you need to have *all* of the shared
libraries?  

-----Original Message-----
From: gdb-owner@sourceware.org on behalf of Lee
Sent: Thu 9/14/2006 10:49 AM
To: gdb@sources.redhat.com
Subject: preserving gdb symbols
 
Sorry, one more painful shared library symbol
question.

When I have a customer's machine core, I can open the
core with something like 

gdb --readnow /usr/bin/myapp core.1234

gdb then reads the binaries to read in the needed
symtabs 

I now have every symbol in memory that I need for what
I am doing.  

Currently i have to use a script to read all of the
loaded statements, parse it, and pipe that out and tar
up all of the needed libraries so that I can get
matching binaries for shared libraries and have a
useful core to read. This is usually in the order of
60 to 100 shared libraries).  We ofcourse are doing
this on HPUX, linux (redhat and suse), and solaris. 
So getting every vendor to change their core format
while probably the best option, is not very likely.

So my question is first of all is there any way I can
just save all of the symbol information I have in
memory, so that I can reload it when reading the core
on a different machine.   

If not, then we are still stuck with always having to
have the exact shared library to read the symbols
from.
The gnu_debug_link is even worthless as u have to read
that out of the actual shared library, its not in the
core. 

I modified solib_read_symbols.  I changed it so that
if you added a switch on gdb's command line then each
time a call was made to solib_read_symbols I then kept
the file.  In my case I used the command interface to
exec tar.  A person could tack them on the end of the
core file, or create your own package in whatever
format is generally acceptable.  Would a solution of
anything like this be acceptable to get back into the
gdb source ?

Lee



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: AMD64 Hardware Watchpoints

[Giles Hall]

Daniel Jacobowitz wrote:
> You've probably asked it to watch something that can't be watched using
> a hardware watchpoint, e.g. wrong size or not in memory.  Please post
> an example, and then we can see.
>   

Thanks, this email cleared up a bunch for me!  I understand the issue a 
lot better know, it was definitely an issue of scope. 

best,
-g