On Thu, 2009-06-18 at 13:50 -0700, Rick Altherr wrote:
> On Jun 18, 2009, at 3:47 AM, Zach Welch wrote:
>
> > On Thu, 2009-06-18 at 03:17 -0700, David Brownell wrote:
> >> On Wednesday 17 June 2009, Zach Welch wrote:
> >>> --- src/target/trace.h (working copy)
> >>> +++ src/target/trace.h (working copy)
> >>> @@ -28,7 +28,7 @@
> >>> typedef struct trace_point_s
> >>> {
> >>> uint32_t address;
> >>> - u64 hit_counter;
> >>> + uint64_t hit_counter;
> >>> } trace_point_t;
> >>>
> >>> typedef struct trace_s
> >>
> >> On x86_64 builds I now get:
> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../src/helper -
> >> I../../src/jtag -I../../src/xsvf -I/usr/local/include -Wall -
> >> Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -
> >> Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT
> >> trace.lo -MD -MP -MF .deps/trace.Tpo -c trace.c -o trace.o
> >> cc1: warnings being treated as errors
> >> trace.c: In function ‘handle_trace_point_command’:
> >> trace.c:63: warning: format ‘%lld’ expects type ‘long long int’,
> >> but argument 4 has type ‘uint64_t’
> >> make[3]: *** [trace.lo] Error 1
> >> make[3]: *** Waiting for unfinished jobs....
> >>
> >> Making it "%llu" doesn't help. I guess this is one of the ways
> >> that the previous "u64" behaved differently from "uint64_t"...
> >
> > I found this myself and just committed a patch to fix it, but I simply
> > use a cast. There probably is a better way, but this fixes the build
> > for now. Fortunately, this is the only variable in the tree that uses
> > the uint64_t type, so the consequences should be minor.
> >
> > Cheers,
> >
> > Zach
> >
> > _______________________________________________
> > Openocd-development mailing list
> > Openocd-development@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/openocd-development
>
> The proper fix is to use the PRId64 format string provided by
> inttypes.h. The PRI* macros exist to provide the correct format
> string for the uint*_t types. The problem is that the size of long
> changes between 32-bit and 64-bit x86 processors. For 32-bit, you get
> a 64-bit number via long long, but for 64-bit, you only need long.
> PRId64 will change appropriately to handle that depending on the
> target architecture.
Ack.
> It looks like inttypes.h should be included in types.h, but it will
> also need tests added to configure.
Actually, think inttypes.h can replace stdint.h, since the later is
included by the former.
Cheers,
Zach
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
