This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] [ARC] Improve filtering instructions while disassembling.
> 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
> 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.