From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-43138-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 6613 invoked by alias); 19 Mar 2014 17:50:18 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 6595 invoked by uid 89); 19 Mar 2014 17:50:16 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2
X-HELO: mtaout20.012.net.il
Received: from mtaout20.012.net.il (HELO mtaout20.012.net.il) (80.179.55.166) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Mar 2014 17:50:14 +0000
Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0N2P00L002R79L00@a-mtaout20.012.net.il> for gdb@sourceware.org; Wed, 19 Mar 2014 19:50:11 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N2P00K222VNLUB0@a-mtaout20.012.net.il> for gdb@sourceware.org; Wed, 19 Mar 2014 19:50:11 +0200 (IST)
Date: Wed, 19 Mar 2014 17:50:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: "disassemble" shows code, but not with /m
To: gdb@sourceware.org
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <83y50684dd.fsf@gnu.org>
X-IsSubscribed: yes
X-SW-Source: 2014-03/txt/msg00055.txt.bz2

Did anyone bump into something like below with GDB 7.7?
SUBRP is an inline function defined on the header file lisp.h in
Emacs:

  INLINE bool
  SUBRP (Lisp_Object a)
  {
    return PSEUDOVECTORP (a, PVEC_SUBR);
  }


Trying to disassemble it, I get these results:

  (gdb) disassemble 0x10f3110,+30
  Dump of assembler code from 0x10f3110 to 0x10f312e:
     0x010f3110 <SUBRP+0>:        push   %ebp
     0x010f3111 <SUBRP+1>:        mov    %esp,%ebp
     0x010f3113 <SUBRP+3>:        sub    $0x8,%esp
     0x010f3116 <SUBRP+6>:        movl   $0xa,0x4(%esp)
     0x010f311e <SUBRP+14>:       mov    0x8(%ebp),%eax
     0x010f3121 <SUBRP+17>:       mov    %eax,(%esp)
     0x010f3124 <SUBRP+20>:       call   0x10f306f <PSEUDOVECTORP>
     0x010f3129 <SUBRP+25>:       leave
     0x010f312a <SUBRP+26>:       ret
     0x010f312b <COMPILEDP+0>:    push   %ebp
     0x010f312c <COMPILEDP+1>:    mov    %esp,%ebp
  End of assembler dump.
  (gdb) disassemble 0x10f3110
  Dump of assembler code for function SUBRP:
     0x010f3110 <+0>:     push   %ebp
     0x010f3111 <+1>:     mov    %esp,%ebp
     0x010f3113 <+3>:     sub    $0x8,%esp
     0x010f3116 <+6>:     movl   $0xa,0x4(%esp)
     0x010f311e <+14>:    mov    0x8(%ebp),%eax
     0x010f3121 <+17>:    mov    %eax,(%esp)
     0x010f3124 <+20>:    call   0x10f306f <PSEUDOVECTORP>
     0x010f3129 <+25>:    leave
     0x010f312a <+26>:    ret
  End of assembler dump.
  (gdb) disassemble 'lisp.h'::SUBRP
  Dump of assembler code for function SUBRP:
     0x010f3110 <+0>:     push   %ebp
     0x010f3111 <+1>:     mov    %esp,%ebp
     0x010f3113 <+3>:     sub    $0x8,%esp
     0x010f3116 <+6>:     movl   $0xa,0x4(%esp)
     0x010f311e <+14>:    mov    0x8(%ebp),%eax
     0x010f3121 <+17>:    mov    %eax,(%esp)
     0x010f3124 <+20>:    call   0x10f306f <PSEUDOVECTORP>
     0x010f3129 <+25>:    leave
     0x010f312a <+26>:    ret
  End of assembler dump.

But:

  (gdb) disassemble /m 0x10f3110
  Dump of assembler code for function SUBRP:
  End of assembler dump.
  (gdb) disassemble /m 0x10f3110,+30
  Dump of assembler code from 0x10f3110 to 0x10f312e:
  End of assembler dump.
  (gdb) disassemble /m 'lisp.h'::SUBRP
  Dump of assembler code for function SUBRP:
  End of assembler dump.
  (gdb)

IOW, the /m switch somehow inhibits the disassembly.  FWIW, using x/i
for the respective addresses shows the instructions just fine.

Is this a bug?