[Mono-devel-list] (AMD64) Compiler Warnings (2)

Willibald Krenn Willibald.Krenn at gmx.at
Mon Dec 6 11:50:35 EST 2004

Paolo Molaro schrieb:

>>+		return (guint) GPOINTER_TO_UINT(value);
> The extra cast to guint is not needed.

Of course. :-(
Somehow I had the impression that the macro just casts to some 64 bit 
uint.. Will recheck everything.

>> struct MonoDebugLineNumberEntry {
>> 	guint32 offset;
>>-	guint32 address;
>>+	uintptr_t address;
> Unfortunately the names here are confusing: this is not a pointer-sized
> address, it is actually the offset in the native code from the start of
> the method (at least after a quick look at the code). So that change is not
> needed.
> A separate patch here could be done that changes the names of both fields to
> il_offset and native_offset.
> In other parts of the debug code it's used as a real address, though: this
> really requires one of the debug guys to fix the mess. Just changing
> the types to uintptr_t is not going to help.

Ok, so I'll revert that to guint32 and add a *big* FIXME.
But this can break the code on 64 bit architectures as long as the debug 
code uses this field as real address?!

>>+#include <intps.h>
> mono-debug.h is an installed header and you can't add headers that require config.h 
> to it.

That complicates matters. IIRC I need uintptr_t in that header for some 
function arguments that take some address..
I guess I'll use GLIB_SIZEOF_VOID_P instead of SIZEOF_VOID_P in intps.h 
to test for 64 bit and additionally I'll map the [u]intptr types to glib 
types, so that should remove the config.h dependance..

>>-	g_error ("Invalid IL code at IL%04x in %s: %s\n", ip - header->code, 
>>+	g_error ("Invalid IL code at IL%04"x_INT_PTR_T" in %s: %s\n", ip - header->code,
> Here and in other places like this, the correct thing to do is to change the code
> to cast the pointer difference to an int:
> 	g_error ("Invalid IL code at IL%04x in %s: %s\n", (int)(ip - header->code),
> because we're not going to have IL methods bigger than 2 gigabytes.

Ok, I'll change that in all cases where it's obvious (to me).. Most of 
these changes, however, print arguments of type g[s]size - and this is 
64 bits on AMD64. Shall I truncate these types to 32 bit too?

>> 	/* The address of the generated code, used for fixups */
>>-	int native_offset;
>>-	int max_offset;
>>+	intptr_t native_offset;
>>+	intptr_t max_offset;
> They are offsets, the ints are fine.


>>Index: mono/mini/mini-exceptions.c
>> 					/* Switch back to normal stack */
>> 					if (stack_overflow)
>> 						/* Free up some stack space */
>>-						MONO_CONTEXT_SET_SP (&initial_ctx, (guint32)(MONO_CONTEXT_GET_SP (&initial_ctx)) + (64 * 1024));
>>-					MONO_CONTEXT_SET_IP (&initial_ctx, (unsigned int)jit_tls->abort_func);
>>+						MONO_CONTEXT_SET_SP (&initial_ctx, GPOINTER_TO_UINT(MONO_CONTEXT_GET_SP (&initial_ctx)) + (64 * 1024));
>>+					MONO_CONTEXT_SET_IP (&initial_ctx, GPOINTER_TO_UINT(jit_tls->abort_func));
> The code here is broken and the change just masks the bug. abort_func 
> should not be cast to a uint: it is a pointer.

A cast to uintptr_t should work, I guess..

>>	#if SIZEOF_VOID_P == 8
>>		/*only applies if sizeof(void*)==8*/
>>		#define d_INT_PTR_T "ld"
>>		#define d_INT_64    "ld"
>>		#define u_INT_PTR_T "lu"
>>		#define u_INT_64    "lu"
>>		#define x_INT_PTR_T "lx"
>>		#define x_INT_64    "lx"
>>	#else
>>		/*else switch back to normal*/
>>		#define d_INT_PTR_T "d"
>>		#define d_INT_64    "lld"
>>		#define u_INT_PTR_T "u"
>>		#define u_INT_64    "llu"
>>		#define x_INT_PTR_T "x"
>>		#define x_INT_64    "llx"
>>	#endif
> I don't like the macro names and they don't follow the convention
> in mono: they pullute the namespace. Maybe MONO_FMT_PTR/MONO_FMT_64
> and leave the d/u/x format in the string.

You mean something like

	/*only applies if sizeof(void*)==8*/
	#define MONO_FMT_PTR "l"
	#define MONO_FMT_64  "l"
	/*else switch back to normal*/
	#define MONO_FMT_PTR ""
	#define MONO_FMT_64  "ll"

printf ("some %"MONO_FMT_64"x",some guint64);

Thanks a lot for your feedback, will redo my patch,

More information about the Mono-devel-list mailing list