Bug 87677 - Disassembly from core files doesn't work
Summary: Disassembly from core files doesn't work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdb
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Elena Zannoni
QA Contact: Jay Turner
Depends On:
Blocks: 85605
TreeView+ depends on / blocked
Reported: 2003-04-01 04:53 UTC by Elena Zannoni
Modified: 2015-01-08 00:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-04-04 18:10:43 UTC

Attachments (Terms of Use)

Description Elena Zannoni 2003-04-01 04:53:06 UTC
Description of problem:
When reading a core file, the 'disassemble' command doesn't work, while the 'x'
command works fine.  If you run the code inside gdb you get the correct disass

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Take a RHL9 install and compile:

#include <string.h>
main (void)
  stpcpy (NULL, "dd");
  return 0;

Nothing special about stpcpy, it's a function gcc has no inlines for.
Now run it and create a core (ulimit -c unlimited is your friend).
Finally start gdb with the core file and run "disass".  The result:

(gdb) disass
Dump of assembler code for function stpcpy:
0x4207be30 <stpcpy+0>:  Cannot access memory at address 0x4207be30

Actual results:

Expected results:

Additional info:

Comment 1 Elena Zannoni 2003-04-04 18:10:43 UTC
This was a problem in the disassembly command:

--- gdb+dejagnu-20021129/gdb/disasm.c.1 Mon Mar 31 22:33:18 2003
+++ gdb+dejagnu-20021129/gdb/disasm.c   Mon Mar 31 22:35:53 2003
@@ -360,7 +360,8 @@ gdb_disassembly (struct ui_out *uiout,
       if (strcmp (target_shortname, "child") == 0
          || strcmp (target_shortname, "procfs") == 0
          || strcmp (target_shortname, "vxprocess") == 0
-         || strstr (target_shortname, "-threads") != NULL)
+         || strcmp (target_shortname, "core") == 0
+         || strstr (target_shortname, "-thread") != NULL)
        gdb_disassemble_from_exec = 0;  /* It's a child process, read inferior
mem */
        gdb_disassemble_from_exec = 1;  /* It's remote, read the exec file */

Fixed now in gdb-5.3post-0.20021129.29

Note You need to log in before you can comment on or make changes to this bug.