FW: Re: Why is my executabel in DOS file format?

[Joel Sherrill]

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