This is the mail archive of the gdb-patches@sourceware.org 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: RFC: Relax checking of garbage struct return values


Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>> From: Jim Blandy <jimb@redhat.com>
>> Date: Thu, 06 Oct 2005 10:44:29 -0700
>> 
>> The comments are supposed to have the story.  Tested on
>> x86_64-pc-linux-gnu.
>> 
>> 2005-10-05  Jim Blandy  <jimb@redhat.com>
>> 
>> 	* gdb.base/structs.exp (any): New function.
>> 	(test_struct_returns): Don't make any assumptions at all about
>> 	what value the function returns when GDB can't set the return
>> 	value.
>
> I remember having a discussion about this with Andrew some time ago.
> I believe Andrew argued that if the compiler doesn't pass L<n> as the
> buffer, this should be considered a compiler bug.

I don't agree with that at all.

The compiler is free to generate any code it pleases, as long as the
machine code behaves the way the semantics of C require it to.  An
ordinary assignment of one int to another could go through seven
temporaries, get xor'd with 55 twice, pushed on the stack, and then
popped into its destination, and that's correct.  It's just lousy
code.

> Anyway, there is another case where things fail.  Some compilers use a
> "static" buffer to store function values.  On those systems these
> tests fail too.

It's a pretty losing convention, because it isn't reentrant.  But I
know of such a compiler, too.

> I think your patch is ok: gdb is not a compiler testsuite.

Okay --- thanks for the review.


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