https://sourceware.org/bugzilla/show_bug.cgi?id=33153
--- Comment #8 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #6 from Nick Clifton <nickc at redhat dot com> ---
Hi Nick,
> I have decided to split the patch into two. The changes to the bfd/ files
> fix the actual bug, so they make one patch, and the changes to common.h are
> a separate update so I have split them out. I have also gone ahead and
> applied
> the bfd/ fixes to the mainline and 2.45 branch.
fine, thanks a lot.
>> However, logically the condition is the wrong way around IMO: instead of
>> checking !is_solaris, it should be something like is_gnu, i.e. check if
>> the target supports the GNU OSABI. Otherwise, whenever any OS adds a
>> conflicting SHT_<OS>_* entry in the SHT_LOOS/SHT_HIOS range, things will
>> be broken again.
>
> I suspect that this will break lots of targets which use attributes but do
> not set the OS to ELFOSABI_GNU. But I could be wrong. Please feel free to
> submit a patch to make this change (to the mainline, lets leave the branch
> as it is).
Certainly: this it not the only place where this could be an issue.
Also, please not that I've carefully worded this to say "supports the
GNU OSABI", not checking for ELFOSABI_GNU explicitly. That's similar to
the fact that Solaris ld cannot (and will not) set ELFOSABI_SOLARIS.
The problem might be to reliably determine the set of targets that have
that support.
>> Besides, ELF_TARGET_OS was only defined on Solaris/x86 so far. The
>> revised patch adds matching definitions for Solaris/SPARC.
>
> Yes, that was my bad. I just assumed that ELF_TARGET_OS was being set
> correctly
> for all Solaris based targets.
I guess that so far it has only be necessary on x86 to avoid generating
relocs the native ld doesn't understand.
>> However, there are quite a number of regressions in the binutils
>> testsuite:
>
> I suspect/hope that these are due to an unrelated issue.
It is, as I've now discovered. In the unpatched tree, ld-ctf tests were
UNSUPPORTED since even a simple link test failed. With that problem
gone, the tests will run and FAIL. In the past, I repeated had problems
with CTF tests on Solaris that went away when mmap support was disabled
for libctf. I'll keep looking what's going on here...
>> I've not yet found what's wrong here, however it seems to be CTF related
>> in some way:
>>
>> exited abnormally with 1,
>> output:/var/gcc/binutils/i386/obj/binutils-2.45-branch/ld/../binutils/
>> objdump: error: ctf_arc_bufopen(): cannot open CTF
>> /var/gcc/binutils/i386/obj/binutils-2.45-branch/ld/../binutils/objdump: CTF
>> open failure: Buffer does not contain CTF data.
>> /var/gcc/binutils/i386/obj/binutils-2.45-branch/ld/../binutils/objdump:
>> tmpdir/dump: file format not recognized
>
> Maybe the CTF code needs attributes in order to work properly ? (Just
> guessing).
I don't think so: this wasn't an issue in previous binutils releases and
probably won't have become a requirement recently.
>> There's more, however:
>>
>> * <sys/link.h> has quite a number of DT_SUNW_* and DF_SUNW_* defines.
>>
>> * <sys/elf.h> has ET_SUNW_*, PT_SUNW_*, SHF_SUNW_*.
>>
>> One may want to add (some of?) those, too, maybe into a separate
>> include/elf/sun.h (or solaris.h).
>
> Indeed. I am going to upload a revised version of the second part of the
> patch
> which not only includes updates to common.h but also additions of code to
> readelf
> to display all these Solaris specific values. If you have the time would you
> mind
> taking a look over it, and maybe trying out the new readelf decoding ?
I'll have a look. May take a bit with breakage on the gcc coming up
regularly and LLVM entering the 21.x release phase...
> I did consider using a separate header file, but we already have other OS
> specific
> information on common.h. Plus the whole point of this update was to have the
> various OS specific values defined close to their generic counterparts so
> that
> when coders want to select new values, they can avoid ones that are already
> taken.
Good point. I only saw the existing hppa.h file and considered
following this model.
Thanks.
Rainer
--
You are receiving this mail because:
You are on the CC list for the bug.
