This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: objdump -M for x86
- To: Alan Modra <amodra at bigpond dot net dot au>
- Subject: Re: objdump -M for x86
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 14 Nov 2001 03:49:52 -0500
- Cc: binutils at sources dot redhat dot com, gdb at sources dot redhat dot com
- References: <20011114134429.G6922@bubble.sa.bigpond.net.au> <3BF200F9.4070601@cygnus.com> <20011114174350.K6922@bubble.sa.bigpond.net.au>
>
> Actually, I was meaning that you don't need to call print_insn_i386_att
> or ..._intel; Just call print_insn_i386 with info->mach set.
Hmm, I didn't see that ....
> mode_64bit = (info->mach == bfd_mach_x86_64_intel_syntax
> || info->mach == bfd_mach_x86_64);
>
> + if (intel_syntax == -1)
> + intel_syntax = (info->mach == bfd_mach_i386_i386_intel_syntax
> + || info->mach == bfd_mach_x86_64_intel_syntax);
> +
See my other e-mail. I can't find anything that sets ->mach to
.._intel_syntax so, apart from backward compatibility, I can't think of
a reason to hang on to those ``machine'' variants. I don't expect GDB
to start using them again.
>> Next problem ... If I understand things correctly, the set of possible
>> options, for a given ISA family, is finite. Could that finite list be
>> made available via a published interface?
>
>
> Yes, good idea. Something like:
>
> const char **opcodes_disasm_options (enum bfd_architecture arch)
>
> returning a malloc'd list of strings for the given arch?
(if gdb is going to freeargv() it then I don't think you want the const).
Yes, anything like that. Could add it to bfd_arch_info_type, or ....
What ever BINUTILS is comfortable with I guess.
We'll need to do things like pin down the semantics. Which really means
agree on what something like ``x86-64 i386 i8086 intel att addr16 addr32
data32 data16 suffix'' actually means, and ensure that GDB doesn't find
it has accepted a set of options only to find them later rejected by the
disasssembler.
(May one day need to add pre-parsed disassembler-options to the
disassemble_info due to the overhead of constant re-parsing. However,
cross that bridge when someone notices a real problem :-)
Andrew