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