This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug corefiles/11804] Fix -Wl,-z,relro gcore writer (+maybe reader)
- From: "rguenth at gcc dot gnu dot org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: 31 Aug 2010 14:10:25 -0000
- Subject: [Bug corefiles/11804] Fix -Wl,-z,relro gcore writer (+maybe reader)
- References: <20100710211433.11804.jan.kratochvil@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From rguenth at gcc dot gnu dot org 2010-08-31 14:10 -------
> (In reply to comment #10)
> > Hm. The .dynamic section in memory is different from that in the file-backing
> > (at least DT_DEBUG has been filled in by the dynamic loader). But still the
> > page is marked clean in /proc/smaps.
>
> I have tested this on Fedora14snapshot + kernel-2.6.33.6-147.fc13.x86_64
> and it works for me.
>
> ./gdb -nx /usr/libexec/postfix/qmgr
> GNU gdb (GDB) 7.2.50.20100831-cvs
> [...]
> This GDB was configured as "x86_64-unknown-linux-gnu".
> [...]
> Reading symbols from /usr/libexec/postfix/qmgr...(no debugging symbols
> found)...done.
> (gdb) start
> Temporary breakpoint 1 at 0x8ae0
> Starting program: /usr/libexec/postfix/qmgr
> [Thread debugging using libthread_db enabled]
> Temporary breakpoint 1, 0x00007ffff7fbdae0 in main ()
> (gdb) info files
> `/usr/libexec/postfix/qmgr', file type elf64-x86-64.
> [...]
> 0x00007ffff81ff940 - 0x00007ffff81ffba0 is .dynamic
>
> 7ffff81fe000-7ffff8200000 r--p 00049000 fd:01 6523997
> /usr/libexec/postfix/qmgr
> Size: 8 kB
> Rss: 8 kB
> Pss: 8 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 8 kB
> Referenced: 8 kB
> Swap: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
>
> unpatched:
> [92] load NOBITS 00007ffff81fe000 115dec 002000 00 A
> 0 0 1
>
> patched:
> [92] load PROGBITS 00007ffff81fe000 002000 00 A 0 0 1
>
> Thanks for the testing, though.
>
> From your dumps I believe your .dynamic was at 0x7fac68cc1bc0 and its DT_DEBUG
> was at 0x7fac68cc1d18 which would suggest there is some problem in Linux
> kernel's content of /proc/PID/smaps.
Yeah - I've bounced it to our kernel folks. New started processes work fine,
but a lot of old processes on my system have lost the dirty bits in
/proc/smaps ... let's see what their response will be.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11804
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.