From: "Kevin D. Kissell" <kevink@mips.com>
To: "Fuxin Zhang" <fxzhang@ict.ac.cn>
Cc: <linux-mips@linux-mips.org>
Subject: Re: Strange instruction
Date: Thu, 14 Oct 2004 13:13:11 +0200 [thread overview]
Message-ID: <002f01c4b1de$cb80abc0$10eca8c0@grendel> (raw)
In-Reply-To: 416E5B62.8050508@ict.ac.cn
Sorry about that disinformation. The man page doesn't provide
the necessary details - but running "objdump -H" does (and the
-H help option *is* called out in the man page).
----- Original Message -----
From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
To: "Kevin D. Kissell" <kevink@mips.com>
Sent: Thursday, October 14, 2004 12:56
Subject: Re: Strange instruction
>
>
> Kevin D. Kissell wrote:
>
> >In all fairness, the syntax is in he "man" page for objdump, so
> >
> >
> The man page does mention the option -m
>
> -m machine
> --architecture=machine
> Specify the architecture to use when disassembling object
> files.
> This can be useful when disassembling object files which
> do not
> describe architecture information, such as S-records. You
> can list
> the available architectures with the -i option.
> but it does not mention how to specify a machine, although I did
> find it in
> objdump --help later:)
>
> debian GNU objdump 2.14.90.0.7 20031029
>
> >one doesn't really have to read the sources to figure it out!
> >But the question of whether the default mode of objdump
> >should be the minimum 32-bit legacy instruction set is a good
> >one. Not many currenly used MIPS processors are MIPS I.
> >I understand that disassembling advanced instructions that are
> >not supported by a particular CPU as if they were normal can
> >cause confusion and error, but perhaps the default would be to
> >disassmble everything as MIPS64 rev 2, but with all instructions
> >that are not in MIPS I flagged somehow, perhaps with a message
> >after the assembly code to indicate the extended ISA level? e.g.
> >
> >a0000650: 07400003 bltz k0,a0000660 <nmi_handler+0x1c>
> >a0000654: 03a0d82d move k1,sp *mips3*
> >a0000658: 3c1ba020 lui k1,0xa020
> >
> >Where specifying -m mips:isa64 or -m mips:4000 would suppress the warnings
> >on MIPS64 or MIPS III instructions respectively. Just a thought...
> >
> >----- Original Message -----
> >From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
> >To: "Dmitriy Tochansky" <toch@dfpost.ru>
> >Cc: <linux-mips@linux-mips.org>
> >Sent: Thursday, October 14, 2004 10:45
> >Subject: Re: Strange instruction
> >
> >
> >
> >
> >>objdump -d -mmips:4000 vmlinux to force it regconize all MIPS III
> >>instructions
> >>
> >>I think this option should be renamed( i had try -mips3 -mmips3 etc.
> >>before i find it
> >>by reading the source code)
> >> or the default should be changed.
> >>
> >>Dmitriy Tochansky wrote:
> >>
> >>
> >>
> >>>Hello!
> >>>
> >>>When starts kernel for my au1500 board reseting board. After disassembling I found instruction
> >>>which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
> >>>
> >>>---
> >>>
> >>>a0000650: 07400003 bltz k0,a0000660 <nmi_handler+0x1c>
> >>>a0000654: 03a0d82d 0x3a0d82d
> >>>a0000658: 3c1ba020 lui k1,0xa020
> >>>
> >>>---
> >>>
> >>>Base address changed by me.
> >>>
> >>>What is A0000654? There is board resets.
> >>>
> >>>
> >
> >
> >
> >
>
WARNING: multiple messages have this Message-ID (diff)
From: "Kevin D. Kissell" <kevink@mips.com>
To: Fuxin Zhang <fxzhang@ict.ac.cn>
Cc: linux-mips@linux-mips.org
Subject: Re: Strange instruction
Date: Thu, 14 Oct 2004 13:13:11 +0200 [thread overview]
Message-ID: <002f01c4b1de$cb80abc0$10eca8c0@grendel> (raw)
Message-ID: <20041014111311.SpGPztCA6NsiG0A4BwAHJvOUxgTtOtCH7catCL9nNto@z> (raw)
In-Reply-To: 416E5B62.8050508@ict.ac.cn
Sorry about that disinformation. The man page doesn't provide
the necessary details - but running "objdump -H" does (and the
-H help option *is* called out in the man page).
----- Original Message -----
From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
To: "Kevin D. Kissell" <kevink@mips.com>
Sent: Thursday, October 14, 2004 12:56
Subject: Re: Strange instruction
>
>
> Kevin D. Kissell wrote:
>
> >In all fairness, the syntax is in he "man" page for objdump, so
> >
> >
> The man page does mention the option -m
>
> -m machine
> --architecture=machine
> Specify the architecture to use when disassembling object
> files.
> This can be useful when disassembling object files which
> do not
> describe architecture information, such as S-records. You
> can list
> the available architectures with the -i option.
> but it does not mention how to specify a machine, although I did
> find it in
> objdump --help later:)
>
> debian GNU objdump 2.14.90.0.7 20031029
>
> >one doesn't really have to read the sources to figure it out!
> >But the question of whether the default mode of objdump
> >should be the minimum 32-bit legacy instruction set is a good
> >one. Not many currenly used MIPS processors are MIPS I.
> >I understand that disassembling advanced instructions that are
> >not supported by a particular CPU as if they were normal can
> >cause confusion and error, but perhaps the default would be to
> >disassmble everything as MIPS64 rev 2, but with all instructions
> >that are not in MIPS I flagged somehow, perhaps with a message
> >after the assembly code to indicate the extended ISA level? e.g.
> >
> >a0000650: 07400003 bltz k0,a0000660 <nmi_handler+0x1c>
> >a0000654: 03a0d82d move k1,sp *mips3*
> >a0000658: 3c1ba020 lui k1,0xa020
> >
> >Where specifying -m mips:isa64 or -m mips:4000 would suppress the warnings
> >on MIPS64 or MIPS III instructions respectively. Just a thought...
> >
> >----- Original Message -----
> >From: "Fuxin Zhang" <fxzhang@ict.ac.cn>
> >To: "Dmitriy Tochansky" <toch@dfpost.ru>
> >Cc: <linux-mips@linux-mips.org>
> >Sent: Thursday, October 14, 2004 10:45
> >Subject: Re: Strange instruction
> >
> >
> >
> >
> >>objdump -d -mmips:4000 vmlinux to force it regconize all MIPS III
> >>instructions
> >>
> >>I think this option should be renamed( i had try -mips3 -mmips3 etc.
> >>before i find it
> >>by reading the source code)
> >> or the default should be changed.
> >>
> >>Dmitriy Tochansky wrote:
> >>
> >>
> >>
> >>>Hello!
> >>>
> >>>When starts kernel for my au1500 board reseting board. After disassembling I found instruction
> >>>which reseting board. Here is few strings of "mipsel-linux-objdump -D vmlinux" output:
> >>>
> >>>---
> >>>
> >>>a0000650: 07400003 bltz k0,a0000660 <nmi_handler+0x1c>
> >>>a0000654: 03a0d82d 0x3a0d82d
> >>>a0000658: 3c1ba020 lui k1,0xa020
> >>>
> >>>---
> >>>
> >>>Base address changed by me.
> >>>
> >>>What is A0000654? There is board resets.
> >>>
> >>>
> >
> >
> >
> >
>
next prev parent reply other threads:[~2004-10-14 11:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-14 11:53 Strange instruction Dmitriy Tochansky
2004-10-14 8:34 ` Kevin D. Kissell
2004-10-14 8:34 ` Kevin D. Kissell
2004-10-14 12:12 ` Thiemo Seufer
2004-10-14 12:16 ` Nigel Stephens
2004-10-14 12:36 ` Thiemo Seufer
2004-10-14 13:12 ` Kevin D. Kissell
2004-10-14 13:12 ` Kevin D. Kissell
2004-10-14 13:34 ` Thiemo Seufer
2004-10-14 8:45 ` Fuxin Zhang
[not found] ` <000b01c4b1da$6e049f00$10eca8c0@grendel>
[not found] ` <416E5B62.8050508@ict.ac.cn>
2004-10-14 11:13 ` Kevin D. Kissell [this message]
2004-10-14 11:13 ` Kevin D. Kissell
2004-10-14 13:45 ` Dan Malek
2004-10-14 19:06 ` Dan Malek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002f01c4b1de$cb80abc0$10eca8c0@grendel' \
--to=kevink@mips.com \
--cc=fxzhang@ict.ac.cn \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.