mudflap: how do I give size for 'void *' objects? - example

[Frank Ch. Eigler]

Hi -

On Sun, Apr 06, 2003 at 01:32:53PM +1000, Eyal Lebedinsky wrote:
> [...]
> Good, I now wrapped ctime() and shmat() with __mf_[un]register()
> calls and this removed the reports. 

(Patch please?)

> BTW, for such foreign objects,
> how do I set the size when it is unknown (e.g. for 'ctime' I now
> cheat and say '64'), and what type do I use (I use GUESS)?

For ctime, the size is probably 26 or 27, and the type should
be STATIC.  For other functions, it varies case by case.


> And just to be sure I did not miss a post, the getmem/usemem example
> does show a real problem, right? [...]

It shows a real problem in your test program.  You're allocating a piece
of memory with malloc(), so it is uninitialized.  Its contents are
undefined, but you're reading from it.  The libmudflap default option
"-check-initialization" is designed to detect exactly this.  Had you
used calloc(), or wrote to the buffer first, there would be no
violation shown.  (This is a pretty naive algorithm - nowhere near
what valgrind does.)


> So, the "location=`zz.c:19 (usemem)'" is from compile time, but the
> following traceback is from glibc runtime? 

Yes.

> I never saw line numbers in this trace, only hex offsets,
> and I do use '-g'. Can I make it show line numbers (am I
> missing an option)? 

I don't think glibc can do that.  By supplying "--export-dynamic",
your shared library may have more of the symbols glibc may use
to get at least function names.

> [...] here is an example report which I find very hard to use:
> [...]/libmudflap.so.0(__mfwrap_memcmp+0x13c) [0x40b39bac]
>       /ssa/builds/20030404n/bin/libssaiok.so [0x40a85d51]
>       /ssa/builds/20030404n/bin/libssaiok.so [0x40a84c93]

Yeah.  Unfortunately libmudflap and glibc don't use debugging
data to get more precise locations.  I expect we could use an
external "addr2line" child process to map raw PC values to
source:line coordinates.  Care to try writing up such an option
for libmudflap, perhaps based on libjava/gnu/gcj/runtime/NameFinder.java?
(I believe there used to be a C/C++ version of that little function too.)


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20030407/8d38c441/attachment.sig>