This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bogus test case expectations


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]