This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: bogus test case expectations
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at novell dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 21 Jul 2009 07:38:22 -0700
- Subject: Re: bogus test case expectations
- References: <4A65C7ED020000780000B881@vpn.id2.novell.com>
On Tue, Jul 21, 2009 at 4:51 AM, Jan Beulich<JBeulich@novell.com> wrote:
> Finally I found time to debug why, after initially working with the
> snapshot_symbol() change I had done in late 2005, some local changes I
> had on top of this stopped working in newer binutils releases. I was about
> to propose below change (with the rationale that the comment "Never
> change a defined symbol.", while correct, didn't match the code, as the
> check was done against the perhaps already updated symbol, not the
> one that got passed in). This, however, causes one of the four ia64 test
> cases added together with that change to fail.
I have no objections to update comments.
> The question is whether the expectations ltoff22x-2.d sets are really
> correct in the first place: In particular, I would question whether it is
> appropriate to expect that foo gets used for the symbol references in
> both resulting relocations, since foo got equated to bar earlier on (and
> hence the assembler ought to be free to de-reference that symbol).
> Since this depending on internal behavior, the only sane thing to do
> would imo be to either change ltoff22x-2.s to reference bar in both
> cases, or to permit both symbols in ltoff22x-2.d.
We can't change relocation symbol from "foo" to "bar" since
"bar" may have different properties. "foo = bar" only sets symbol
value for "foo", nothing more.
> The former would, as I understand it, make the whole test case
> pointless.
That is correct.
> The latter, however, bares the risk that the relocations refer once to
> each symbol, which really is the case with just the below change. But
> that's due to an inconsistency in tc-ia64.c's handling of operands,
> which in turn is due to the lack of a target hook for handling target
> specific operators for resolve_expression(): O_pseudo_fixup doesn't
> get handled, and hence its operand doesn't undergo the same
> expression evaluation as normal symbol references would.
>
> Remains as the final (but more involved) option fixing the ia64 issue,
> and making the test case yet again depend on behavioral details of
> the assembler, by changing the expectation in both cases from foo
> to bar.
>
As long as those ia64 testcases are unchanged, I have no problems.
Thanks.
H.J.