A Question

A Question

[Thomas Dineen]

Gentlepeople:

      Is there the equivalent of a core file on Windows?

      If yes where is it found?

      Do you have to generate one?

Thank You
Thomas Dineen

Re: A Question

[Eli Zaretskii]

> Date: Tue, 04 Feb 2014 10:06:23 -0800
> From: Thomas Dineen <tdineen@ix.netcom.com>
> 
>       Is there the equivalent of a core file on Windows?

Not really.  There are crash dumps, which are similar.  But GDB
doesn't support them.

Re: A Question

[Christopher Faylor]

On Tue, Feb 04, 2014 at 10:06:23AM -0800, Thomas Dineen wrote:
>Gentlepeople:
>
>      Is there the equivalent of a core file on Windows?
>
>      If yes where is it found?
>
>      Do you have to generate one?

Cygwin executables can produce real linux-like core files but it is not
the default.

http://cygwin.com/

Re: a question

[Daniel Jacobowitz]

On Wed, Aug 15, 2007 at 05:20:23PM -0700, Marius Nita wrote:
> I have a rather specific question regarding the code below, which is
> in bfd/aout-arm.c line 420. This code seems to deal with bit-level
> endianness. E.g. a "char" address holding a bit pattern 00010000
> represents 0x10 on one endianness and 0x08 on the other. The r_length
> left-shift below shifts data by 5 bits on big-endian and 1 bit on
> little-endian. The r_length data will end up occupying 2 bits in the
> natptr->r_type[0] byte. On big-endian, they'll be bits 6 and 7, and on
> little-endian, they are bits 2 and 3.
> 
> My question is: why aren't the bits in r_length "reversed" to conform
> with bit-level endianness? For example, if the r_length bits are "10",
> this left-shift results in "0100 0000" on big-endian and "0000 0100"
> on little-endian. These bit strings are clearly not the reverse of
> each other.

Each byte is written out, one at a time.  At that point there is no
definition of "endianness".  Bitfields are always special, since they
are at finer than byte resolution.  Try writing the obvious C struct
equivalent of the data type, and think about how it's laid out in each
endianness.

I don't want to know what you're doing that involves ARM and a.out;
whatever it is, use ELF instead :-)

-- 
Daniel Jacobowitz
CodeSourcery

a question

[Marius Nita]

Hi, I am trying to understand some endian-specific code in GDB (well,
BFD for the purpose of this message). I would greatly appreciate any
help.

I have a rather specific question regarding the code below, which is
in bfd/aout-arm.c line 420. This code seems to deal with bit-level
endianness. E.g. a "char" address holding a bit pattern 00010000
represents 0x10 on one endianness and 0x08 on the other. The r_length
left-shift below shifts data by 5 bits on big-endian and 1 bit on
little-endian. The r_length data will end up occupying 2 bits in the
natptr->r_type[0] byte. On big-endian, they'll be bits 6 and 7, and on
little-endian, they are bits 2 and 3.

My question is: why aren't the bits in r_length "reversed" to conform
with bit-level endianness? For example, if the r_length bits are "10",
this left-shift results in "0100 0000" on big-endian and "0000 0100"
on little-endian. These bit strings are clearly not the reverse of
each other.

Any help would be much appreciated!

Thank you!

-m

  if (bfd_header_big_endian (abfd))
    {
      natptr->r_index[0] = r_index >> 16;
      natptr->r_index[1] = r_index >> 8;
      natptr->r_index[2] = r_index;
      natptr->r_type[0] =
    (  (r_extern ?   RELOC_STD_BITS_EXTERN_BIG: 0)
     | (r_pcrel  ?   RELOC_STD_BITS_PCREL_BIG: 0)
     | (r_neg    ?   RELOC_ARM_BITS_NEG_BIG: 0)
     | (r_length <<  RELOC_STD_BITS_LENGTH_SH_BIG));
    }
  else
    {
      natptr->r_index[2] = r_index >> 16;
      natptr->r_index[1] = r_index >> 8;
      natptr->r_index[0] = r_index;
      natptr->r_type[0] =
    (  (r_extern ?   RELOC_STD_BITS_EXTERN_LITTLE: 0)
     | (r_pcrel  ?   RELOC_STD_BITS_PCREL_LITTLE: 0)
     | (r_neg    ?   RELOC_ARM_BITS_NEG_LITTLE: 0)
     | (r_length <<  RELOC_STD_BITS_LENGTH_SH_LITTLE));
    }