Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote:
> The GNU Binutils requirement was to target lots of different object
> formats, and architectures, allow different ones to be interconverted
> and linked together, and to run on lots of platforms.
The Linux kernel also meets those requirements (the ones that are
relevant for a kernel that is.)
> Given those constraints, probably C was the only option at the time,
> and BFD's interface, although ugly and difficult to work with, does
> reflect the abstractions of different object formats and architectures
> moderately well IMHO.
Well, I guess it does work moderately well once you get used to it. But
there are lots of hidden dependencies all over the place. I still
haven't figured out how to un-break the debugging information after
relaxing, for example.
But what I disagree with is that these problems are somehow a symptom
of using C as the implementation language. They're a symptom of bad
design decisions IMO.
> It's tough to make a nice design that meets those requirements.
Absolutely. But does using C++ as an implementation language really
make it any easier?
> It's unfortunate that BFD is so hard to work with that people resort
> to post-processing tools and other hacks, instead of enjoying adding
> new format support to it.
>
> For all it's faults working with it, the tools themselves are very
> versatile and useful compared with most equivalents.
Agreed. I definitely prefer using the GNU tools over the alternatives
I've seen. But that doesn't mean they can't be improved further.
> If you have clear improvements that would simplify GOLD (without
> breaking it or requirements you might not be aware of), the author may
> be quite receptive to them. He seems keen on the code being of high
> quality, and he's quite experienced at working on "open" projects with
> many contributors.
Yeah, I suppose I should put my money where my mouth is and offer some
constructive suggestions. Right now I'm waiting for someone to get the
necessary paperwork in place so that we can work as closely with the
GNU community as we do with the Linux kernel and several other
communities.
Off the top of my head, after looking just at the target interface, I'd
really like to see
* A few better abstractions so that the target relocation hooks
don't need a gazillion parameters.
* Some way to spread the target implementation across a few more
files/classes so that we don't end up with a single
several-thousand-lines file for each architecture. A subdir for each
arch would be nice.
Currently, it looks like the target interface is headed down the same
road as libbfd, and that means the code will be just as unmanageable in
a few years.
I'm also curious about what things will look like once support for
complicated things like --relax and --gc-sections is added...
But I guess complaining about it here won't do much good.
Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
