This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix `return' of long/long-long results with no debuginfo
> Date: Sat, 21 Feb 2009 13:47:24 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>
> On Wed, 11 Feb 2009 22:22:41 +0100, Mark Kettenis wrote:
> > would it be an idea to use the type of the return value expression given by
> > the user instead of int as a fallback?
> >
> > In the case at hand, "return -1" will still fail, but it would be
> > possible to do return (void *)-1 to do what the user wanted.
>
> It has been proven by the original bugreport even experienced
> programmers will make a mistake forgetting about the type cast.
And I' say it again. You're doing such users a far bigger favour by
distributing libraries with debug information. than with bloating gdb
with code to work around issues.
> Therefore GDB "will not work" from the user POV in the most common
> programming usecase of the `(gdb) return' command:
> * x86_64 as the current+future primary development architecture.
> * `void *' (pointer) as the most common return type in modern code.
You're pulling that one out of your arse for sure.
> * `(gdb) return 0' to simulate a failed function
> (`0' because `return NULL' may produce: No symbol "NULL" in current context.)
> Screenshot of the problem reproducer is at the bottom of this mail.
Ah, yes. Gieven the amd64 ISA zero-extends stores into the low 32
bits of a GPR, amd64_return_value() should do the same.
> While I do not have such machine at hand (could try UAE - m68k - for caller
> expecting `long long') I agree with your argument to my former unconditionally
> `long long'-casting patch:
> On Wed, 11 Feb 2009 23:44:21 +0100, Mark Kettenis wrote:
> > I'm not convinced casting to `long long' is safe in all cases, especially on
> > 32-bit big-endian machines. It really might do the wrong thing there,
> > exposing garbage or the wrong 32 bits of the 64-bit value.
>
> To find a way out of the both requirements this patch implements:
> > On Sat, 21 Feb 2009 01:04:09 +0100, Jan Kratochvil wrote:
> > > +/* Set RETURN_VALUE extended to the largest type width which will still be the
> > > + same value after reading it back using the RETURN_VALUE type. */
>
> So this patch tries as best as it can the original intention of a widest cast
> but still it verifies it has not broken the compatibility with the type
> specified by user. Specified either intentionally or unintentionally.
Well, I think your code violates the KISS principle.
> It has no regressions. The only imperfection I find is on the big endian
> 32bit arches one has to use an explicitely cast for callers expecting `long
> long'. But it cannot be guessed better and big endian arches are minority.
Perhaps that's true for the architectures that Red Hat ships products
for. It's certainly not true for the industry as a whole.