public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Eyal Lebedinsky <eyal@eyal.emu.id.au>
Cc: gcc@gcc.gnu.org
Subject: Re: mudflap: how do I give size for 'void *' objects? - example
Date: Mon, 07 Apr 2003 19:54:00 -0000	[thread overview]
Message-ID: <20030407120627.C10802@redhat.com> (raw)
In-Reply-To: <3E8F9FE5.ED8FFCE@eyal.emu.id.au>; from eyal@eyal.emu.id.au on Sun, Apr 06, 2003 at 01:32:53PM +1000

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2003-04-07 16:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-04  1:27 mudflap: how do I give size for 'void *' objects? Eyal Lebedinsky
2003-04-05 11:18 ` mudflap: how do I give size for 'void *' objects? - example Eyal Lebedinsky
2003-04-05 21:17   ` Frank Ch. Eigler
2003-04-06 13:39     ` Eyal Lebedinsky
2003-04-07 19:54       ` Frank Ch. Eigler [this message]
2003-04-08  0:08         ` Eyal Lebedinsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030407120627.C10802@redhat.com \
    --to=fche@redhat.com \
    --cc=eyal@eyal.emu.id.au \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).