RE: Can this be happening?

RE: Can this be happening?

[Mohammed, Moqtadir]

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org]On
> Behalf Of Mohammed, Moqtadir
> 
> > -----Original Message-----
> > From: Daniel Jacobowitz [mailto:drow@false.org]
> > 
> > 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.
> > 
> > The kernel dumps it as 32-bit too.  It's not clear what 
> those bits are
> > for, but I bet they're really in your core dump and you 
> should ask the
> > kernel developers.
> > 
> > Moves from the segment registers may leave implementation 
> defined data
> > in the upper half register - but that's only for fairly old Intel
> > processors.
> 
> I didn't knew that the dump itself was 32 bit. Will check the 
> core dump code
> in kernel to see if it is truncating or not before dumping.
> 
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 : 
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 values.

Someone can please close the bug 2281.

Thanks,
Moqtadir

RE: Can this be happening?

[Mohammed, Moqtadir]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org]
> 
> 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.
> 
> The kernel dumps it as 32-bit too.  It's not clear what those bits are
> for, but I bet they're really in your core dump and you should ask the
> kernel developers.
> 
> Moves from the segment registers may leave implementation defined data
> in the upper half register - but that's only for fairly old Intel
> processors.

I didn't knew that the dump itself was 32 bit. Will check the core dump code
in kernel to see if it is truncating or not before dumping.

Thanks,
Moqtadir

Can this be happening?

[Mohammed, Moqtadir]

Hi all,

I was trying to look at a core dump of a program, and gdb displays the following result for
#info registers

eax            0xa0     160
ecx            0x2      2
edx            0xa      10
ebx            0xa7e3de9c       -1478238564
esp            0xa6babddc       0xa6babddc
ebp            0xa6babe00       0xa6babe00
esi            0xa7ef9d9a       -1477468774
edi            0x838f44c        137950284
eip            0xa7d85cec       0xa7d85cec <mempcpy+28>
eflags         0x50203  [ CF IF RF AC ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0xb010007b       -1341128581
fs             0x0      0
gs             0x33     51

Platform: IA32. (elf)

My question is, how is the register 'es' being reported as a 32 bit value.
I may be completely naive asking this question, but I have been trying to google for anything 
related to it, but haven't found an answer. Is 'es' not supposed to be only 16bit.

TIA,

Moqtadir

Re: Can this be happening?

[Jim Blandy]

"Mohammed, Moqtadir" <Moqtadir_Mohammed@reyrey.com> writes:
> I was trying to look at a core dump of a program, and gdb displays the following result for
> #info registers
>
> eax            0xa0     160
> ecx            0x2      2
> edx            0xa      10
> ebx            0xa7e3de9c       -1478238564
> esp            0xa6babddc       0xa6babddc
> ebp            0xa6babe00       0xa6babe00
> esi            0xa7ef9d9a       -1477468774
> edi            0x838f44c        137950284
> eip            0xa7d85cec       0xa7d85cec <mempcpy+28>
> eflags         0x50203  [ CF IF RF AC ]
> cs             0x73     115
> ss             0x7b     123
> ds             0x7b     123
> es             0xb010007b       -1341128581
> fs             0x0      0
> gs             0x33     51
>
> Platform: IA32. (elf)
>
> My question is, how is the register 'es' being reported as a 32 bit value.
> I may be completely naive asking this question, but I have been trying to google for anything 
> related to it, but haven't found an answer. Is 'es' not supposed to be only 16bit.

Well, actually, GDB thinks they're all 32 bits long:

    static struct type *
    i386_register_type (struct gdbarch *gdbarch, int regnum)
    {
      if (regnum == I386_EIP_REGNUM)
        return builtin_type_void_func_ptr;

      if (regnum == I386_EFLAGS_REGNUM)
        return i386_eflags_type;

      if (regnum == I386_EBP_REGNUM || regnum == I386_ESP_REGNUM)
        return builtin_type_void_data_ptr;

      if (i386_fp_regnum_p (regnum))
        return builtin_type_i387_ext;

      if (i386_mmx_regnum_p (gdbarch, regnum))
        return i386_mmx_type (gdbarch);

      if (i386_sse_regnum_p (gdbarch, regnum))
        return i386_sse_type (gdbarch);

    #define I387_ST0_REGNUM I386_ST0_REGNUM
    #define I387_NUM_XMM_REGS (gdbarch_tdep (current_gdbarch)->num_xmm_regs)

      if (regnum == I387_MXCSR_REGNUM)
        return i386_mxcsr_type;

    #undef I387_ST0_REGNUM
    #undef I387_NUM_XMM_REGS

      return builtin_type_int;
    }

You can always check in GDB:

    (gdb) p sizeof ($cs)
    $1 = 4
    (gdb) ptype $cs
    type = int
    (gdb) 

I don't know why the upper bits would be set.  GDB may be
misinterpreting the information in the core file.

Re: Can this be happening?

[Mark Kettenis]

> From: Jim Blandy <jimb@codesourcery.com>
> Date: Tue, 03 Jul 2007 14:38:51 -0700
> 
> "Mohammed, Moqtadir" <Moqtadir_Mohammed@reyrey.com> writes:
> > I was trying to look at a core dump of a program, and gdb displays the following result for
> > #info registers
> >
> > eax            0xa0     160
> > ecx            0x2      2
> > edx            0xa      10
> > ebx            0xa7e3de9c       -1478238564
> > esp            0xa6babddc       0xa6babddc
> > ebp            0xa6babe00       0xa6babe00
> > esi            0xa7ef9d9a       -1477468774
> > edi            0x838f44c        137950284
> > eip            0xa7d85cec       0xa7d85cec <mempcpy+28>
> > eflags         0x50203  [ CF IF RF AC ]
> > cs             0x73     115
> > ss             0x7b     123
> > ds             0x7b     123
> > es             0xb010007b       -1341128581
> > fs             0x0      0
> > gs             0x33     51
> >
> > Platform: IA32. (elf)
> >
> > My question is, how is the register 'es' being reported as a 32
> > bit value.  I may be completely naive asking this question, but I
> > have been trying to google for anything related to it, but haven't
> > found an answer. Is 'es' not supposed to be only 16bit.
> 
> Well, actually, GDB thinks they're all 32 bits long:

Yes, they are, mostly to keep the remote register packet compatible.
They should really be changed into a 16bit type I guess.

Mark

Re: Can this be happening?

[Daniel Jacobowitz]

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.

The kernel dumps it as 32-bit too.  It's not clear what those bits are
for, but I bet they're really in your core dump and you should ask the
kernel developers.

Moves from the segment registers may leave implementation defined data
in the upper half register - but that's only for fairly old Intel
processors.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Can this be happening?

[Balazs Scheidler]

On Tue, 2007-07-03 at 17:57 -0400, Daniel Jacobowitz wrote:
> 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.
> 
> The kernel dumps it as 32-bit too.  It's not clear what those bits are
> for, but I bet they're really in your core dump and you should ask the
> kernel developers.
> 
> Moves from the segment registers may leave implementation defined data
> in the upper half register - but that's only for fairly old Intel
> processors.
> 

IIRC the processor-defined TSS (Task State Segment) uses 32 bit values
for segment registers, although as I know TSS is not used anymore by
recent kernels. 

-- 
Bazsi