This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [ARC] Improve filtering instructions while disassembling.

Hi Claudiu,

> My proposal is orthogonal to the note proposal, and addresses 
> situations when the compiler doesn't place the notes into the 
> asm file or we have intermediate elf processing steps that are 
> throwing or messing up with the note section. Hence, once a 
> note solution will get in it will not runout the need for the 
> solution proposed, as they may be old compilers which may not 
> produce the newly introduced note section.

Ah - fair enough.  I had not considered that situation.

>>       The exception to this would be if the toolchain has been
>>       built with the --with-cpu=ARCxxx option specified on the
>>       configure command line.  Currently this option is only
>>       interpreted by GAS, but it could/should be extended to the
>>       opcodes library to provide a default for disassembly.
> I see a limitation here, we use multilib. 

Hmm, so how do you ensure that the user does not attempt to link an
application intended for one particular ARC variant with a library
built for a different ARC variant ?  Or is this something which is
not currently addressed, but which the ABI notes are intended to 
address ?

> So, even if we build with --with-cpu, we will have situations 
> when we want to disassemble differently for a different ARC 
> cpu. Also, the ARC cpus are templates and, basically, we do 
> not know what instruction mix a customer will choose until 
> they come back to us. Basically, --with-cpu selects a class 
> of CPUs and not a precise implementation.

Umm, so does that mean that the meaning of ARC opcodes can be changed
on a per-customer basis ?  Isn't that going to make correct disassembly
almost impossible if the tool has not been customised for that particular
customer ?  (Sorry about the pun).

Also - with multilibs you have to select the desired CPU variant using
a command line switch when compiling right ?  So a [multilib experienced] 
user will already be familiar with the idea of selecting a cpu, and adding 
an option to objdump (to override a default set up by the --with-cpu) will 
hardly be a difficulty for them.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]