[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [microblaze-uclinux] microblaze-uclinux-elf2flt mistranslation



On Mon, 2009-06-01 at 13:23 -0500, Steven J. Magnani wrote:
> On Wed, 2009-05-27 at 11:04 -0400, Rod Campbell wrote:
> > Hi Steve,
> > 
> > I ran into the same problem a year or so ago.  I posted this issue to 
> > the group in June of 2008:
> > http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/archive/2008/06/msg00108.html
> > 
> > I came to the same conclusions that you did.  Instead of spending a lot 
> > of time trying to fix elf2flt, I developed a work-around:
> > 
> > * Take the same elf file that was used by elf2flt to generate the flat 
> > executable and create a binary file with mb-objcopy.
> > * Replace the .data section of the flat executable with the binary 
> > file's version. 
> > 
> > I created a utility to do compare the 2 data sections and do the 
> > replacement.  I often see a couple mismatches between the binary file's 
> > data section and the flat file's.  I have this as part of every 
> > microblaze compile.
> 
> OK, I tried something similar. I found that 'fixing' the flat data
> section can actually break a program. Specifically, it looks like
> 'agetty' has a table of days of the week. In my build, the pointer to
> "Fri" mistranslates as a pointer to "\r\n". A brute-force copy of the
> ELF .data section to the FLT file fixes the corruption, but agetty then
> fails to display a login prompt.

My bad. The 'dd' command I was using to patch the FLT file needed a
conv=notrunc. For the record, here is the script I use to do the
patching:

----------

#!/bin/sh
#
#       File:   fixflt.sh
#
#       D E S C R I P T I O N
#
#       This Shell script detects and repairs corruption in FLT
#       executables that are the result of a buggy elf2flt conversion.
#
#       Credit to Rod Campbell <rod@xxxxxxxxxxxxxxxxxx> for the
#       strategy.
#
#       R E V I S I O N    H I S T O R Y
#
#       06/01/09    Steven J. Magnani, Digital Design Corporation
#                   Created.
#
###############################################################################

ME=`basename $0`
FLTFILE=$1

if [ ! -f $FLTFILE ] ; then
    echo $ME: $FLTFILE not found.
    exit 1
fi

STARTHEX=`microblaze-uclinux-flthdr -p $FLTFILE 2> /dev/null \
    | grep "Data Start" | cut -d: -f2-`

# Exit silently if the file is not a flat executable
[ -z "$STARTHEX" ] && exit 0

if [ ! -f ${FLTFILE}.gdb ] ; then
    echo $ME: ${FLTFILE}.gdb not found.
    exit 1
fi

ENDHEX=`microblaze-uclinux-flthdr -p $FLTFILE | grep "Data End" \
       | cut -d: -f2-`

STARTDEC=`printf "%d" $STARTHEX`
ENDDEC=`printf "%d" $ENDHEX`
FLTDATALEN=`expr $ENDDEC - $STARTDEC`

microblaze-uclinux-objcopy -j .data -O binary $1.gdb /tmp/$$.elf.data
ELFDATALEN=`ls -l /tmp/$$.elf.data | cut -d' ' -f5`

if [ $FLTDATALEN -ne $ELFDATALEN ] ; then
    echo ELF/FLT data segment size mismatch - aborting.
    exit 1
fi

dd if=$FLTFILE of=/tmp/$$.flt.data bs=1 skip=$STARTDEC \
   count=$FLTDATALEN > /dev/null 2>&1
cmp -s /tmp/$$.elf.data /tmp/$$.flt.data
if [ $? -ne 0 ] ; then
    echo $ME: Repairing data mismatch detected in $FLTFILE \
        | tee -a /tmp/mismatches
    dd if=/tmp/$$.elf.data of=$FLTFILE bs=1 seek=$STARTDEC \
       count=$FLTDATALEN conv=notrunc > /dev/null 2>&1
fi

rm -f /tmp/$$.elf.data /tmp/$$.flt.data

----------

I hooked this into the file_copy() function of romfs-inst.sh so all my
FLT executables get checked and repaired. It slows down the build some,
but it does the job. Five of the apps in my userland seem to have
'issues'.

--Steve

> 
> > 
> > Here is a run of tail end of my compile script:
> > mb-flthdr -p la5600
> > la5600
> >     Magic:        bFLT
> >     Rev:          4
> >     Build Date:   Tue May 26 18:07:37 2009
> >     Entry:        0x50
> >     Data Start:   0x2eb40
> >     Data End:     0x41ec0
> >     BSS End:      0x55dc0
> >     Stack Size:   0x8000
> >     Reloc Start:  0x41ec0
> >     Reloc Count:  0x12e7
> >     Flags:        0x1 ( Load-to-Ram )
> > ==============================================================
> > * Compare flat file Data Sect with bin file & fix flat file  *
> > ==============================================================
> > mb-objcopy -O binary la5600.gdb la5600.bin
> > ./la_fltfix -v -f la5600 -b la5600.bin -o la5600
> > ./la_fltfix INFO: Flat File Flags=0x00000001
> > ./la_fltfix INFO: DataSect Len=0x13380,78720 Ofst:Flt=0x2eb40 Bin=0x2eb00
> > ./la_fltfix INFO: DIFF @DataSect+0xf29e Flt=0xec Bin=0xed
> > ./la_fltfix INFO: DIFF @DataSect+0xf29f Flt=0x6c Bin=0xd8
> > ./la_fltfix INFO: DIFF @DataSect+0xf31e Flt=0xec Bin=0xed
> > ./la_fltfix INFO: DIFF @DataSect+0xf31f Flt=0x6c Bin=0xd8
> > ./la_fltfix INFO: 4 DIFFs found
> > ./la_fltfix INFO: Created Output flat file "la5600"
> > ./la_fltfix INFO: Return code=0
> > 
> > I hope this helps.
> > 
> > Rod Campbell
> > 
> > Steven J. Magnani wrote:
> > > Hi,
> > >
> > > Has anyone run into problems with microblaze-uclinux-elf2flt?
> > >
> > > We have a program that contains a constant global array something like
> > > this:
> > >
> > > const struct
> > > {
> > >    const char*          source;
> > >    const char*          target;
> > >    unsigned long        flags;
> > >    const char*          options;
> > >    unsigned int         channel;
> > >    unsigned long        devnum;
> > > } myGlobalStruct[9] = { blah blah blah };
> > >
> > > What we are seeing is for certain sequences of executable code, one of
> > > the .target fields in the array gets mis-translated, so instead of
> > > pointing to the constant string associated with array element [3], it
> > > points to the constant string associated with array element [0]. It's
> > > definitely a translation problem because I can use
> > > microblaze-uclinux-objcopy to extract the .data segment from the .gdb
> > > file and the structure is correct there.
> > >
> > > Depending on how we change the program flow, the problem can come and
> > > go. If we add a printf to one module the problem goes away.
> > >
> > > Any suggestions? Is there a more recent version of microblaze-uclinux
> > > tools available anywhere, or in the works? Tool problems like this make
> > > us very nervous because there's no telling what else is being corrupted.
> > >
> > > Thanks.
> > > ------------------------------------------------------------------------
> > >  Steven J. Magnani               "I claim this network for MARS!
> > >  www.digidescorp.com              Earthling, return my space modulator!"
> > >
> > >  #include <standard.disclaimer>
> > >
> > >
> > > ___________________________
> > > microblaze-uclinux mailing list
> > > microblaze-uclinux@xxxxxxxxxxxxxx
> > > Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> > > Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
> > >
> > >
> > >   
> > 
> > 


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@xxxxxxxxxxxxxx
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/