From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18199 invoked by alias); 29 Aug 2006 21:08:34 -0000 Received: (qmail 18190 invoked by uid 22791); 29 Aug 2006 21:08:33 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Aug 2006 21:08:31 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k7TL7uoK023014; Tue, 29 Aug 2006 23:07:56 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k7TL7u5k001070; Tue, 29 Aug 2006 23:07:56 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.8/8.13.8/Submit) id k7TL7tab029171; Tue, 29 Aug 2006 23:07:55 +0200 (CEST) Date: Tue, 29 Aug 2006 21:08:00 -0000 Message-Id: <200608292107.k7TL7tab029171@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: dits365@gmail.com, gdb@sources.redhat.com In-reply-to: <20060829201206.GA28907@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 29 Aug 2006 16:12:06 -0400) Subject: Re: What exactly does "info sharedlibrary" command show? References: <20060829123954.GB12955@nevyn.them.org> <200608291914.k7TJEOPY016721@elgar.sibelius.xs4all.nl> <20060829192758.GA27571@nevyn.them.org> <200608292005.k7TK5M2q021703@elgar.sibelius.xs4all.nl> <20060829201206.GA28907@nevyn.them.org> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00227.txt.bz2 > Date: Tue, 29 Aug 2006 16:12:06 -0400 > From: Daniel Jacobowitz > > Right. As I said, I knew that there were systems where you were > limited to the first segment for this purpose, though I didn't know W^X > used this. We play tricks we the i386's segment registers to accomplish this. We set up a segment descriptor for %cs that doesn't map the complete virtual address space. Then we have to make sure that all executable segments fall into the region covered by that segment descriptor and all writable sections are outside that region. > > > Right now we say it occupies 0x00002aaaaabdf2d0 to 0x00002aaaaacc1a10. > > > > I like this though, since I mostly search the list for code addresses. > > Really? Even if I'm searching for code addresses, I dislike this, > because it has more noise and fewer significant bits. > > Given this I have a hard time finding anything visually: > > 0x00002aaaaabd6910 0x00002aaaaabf1e58 Yes /lib/libreadline.so.5 > 0x00002aaaaad20ef0 0x00002aaaaad43cc8 Yes /usr/lib/libncurses.so.5 > 0x00002aaaaae61dd0 0x00002aaaaaea22b8 Yes /lib/libm.so.6 > 0x00002aaaaafe2000 0x00002aaaaafe2978 Yes /lib/libdl.so.2 > 0x00002aaaab1002d0 0x00002aaaab1e2a10 Yes /lib/libc.so.6 > 0x00002aaaaaaaba80 0x00002aaaaaabc857 Yes /lib64/ld-linux-x86-64.so.2 > 0x00002aaaab50a8e0 0x00002aaaab50dce8 Yes /lib/libthread_db.so.1 > > I find this much easier: > > 0x00002aaaaabd6000 0x00002aaaaabf2000 Yes /lib/libreadline.so.5 > 0x00002aaaaad20000 0x00002aaaaad44000 Yes /usr/lib/libncurses.so.5 > 0x00002aaaaae61000 0x00002aaaaaea3000 Yes /lib/libm.so.6 > 0x00002aaaaafe2000 0x00002aaaaafe3000 Yes /lib/libdl.so.2 > 0x00002aaaab100000 0x00002aaaab1e3000 Yes /lib/libc.so.6 > 0x00002aaaaaaab000 0x00002aaaaaabd000 Yes /lib64/ld-linux-x86-64.so.2 > 0x00002aaaab50a000 0x00002aaaab50e000 Yes /lib/libthread_db.so.1 Yup, if you can guarantee that the first segment indeed includes all the .text code, the latter is much better. > But, it's not a big deal. If you actually prefer the way it is now, > I guess I'll leave it alone after all. > > > True. Somehow we should make the load address of a shared library > > available. > > Should we use segments in "info files" when available? Not sure. For me, the sections are much more useful, and the segments wouldn't really add much information.