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] |
> > > 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