On Fri, 2008-02-01 at 10:40 +, Nick Clifton wrote:
> > The GNU tools never generate EM_COLDFIRE. I think some non-GNU tools
> > do.
>
> Ok, but is the EM_COLDFIRE number the correct one to use ? (ie are the GNU
> tools wrong ?) It would appear so given the name, but maybe it is an
> unoff
On Thu, 2008-01-31 at 15:22 -0500, Daniel Jacobowitz wrote:
> The GNU tools never generate EM_COLDFIRE. I think some non-GNU tools
> do.
Daniel:
Thank you. That's a bit of a relief. I may have it misconfigured, but at
least I seem to have it misconfigured correctly. :-)
shap
If this is an error, it is the result of a misconfiguration on my part,
but I would like to know the right thing before I fix it.
We are compiling for Coldfire CFV4E target. Binutils seems to want to
set the ELF header em_machine field to EM_68K with about half a dozen
options set to indicate inst
On Fri, 2007-12-21 at 17:13 +, nickc at redhat dot com wrote:
> --- Additional Comments From nickc at redhat dot com 2007-12-21 17:13
> ---
> I think that you may need to define a new opcode operator, one like 'c' but
> which only accepts 'ic','dc' or 'bc' and then use this.
> PS. In
Yang:
It's going to be very tough for people to debug this unless they know
what target you are compiling for and what options were passed to the
assembler. If you are using gcc, pass it the -v option and it will show
the options to the subprograms.
Debugging this for real may not be possible wit
I've gotten annoyed enough to want to fix something :-)
The disassembly logic for M68k MOVEC is awful. To do it right requires
knowledge of the actual target CPU model, and we don't have that from
BFD. We *do* have the target architecture level, and we can at least use
that to refine the output.
