This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


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

Re: gcc/sdbout.c and char parameters


> 
> 	> I also believe that gcc will say the parameter has type `int' when optimizing,
> 	> but that there is no practical way to fix this in the sdbout format.  Is
> 	> this the only thing you are complaining about?
> 
> 	Yes, but I always compile with optimization :).
> 
> Unfortunately, the sdbout format was not designed for compilers that can
> both optimize and emit debug info at the same time.  And because it is
> unextensible, this problem can't be easily fixed.
> 
> 	> If you look at the RTL dumps, you can see that the parameter is an int, that
> 	> gets truncated to a char, and then sign-extended to a short.  Gcc believes
> 	> that the value being passed in is an int, it just isn't taking advantage of
> 	> this fact to generate faster code.
> 
> 	No, Gcc knows that the value passed is a char, but padded to fit the size of
> 	an int.
> 
> No, what I said was correct, but the distinction is a subtle one.  For the port
> that you are using, we really are passing an int and converting it to char.
> This always happens for old-style function declarations.  This happens for
> prototyped function declarations only if PROMOTE_PROTOTYPES is defined, and
> this is defined for your port.  This can be seen if you look at the tree
> structures that gcc is using.  Look at parm->decl.initial, and note that
> it is int.  This is the type that gcc is using the value passed in and this
> has nothing to do with padding.  If you undefine PROMOTE_PROTOTYPES, then this
> type will be char.  This distinction is easier to see on a 64 bit machine
> with 32 bit ints, where the incoming rtl will be SImode even though stack
> slots and registers are DImode.
> 
> gcc is generating the most
> conservative calling convention code for best portability.  The gcc m68k port
> promotes a char argument to int before a call, so that the callee will
> work regardless of whether the callee was expecting an int or char.  Also,
> the gcc m68k port truncates a char parameter from a passed int in the
> prologue, which will always work regardless of whether the caller passed an
> int or a char.

Ok, I agree with that.  Sorry if my wording was not precise enough.

Now, back to the problem : is the user interested in that intermediate
`int' form of his parameter or rather in the `char' form when using
gdb and friends ? It is possible to tell gdb that the `int' that is on
the stack is a `char' (and change its address on big-endian
machines); that's what my patch did.  And gdb has no problem with
that small lie : I saw no regression with it by running the gdb-4.16.85
testsuite using such a modified version of gcc on m68k-motorola-sysv.

I was asking for some help because I was a little bit uncomfortable
by the fact that what my patch did actually was to remove some code,
instead of adding some.

Philippe