This is the mail archive of the
mailing list for the binutils project.
Re: binutils/glibc .hashvals section ...
- From: Nick Clifton <nickc at redhat dot com>
- To: michael dot meeks at novell dot com
- Cc: binutils <binutils at sources dot redhat dot com>
- Date: Fri, 27 Jan 2006 17:51:13 +0000
- Subject: Re: binutils/glibc .hashvals section ...
- References: <firstname.lastname@example.org>
Trivial patch follows; of course, since this requires glibc support one
can't be overly optimistic wrt. inclusion ;-)
There is no reason why such a patch cannot be included in binutils.
People are free to modify glibc after all.
but surely it's only polite to post here for discussion.
Well then here are some comments...
+ case DT_SUSE_HASHVALS: name = "SUSE_HASHVALS"; break;
I assume that this feature does not have to be specific to SUSE, so I
would suggest a more generic name, eg DT_GNU_HASHVALS.
+ if (info->hashvals)
+ s = bfd_make_section (abfd, ".suse.hashvals");
Similarly. In fact if the info->hashvals field was a "const char *"
then it could be the name of the section to create. (Not sure if this
is a good idea though). If the name of the section is going to be fixed
however then it ought to be specified as a #defined constant in a header
file somewhere. One that can be accessed by both binutils and glibc.
(Although you could quite reasonably point out that hard coded section
names are everywhere in the elflink.c file. To which I would say, well
they should *all* be replaced by #define'd constants...)
Other than that though the binutils part of the patch looks fine to me.
A few formatting tidy ups and replacements of fprintf with calls to
bfd_error_handler, but otherwise OK.