On Tue, 2005-02-08 at 12:55 -0800, Zack Weinberg wrote:
> Currently, if you write a linker script which assigns dot to an
> expression involving a symbol, and that symbol is undefined, you get
> the not-terribly-helpful diagnostic "invalid assignment to location
> counter".  For instance:
[...]

Since no one seems interested in helping me with this, I have redone it
in a way which at least does not break anything.  I'm not hugely
enthused about adding a file-global state flag, but then neither am I
enthused about the alternative of adding another argument to just about
every function in ldexp.c (it wouldn't be used in most of them, but who
knows, my clients may come back next week with another place where the
diagnostics would be better if we knew we were processing an assignment
to the location counter).

I've also added a full set of tests for both the good diagnostic and the
construct that raised the issue in the first place.

OK to commit?

zw

	* ldexp.c (assigning_to_dot): New global flag.
	(fold_name): If assigning_to_dot is true, object immediately to
	an undefined symbol.
	(exp_fold_tree): Set and clear assigning_to_dot around the
	recursive call to exp_fold_tree to process the right-hand side
	of an assignment to the location counter.

testsuite:
	* ld-scripts/align.exp: Rename existing "ALIGN" test to "align1".
	Add dump tests "align2a", "align2b", "align2c".
	* ld-scripts/align2.t, ld-scripts/align2a.s, ld-scripts/align2a.d
	* ld-scripts/align2b.s, ld-scripts/align2b.d
	* ld-scripts/align2c.s, ld-scripts/align2c.d: New files.