This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB 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: [cagney_convert-20030606-branch] Add value to REGISTER_TO_VALUEet.al.



Anyway, the question of what to do when the register's value can't be found has been largely ignored. I'm thinking that throwing an error would be a safer strategy - there is too much code ignoring register fetches and I don't think we're going to be auditing it soon.

Indeed, GDB depends on the frame unwinder always returning a value for
its registers.  However for the sake of printing variables stored in
registers it seems that setting OPTIMIZED_OUT makes sense if we know
for certain that a the register has been thrashed.  It makes
valprint.c:value_print() print "<value optimized out>".  The problem
with printing an error message from REGISTER_TO_VALUE() is keeping the
error messages uniform.  However, in some cases it might be more
appropriate to print a warning instead of an error, for example if the
register hasn't been saved, but if we cannot tell whether it has been
thrashed yet.

However, I can live with the current status quo.

Well, the status quo is that GDB doesn't have a story :-( GDB throws an error for some values (memory read failures), returns bogus values for others (register not available), and sets optimized out for more.


As a pie in the sky, would printing better messages help, vis:

	<optimized out>
or
	<register r10 unavailable>
or
	<memory error at 0x1234>
or
	<register r11 invalid>

What of the user interface, should it expect to be able to catch such errors?

Andrew



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