https://bugs.kde.org/show_bug.cgi?id=433510
--- Comment #5 from Mark Wielaard <m...@klomp.org> ---
(In reply to Paul Floyd from comment #4)
> > - TRACE_SYMTAB("rx_map: avma %#lx size %lu foff %ld\n",
> > + TRACE_SYMTAB("rx_map: avma %#lx size %lu foff %lld\n",
>
> ^^^ generates warnings
>
> I think that both versions probably generate warnings on either 32bit or
> 64bit systems, and that we should use a macro to choose l or ll.
I don't think so. I believe the actual pointers and offsets are either 32/64bit
already and match the lx/lu/ld directives.
> > coregrind/pub_core_gdbserver.h What is the padding in padding? I see it is
> > actually set in coregrind/m_gdbserver/remote-utils.c remote_open. But why?
>
> I don't remember exactly what the problem was, but this is the implicit
> padding that is there anyway. The memory gets initialized with brace
> intialization leaving the padding uninitialized. This code makes sure that
> the entire struct gets initialized, even the unused last 4 bytes.
It seems harmless, but odd.
If you really want to initialize the whole struct (including padding, but why?)
then memset(p, 0, sizeof(Struct)) should do it.
> > The logic and the defines feel swapped in VG_(is32on64)(void). But I might
> > misunderstand why the check for that file is done.
>
>
> It's very hard to tell when a 32bit process is running on an amd64 kernel
> (for instance, all sysctls behave like a true 32bit system). When compiling
> the amd64 binary it returns false - that can only ever be 64on64. When
> compiling for x86 that is either on an x86 system or and amd64 system
> building both amd64 and x86. I'm using the link loader to tell them apart.
> This isn't totally bomb proof. Someone could try to run an x86 built
> Valgrind on amd64 or add a /libexec/ld-elf32.so.1 on an x86 system, but I'm
> not going to try to handle user foolishness like that.
Aha. So it is about whether the 32bit x86 freebsd valgrind runs under a 64
amd64 kernel?
On most GNU/Linux distros that is fine and it is actually how 32bit programs
are run under valgrind on a 64bit system.
> > Why this in coregrind/m_main.c
> >
> > +void *memcpy(void *dest, const void *src, size_t n);
> > +void *memcpy(void *dest, const void *src, size_t n) {
> > + return VG_(memcpy)(dest, src, n);
> > +}
> > +void* memmove(void *dest, const void *src, SizeT n);
> > +void* memmove(void *dest, const void *src, SizeT n) {
> > + return VG_(memmove)(dest,src,n);
> > +}
> > +void* memset(void *s, int c, SizeT n);
> > +void* memset(void *s, int c, SizeT n) {
> > + return VG_(memset)(s,c,n);
> > +}
>
>
> That's clang's fault. clang can convert things like
>
> structA = {0};
> and
> structA = structB;
>
> into memset and memcoy calls, so FreeBSD needs them in the tool exe.
That is really odd. Aren't we preventing that somehow with some compile flag.
It also seems pretty inefficient, and inlined memcpy should really be faster
for a simple struct copy than a function call to memcpy.
But if so, could you add this to coregrind/m_compiler.c hidden behind and
appropriate #ifdef CLANG option?
--
You are receiving this mail because:
You are watching all bug changes.
