[linuxsh-dev] Re: [linux-sh:02691] Re: Use of e_flags field in ELF header

[Daniel J. <dr...@fa...>]

On Mon, Apr 14, 2003 at 11:12:47PM +0900, kaz Kojima wrote:
> Hi,
> 
> "Thomas,Stephen" <ste...@su...> wrote:
> >Apparently, the e_flags field of the ELF Header structure in ELF files
> >is used by SH architectures to indicate the CPU type. The lower 5 bits
> > have the following meaning:
> >
> >     0  = unknown CPU type
> >     1  = SH1
> >     2  = SH2
> >     3  = SH3
> >     5  = SH3 with DSP
> >     8  = SH3E
> >     9  = SH4
> >    10  = SH5
> >
> >The e_flags field is designed to hold architecture specific info, but
> >other architectures don't appear to use it in quite the same way, i.e.
> >to indicate different CPU types.
> >
> >Does anybody know why SH uses e_flags in this way?
> 
> I don't know why SH does so, but MIPS uses the upper 4 bits of e_flags
> to encode ISA. Perhaps there might be another examples.
> 
> >The problem I have is in generating & interpreting core files. When
> >the kernel (V2.4)generates an ELF core dump, it just sets e_flags to 0
> >(hard coded constant) & dumps it. So to get it to generate a valid SH5
> >core dump, I need to modify generic code. There are similar problems
> >with the gdb 'gcore' command.
> 
> Your modification seems the right thing to do.

Why is this an issue?  If the core dump is marked "unknown", then the
ISA should be taken from the executable during a GDB session, and it
should do the right thing.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer