From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91099 invoked by alias); 5 Oct 2015 18:54:43 -0000 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 Received: (qmail 91086 invoked by uid 89); 5 Oct 2015 18:54:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=5.1 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 X-HELO: p3plwbeout03-05.prod.phx3.secureserver.net Received: from p3plsmtp03-05-2.prod.phx3.secureserver.net (HELO p3plwbeout03-05.prod.phx3.secureserver.net) (72.167.218.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 05 Oct 2015 18:54:41 +0000 Received: from localhost ([72.167.218.243]) by p3plwbeout03-05.prod.phx3.secureserver.net with bizsmtp id RWug1r0025FgiYg01WugKT; Mon, 05 Oct 2015 11:54:40 -0700 X-SID: RWug1r0025FgiYg01 Received: (qmail 14649 invoked by uid 99); 5 Oct 2015 18:54:40 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" User-Agent: Workspace Webmail 5.15.9 Message-Id: <20151005115437.5c1bb9f86d671edec44bb378f25c04cc.28494d3874.wbe@email03.secureserver.net> From: To: "Doug Evans" Cc: "Peter Griffin" , "Andreas Arnez" , "gdb" , "Lee Jones" Subject: RE: RFC GDB Linux Awareness analysis Date: Mon, 05 Oct 2015 18:54:00 -0000 Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00015.txt.bz2 duane> 7) A good example of scripting is during postmortem debug duane> GDB cannot call (execute) a helper function within the=20 duane> target because the target is not =E2=80=9Clive=E2=80=9D doug> Depends on what the helper function does of course. doug> E.g., it's possible to resurrect a corefile (assuming it hasn't been doug> truncated, etc.) enough to run a pretty-printer contained in the=20 doug> app (as opposed to in python). Yes, as you said "it depends on what it does" I would say almost categorically you *cannot* use the target pretty printer. Bare metal is often a synonym for "cross compiling". That means host !=3D target, and loading a complete image into a real target is=20 not always viable, or possible. (ie: You may need to construct MMU page tables, or initialize memory decoders, or DDR to make memory work. The advantage is: The Target CPU might be able to execute opcodes :-) The easier method is loading into a 'memory only' emulation, and do not=20 support execution. Yes, you could use an opcode simulator... (ie: the=20 armulator) but that is not viable for all CPU types. Using your "pretty print" solution as the example - another problem is the run time library support. I'll bet it would be very helpful to use the targets version of "printf()" in some way (maybe sprintf()) The problem is often the underlying printf() routines in the target=20 C library in some cases [often!] use malloc/free to manage buffers And thus, often make use of some OS feature like a semaphore or mutex. Thus, while calling this special function interrupts get turned back on and who knows what else get changed. Every target is different, every embedded system is different. Some of these pretty print problems also occur when live debugging. This whole area is one giant rat hole of problems to make work universally. -Duane.