This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Define various symbols conditionally in shared libraries executables
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: amodra at gmail dot com
- Cc: binutils at sourceware dot org
- Date: Tue, 12 Jun 2018 16:47:35 +0200
- Subject: Re: Define various symbols conditionally in shared libraries executables
> Date: Tue, 12 Jun 2018 23:44:26 +0930
> From: Alan Modra <amodra@gmail.com>
> On Tue, Jun 12, 2018 at 05:37:03AM +0200, Hans-Peter Nilsson wrote:
> I test cris-elf, which needed a change, and crisv32-linux. On looking
> at my logs I see the libdso-1 test wasn't run for the linux target..
> In fact, none of the ld-cris/ tests were run, for a fairly obvious
> reason.
Hah, ![istarget cris-*-*]. Though, I believe there'd be too
many bit-patterns to tweak, so that has to stay.
> The cris-elf dump looks like:
>
> ld/tmpdir/libdso-1.so: file format elf32-cris
Hm, this test runs for cris-elf? DSOs don't make much sense
there...'k, apparently I set all required options to generate a
DSO, but apparently there's still a size difference. The
purpose is to have cris-elf be the catch-all target.
> DYNAMIC SYMBOL TABLE:
> 000000d0 g DF .text 00000002 dsofn
>
> So it would seem the patch should have made the address match
> 00000[01].[02468ace]
Right, though (IIRC) the purpose of the address pattern not
being ".+" is that I want to exclude 0 (and the last part is
that functions start on an even address). Though, that doesn't
seem important enough to worry about.
Ok, thanks for clarifying; I'll fix.
brgds, H-P