From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29174 invoked by alias); 15 Apr 2008 13:32:00 -0000 Received: (qmail 28860 invoked by uid 48); 15 Apr 2008 13:31:04 -0000 Date: Tue, 15 Apr 2008 13:32:00 -0000 Message-ID: <20080415133104.28859.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug ada/35880] GNAT does not generate debugging information on imported entities In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "knoxj at att dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg01063.txt.bz2 ------- Comment #9 from knoxj at att dot net 2008-04-15 13:31 ------- I was going to update my bug report when I noticed Sam's comments. I used "readelf -a -w test_pacs_cp_package.o" to try to see what was happening, and I saw that the compiler was throwing out any information about the Ada definintion. I would have expected the compiler to hang onto the Ada debug information, but use the IMPORT information for code generation. The linker would then resolve the IMPORT name, and the debugger could see the Ada description. I too realized that shared memory was a red herring, and the real problem was simply the IMPORT implementation. Sam's sample illustrates this much better than the source files I submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35880