This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3
- From: "ganzmatthias at hotmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 15 Jan 2015 15:21:01 +0000
- Subject: [Bug gdb/17846] New: read memory from _dl_debug_state returns 0xcc instead of 0xf3
- Auto-submitted: auto-generated
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.