This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] LD/testsuite: ld-*/comm-data.exp improvements
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: binutils at sourceware dot org
- Date: Sun, 28 Jul 2013 23:42:51 +0100 (BST)
- Subject: Re: [PATCH] LD/testsuite: ld-*/comm-data.exp improvements
- References: <alpine dot LFD dot 2 dot 03 dot 1307280023430 dot 3015 at linux-mips dot org> <Pine dot LNX dot 4 dot 64 dot 1307281705350 dot 28065 at digraph dot polyomino dot org dot uk>
On Sun, 28 Jul 2013, Joseph S. Myers wrote:
> > (Joseph, any idea why the default linker emulation used by tic6x-uclinux
> > fails shared library or shared executable links?)
>
> You don't say what "fails" means - but you can't usefully do a
> shared-library link on C6X without specifying a DSBT index, since those
> need to be globally allocated and distinct for all shared libraries on a
> system.
Sorry for being vague, having hoped you might know right away anyway --
it's been a while since I discovered the problem and I did not remember
the exact details. I have now rerun this test with the -melf32_tic6x_le
option removed so the emulation in effect was elf32_tic6x_linux_le. The
result was a shared object with no dynamic segment/section -- linked
successfully with no warnings, but indeed rather useless.
I don't know what's going on here and why the lack of a DSBT index (if
relevant and whatever that is) might cause the dynamic data to be omitted
from output altogether, and specifically for one of these emulations but
not the other. If that is expected behaviour, then I am of course fine
with that and I apologise for troubling you -- I just wanted to make sure
all is right here.
If you'd like however to investigate it further, then you can reproduce
this phenomenon by applying the patch concerned here and removing the line
that adds -melf32_tic6x_le to LFLAGS for tic6x-*-*.
Thanks for your input.
Maciej