Re: objdump -M for x86

Re: objdump -M for x86

[Andrew Cagney]

> Applying to mainline.  Note to gdb people: Some backwards compatibility
> stuff can be removed when i386-tdep.c and x86-64-tdep are updated to use
> the new (old!) print_insn_i386.
> 
> binutils/ChangeLog
> 	* doc/binutils.texi (objdump): Document x86 -M options.
> include/ChangeLog
>  	* dis-asm.h (print_insn_i386): Declare.
> opcodes/ChangeLog
> 	* disassemble.c (disassembler): Call print_insn_i386.
> 	* i386-dis.c (SUFFIX_ALWAYS): Define.
> 	(struct dis_private): Add orig_sizeflag.
> 	(print_insn_i386): Make it a wrapper, calling..
> 	(print_insn): ..The old body of print_insn_i386.  Avoid longjmp
> 	warning without using volatile by moving orig_sizeflag to priv,
> 	and removing inbuf.  Parse disassembler_options.
> 	(print_insn_i386_att, print_insn_i386_intel): Move initialisation
> 	code to print_insn.
> 	(putop): Remove #ifdef SUFFIX_ALWAYS.
> 

Hmm, I was wondering what you were talking about until I found this:

> +  for (p = info->disassembler_options; p != NULL; )
> +    {
> +      if (strncmp (p, "x86_64", 6) == 0)
> +	{
> +	  mode_64bit = 1;
> +	  priv.orig_sizeflag = AFLAG | DFLAG;
> +	}
> +      else if (strncmp (p, "i386", 4) == 0)
> +	{
> +	  mode_64bit = 0;
> +	  priv.orig_sizeflag = AFLAG | DFLAG;
> +	}
> +      else if (strncmp (p, "i8086", 5) == 0)
> +	{
> +	  mode_64bit = 0;
> +	  priv.orig_sizeflag = 0;
> +	}
> +      else if (strncmp (p, "intel", 5) == 0)
> +	{
> +	  intel_syntax = 1;
> +	}
> +      else if (strncmp (p, "att", 3) == 0)
> +	{
> +	  intel_syntax = 0;
> +	}
> 

(x86-64?)

Thanks!

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?  That way GDB could 
incorporate them into its CLI so that things like ``set 
disassembly-options <tab>'' worked.

To get the feel for what I'm talking about check gdb/arm-tdep.c which 
queries opcodes for the ARM register naming conventions.

enjoy,
Andrew

Re: objdump -M for x86

[Alan Modra]

On Wed, Nov 14, 2001 at 12:28:25AM -0500, Andrew Cagney wrote:
> > Applying to mainline.  Note to gdb people: Some backwards compatibility
> > stuff can be removed when i386-tdep.c and x86-64-tdep are updated to use
> > the new (old!) print_insn_i386.
> 
> Hmm, I was wondering what you were talking about until I found this:

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.

> (x86-64?)

Well, x86_64 follows the name used by -m

> 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?

Alan

Re: objdump -M for x86

[Andrew Cagney]

> 
> 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

Re: objdump -M for x86

[Alan Modra]

On Wed, Nov 14, 2001 at 03:49:52AM -0500, Andrew Cagney wrote:
> 
> >  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.

"objdump -d -m i386:intel" sets it via bfd_default_scan from the entry
in bfd/cpu-i386.c

> 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.

Perhaps the thing to do is add a function to bfd_arch_info_type that
validates a -M string for the given arch.  If a null string is passed in,
it could return an array of possible string components.

Alan

Re: objdump -M for x86

[Andrew Cagney]

>> 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.
> 
> 
> "objdump -d -m i386:intel" sets it via bfd_default_scan from the entry
> in bfd/cpu-i386.c

Ahh.  (Sorry only just got back to this).  Groan.

Can I suggest a comment on the test indicating that this can happen -> 
stop me trying to delete ..._intel :-)

Andrew

Re: objdump -M for x86

[Andrew Cagney]

>> 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.
> 
> 
> "objdump -d -m i386:intel" sets it via bfd_default_scan from the entry
> in bfd/cpu-i386.c

Ahh.  (Sorry only just got back to this).  Groan.

Can I suggest a comment on the test indicating that this can happen -> 
stop me trying to delete ..._intel :-)

Andrew