From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15410 invoked by alias); 3 Jul 2007 22:46:12 -0000 Received: (qmail 15401 invoked by uid 22791); 3 Jul 2007 22:46:12 -0000 X-Spam-Check-By: sourceware.org Received: from houpop.exchsvc.com (HELO housmtp.exchsvc.com) (63.96.4.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 03 Jul 2007 22:46:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Can this be happening? Date: Tue, 03 Jul 2007 22:46:00 -0000 Message-ID: From: "Mohammed, Moqtadir" To: "Daniel Jacobowitz" , "Jim Blandy" Cc: X-IsSubscribed: yes 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 X-SW-Source: 2007-07/txt/msg00036.txt.bz2 > -----Original Message----- > From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org]On > Behalf Of Mohammed, Moqtadir >=20 > > -----Original Message----- > > From: Daniel Jacobowitz [mailto:drow@false.org] > >=20 > > On Tue, Jul 03, 2007 at 02:38:51PM -0700, Jim Blandy wrote: > > > I don't know why the upper bits would be set. GDB may be > > > misinterpreting the information in the core file. > >=20 > > The kernel dumps it as 32-bit too. It's not clear what=20 > those bits are > > for, but I bet they're really in your core dump and you=20 > should ask the > > kernel developers. > >=20 > > Moves from the segment registers may leave implementation=20 > defined data > > in the upper half register - but that's only for fairly old Intel > > processors. >=20 > I didn't knew that the dump itself was 32 bit. Will check the=20 > core dump code > in kernel to see if it is truncating or not before dumping. >=20 Just for the record, I see that in http://lxr.linux.no/source/fs/binfmt_elf.c#L1473 They truncate the segment registers to 16 bit for all the threads in the process except the current thread whose regs do not get truncated: There are two calls used :=20 elf_core_copy_regs for the current thread elf_core_copy_task_regs in elf_dump_thread_status() which truncates. Since in my application, the thread that crashed was the current thread, the registers were not truncated and which is probably why we see 32bit val= ues. Someone can please close the bug 2281. Thanks, Moqtadir