This is the mail archive of the binutils@sourceware.org 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: objcopy, binary inputs, and e_machine


On Tuesday 23 June 2009 19:35:36 Dave Korn wrote:
> Mike Frysinger wrote:
> > this behavior is because the objcopy sets the arch/mach of the output to
> > match the input, and since this is a binary input, the arch/mach are set
> > to none.
>
>   That seems obviously and blatantly wrong to me.  Surely the arch/mach for
> the input BFDs should be set one way and the arch/mach for the output BFD
> should be set another in this case?  If the "-I" option is setting the
> parameters for the "-O" BFD, that's just a bug.

hmm, it might run even deeper.  the output bfd does not have anything setup in 
its arch_info field.  this is because objcopy sets up the output bfd by doing 
bfd_open(file, target) (where target is the bfd name e.g. elf32-i386), and 
that uses the target name to only set up the target xvec via 
bfd_find_target().

seems to me that bfd_find_target() should also initialize arch_info ?  or 
perhaps bfd_open ?

> > or isnt there a saner route that'd work for everyone ?
>
>   Yes, if you have correctly diagnosed the problem then binutils is clearly
> currently *not* sane for everyone.  It shouldn't be a backend decision at
> all; this is a wrong request by the client of BFD, isn't it?

ok, just wanted to make sure i wasnt missing something obvious
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


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