This is the mail archive of the binutils@sources.redhat.com 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: FW: Re: Why is my executabel in DOS file format?


DJ Delorie wrote:

Dunno. Probably one of the maintainers will approve or deny the
patch. I don't really like the global variable or the objcopy command
line option, so I'm not too excited about it. But maybe somebody else
will push it forward.



BFD policy would prohibit a global variable as an ABI. It must be some field in the bfd's target-private data, accessed via some function API which will fail gracefully if it's called on the wrong type of bfd.

The patch as submitted would cause a build failure for any build that
didn't include srec, and if in the future srec became two bfd types
(like coff-i386, for example), you'd get link errors then also.

IMHO it would be better to create a new bfd target type for the
alternate srec line endings, say, sreclf or something.  This should be
easy to do if you follow the pattern of the other targets, where one
file just #defines a flag and includes the other (common) file.
That's similar to the big/little endian alternates we do for other
bfds.  It also doesn't require any new options in *any* utility, since
they all already support selecting the target type.

Or complain to your loader vendor that they're too conservative in
what they accept ;-)



In RTEMS we often just run sed on the output from binutils. There are lots of board specific
limitations on srecords. We also run a utility called "packhex" to get the records to the
maximum allowable limit.


Some don't support specific record types, require DOS or UNIX EOL, have a limit on
the length supported, etc. Just a lot of broken srecord readers out there.


--joel


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