From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5354 invoked by alias); 27 Mar 2007 11:56:59 -0000 Received: (qmail 5346 invoked by uid 22791); 27 Mar 2007 11:56:58 -0000 X-Spam-Check-By: sourceware.org Received: from sophia.inria.fr (HELO sophia.inria.fr) (138.96.64.20) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Mar 2007 12:56:56 +0100 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.13.8/8.13.8) with ESMTP id l2RBuq23016181; Tue, 27 Mar 2007 13:56:52 +0200 Received: from garfield.inria.fr (garfield.inria.fr [138.96.88.66]) (authenticated bits=0) by sophia.inria.fr (8.13.8/8.13.8) with ESMTP id l2RBuISZ016023 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 27 Mar 2007 13:56:18 +0200 Subject: Re: Log every call and exit in embedded system From: Mathieu Lacage To: John Zoidberg Cc: Andrew STUBBS , gdb@sourceware.org In-Reply-To: References: <46079A7F.4020308@st.com> <1174904601.2370.5.camel@mathieu> Content-Type: text/plain Date: Tue, 27 Mar 2007 11:56:00 -0000 Message-Id: <1174996577.3988.22.camel@garfield.inria.fr> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sophia.inria.fr [138.96.64.20]); Tue, 27 Mar 2007 13:56:28 +0200 (MEST) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00325.txt.bz2 On Tue, 2007-03-27 at 12:07 +0100, John Zoidberg wrote: > Your tool seems very interesting, it's unfortunate it's not ready for > embedded systems. > On the documentation you mention malloc, but some embedded systems > don't have the code for malloc. Moreover, no embedded system uses > glibc, it uses newlib, uclib, and others... this means that the code > that is linked may not have the support for it (i.e. there are missing > functions). > There is the issue of the target code (the part that is linked to the > application) must be compiled with the corresponding GCC (for the > target system). > And besides all this, there is the issue of where to log the > information or how to send it. The way I have implemented this is that I store in a circular buffer (one per user thread) the address of the function. Then, I have another thread (the manager thread) which reads data from every circular buffer and writes it in a global log file. It also stores in this global log file the memory map of your program whenever it changes because of a dlopen. The thread stuff is really an optimization to avoid as much as possible locking from the user program if I can avoid it: you could write into the log file directly from the __cyg_* functions. And then, there is a post-processing tool which reads the binary log and generates a human-readable output based on the program memory map, the symbol addresses and the debugging information found in the binaries. There is some platform-specific code to make sure that I am notified upon every memory map change (I place an int3 breakpoint in the r_debug data structure to get link map changes through a unix signal). You could avoid this problem by simply scanning the link map all the time whenever you write a new symbol in the log file. Mathieu --