public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3
@ 2015-01-15 15:21 ganzmatthias at hotmail dot com
  2015-01-15 16:32 ` [Bug gdb/17846] " gbenson at redhat dot com
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: ganzmatthias at hotmail dot com @ 2015-01-15 15:21 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17846

            Bug ID: 17846
           Summary: read memory from _dl_debug_state returns 0xcc instead
                    of 0xf3
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: ganzmatthias at hotmail dot com

Created attachment 8065
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8065&action=edit
Small example to reproduce the issue with some information about my environment

When trying to read one byte from _dl_debug_state (I try to read and analyse
arbitrary code loaded into my memory) the behavior of my program is different
depending on whether I run it with gdb or not.

Memory at symbol _dl_debug_state (which is at a fixed address 0x7ffff7dea970
for my system) starts with the values 0xf3 c3. Which corresponds to a "repz
ret" instruction. When i try to read the very first byte of this symbol I read
0xCC (which corresponds to a int3 instruction) instead of 0xF3.

However when I inspect the memory address with gdb as following, I get the
correct value 0xf3.

(gdb) x/1bx 0x7ffff7dea970
0x7ffff7dea970 <_dl_debug_state>:    0xf3

But my program accidentally seems to read the trap instruction instead of the
actual memory value.

The attached archive contains a small example, the compiled binary and a log
how to reproduce the issue.

If I run the binary on its own everything is fine but if it is run within gdb I
get the previously described error.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gdb/17846] read memory from _dl_debug_state returns 0xcc instead of 0xf3
  2015-01-15 15:21 [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3 ganzmatthias at hotmail dot com
@ 2015-01-15 16:32 ` gbenson at redhat dot com
  2015-01-15 16:35 ` palves at redhat dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: gbenson at redhat dot com @ 2015-01-15 16:32 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17846

Gary Benson <gbenson at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |gbenson at redhat dot com
         Resolution|---                         |INVALID

--- Comment #1 from Gary Benson <gbenson at redhat dot com> ---
This is not a bug.  GDB implements breakpoints by overwriting whatever is at
the relevant addresses with int3 instructions on x86 when the inferior program
is running.  When the inferior stops the int3 instructions are replaced with
whatever was there before.  So, when your program is running you see 0xCC at
that address, but when you stop it you see 0xF3.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gdb/17846] read memory from _dl_debug_state returns 0xcc instead of 0xf3
  2015-01-15 15:21 [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3 ganzmatthias at hotmail dot com
  2015-01-15 16:32 ` [Bug gdb/17846] " gbenson at redhat dot com
@ 2015-01-15 16:35 ` palves at redhat dot com
  2015-01-15 17:02 ` ganzmatthias at hotmail dot com
  2015-01-15 17:33 ` palves at redhat dot com
  3 siblings, 0 replies; 5+ messages in thread
From: palves at redhat dot com @ 2015-01-15 16:35 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17846

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #2 from Pedro Alves <palves at redhat dot com> ---
In addition, from GDB, you'll also see 0xF3 when the program is running, as GDB
hides its own breakpoints from the user.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gdb/17846] read memory from _dl_debug_state returns 0xcc instead of 0xf3
  2015-01-15 15:21 [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3 ganzmatthias at hotmail dot com
  2015-01-15 16:32 ` [Bug gdb/17846] " gbenson at redhat dot com
  2015-01-15 16:35 ` palves at redhat dot com
@ 2015-01-15 17:02 ` ganzmatthias at hotmail dot com
  2015-01-15 17:33 ` palves at redhat dot com
  3 siblings, 0 replies; 5+ messages in thread
From: ganzmatthias at hotmail dot com @ 2015-01-15 17:02 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17846

--- Comment #3 from ganzmatthias <ganzmatthias at hotmail dot com> ---
(In reply to Gary Benson from comment #1)
> This is not a bug.  GDB implements breakpoints by overwriting whatever is at
> the relevant addresses with int3 instructions on x86 when the inferior
> program is running.  When the inferior stops the int3 instructions are
> replaced with whatever was there before.  So, when your program is running
> you see 0xCC at that address, but when you stop it you see 0xF3.



> So, when your program is running
> you see 0xCC at that address, but when you stop it you see 0xF3.

So I can not reliably debug programs which read code which may contain
breakpoints (either created by me during the debug session or created by gdb
internaly)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Bug gdb/17846] read memory from _dl_debug_state returns 0xcc instead of 0xf3
  2015-01-15 15:21 [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3 ganzmatthias at hotmail dot com
                   ` (2 preceding siblings ...)
  2015-01-15 17:02 ` ganzmatthias at hotmail dot com
@ 2015-01-15 17:33 ` palves at redhat dot com
  3 siblings, 0 replies; 5+ messages in thread
From: palves at redhat dot com @ 2015-01-15 17:33 UTC (permalink / raw)
  To: gdb-prs

https://sourceware.org/bugzilla/show_bug.cgi?id=17846

--- Comment #4 from Pedro Alves <palves at redhat dot com> ---
I don't know what you mean by reliably.  What would you like GDB to do?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-01-15 17:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-15 15:21 [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3 ganzmatthias at hotmail dot com
2015-01-15 16:32 ` [Bug gdb/17846] " gbenson at redhat dot com
2015-01-15 16:35 ` palves at redhat dot com
2015-01-15 17:02 ` ganzmatthias at hotmail dot com
2015-01-15 17:33 ` palves at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).