From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114945 invoked by alias); 8 Oct 2016 14:38:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 114928 invoked by uid 89); 8 Oct 2016 14:38:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Oct 2016 14:38:03 +0000 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u98EYBuN028092 for ; Sat, 8 Oct 2016 10:38:02 -0400 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 25xwb12s3j-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Sat, 08 Oct 2016 10:38:01 -0400 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sat, 8 Oct 2016 15:37:59 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sat, 8 Oct 2016 15:37:57 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id CFCA31B08023 for ; Sat, 8 Oct 2016 15:39:55 +0100 (BST) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u98EbunF10158560 for ; Sat, 8 Oct 2016 14:37:56 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u98Ebulo010157 for ; Sat, 8 Oct 2016 08:37:56 -0600 Received: from oc8523832656.ibm.com (icon-9-167-238-57.megacenter.de.ibm.com [9.167.238.57]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u98EbuQi010154; Sat, 8 Oct 2016 08:37:56 -0600 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id 10ABE10BEE3; Sat, 8 Oct 2016 16:37:55 +0200 (CEST) Subject: Re: set sysroot command on AIX has no effect. To: sangamesh.swamy@in.ibm.com (Sangamesh Mallayya) Date: Sat, 08 Oct 2016 14:38:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Sangamesh Mallayya" at Oct 08, 2016 06:44:40 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16100814-0040-0000-0000-00000241970E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16100814-0041-0000-0000-00002218F034 Message-Id: <20161008143755.10ABE10BEE3@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-08_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610080256 X-SW-Source: 2016-10/txt/msg00187.txt.bz2 Sangamesh Mallayya wrote: >> Well, of course, you have to check for NULL. What I'm suggesting is to >> use something along the lines of: >> >> found_pathname = solib_find (filename, &found_file); >> if (found_pathname == NULL) >> // error handling >> archive_bfd = solib_bfd_fopen (found_pathname, found_file); > >Yes, i did try these steps. But this won't set the sysroot path as we >intend to. >The final object filename we want is the one returned from solib_find, >which is a sysroot prefixed pathname. >After solib_bfd_fopen call we can't refer to found_pathname as it's been >freed in solib_bfd_fopen at the end, and assertion failure later. Well, if you want to reuse the found_pathname, you'll just have to duplicate it (there's already a call to xstrdup later in the function, you may have to move it earlier). >> > + pathname = solib_find (filename, &found_file); >> > + if (pathname == NULL) >> > + perror_with_name (filename); >> > archive_bfd = gdb_bfd_open (filename, gnutarget, -1); >> > if (archive_bfd == NULL) >> > { >> >> This has a number of problems: >> - you still use gdb_bfd_open with filename, which means it still won't >> find the file (I assume you meant to use pathname?) > >pathname we get is something like "/usr/lib/libc.a(shr.o)", Offcourse >their is no such file with this pathname in the system. >So we set a filename as "/usr/lib/libc.a" after separating member name >from actual file and gdb_bfd_open does find the file and return it's bfd. >Here if we pass the path returned from solib_find to gdb_bfd_open instead >of filename then no issue is seen. My point was, the code as shown above does *not* pass the path returned from solib_find to gdb_bfd_open! The path returned from solib_find is assigned to "pathname" (overriding the value pathname that was input to the function), but then gdb_bfd_open is still called with "filename". >I think, better we use found_pathname variable to store returned value >from solib_find instead of using existing pathname variable to avoid >confusion. >And may assign object filename as "object_bfd->filename = xstrdup >(found_pathname);" ? Agreed (see above). However, note that this will *not* contain the object name in parentheses. For example, if you initially get a pathname of: /usr/lib/libc.a(shr.o) Then you separate out the filename into: /usr/lib/libc.a Then you pass this to solib_find and get a full name including sysroot: /path/to/sysroot/usr/lib/libc.a But what you probably want to use as name in the final solib object is: /path/to/sysroot/usr/lib/libc.a(shr.o) My point was that in order to get this, you'll have to append the "(shr.o)" back on to the result you got from solib_find. >The only problem i think if we use solib_find without using >solib_bfd_fopen is found_file descriptor. >Let me know your view. Please do use the pair of solib_find / solib_bfd_fopen; they were designed to be used with each other, that's why they have the interface they do. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com