[gccsdk] stderr 2 file advantage

Ron beeb at woosh.co.nz
Sun Dec 23 14:04:53 PST 2012


In message <20121223124205.46E522522B at orac.inputplus.co.uk>
          Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Ron,
> 
> > I can get this to error (foo.tar is in CSD in RAM:)
> > ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf foo.tar but moving the
> > tar binary to the same directory and all is OK.  tar vxf foo.tar
> 
> Could it be a memory corruption issue and changing the command line is
> altering whether real data as opposed to padding it being trampled?
> Perhaps ensure ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar still fails then
> rename the path to be shorter, character by character, and see if
> there's a pattern to when it works.
> 
> Cheers, Ralph.
>
 
Possible memory corruption is another complication, and rebooting with
different approaches is necessary now and again to stop drawing wrong
conclusions.
It is possible to get the error to toggle just around the changing of
one character, for example I tried something similar to your
suggestion and it appeared to work without the ! in the path.
A reboot dispelled that theory and for 'good measure' worked as expected
not erroring as in the initially described way either.

I am (quietly) confident that the space before tarfile is the actual
culprit because: 
1. I went down a similar road getting the multipart activity to work.
When multiparting, a filename is included in the command and I resolved
it by removing the space. eg  -Ffoo instead of -F foo

2. I haven't seen tar vx -file=foo.tar fail in any situation yet.
I cant just remove the space by doing tar vxffoo.tar  but --file=foo.tar
does allow not having a preceding space before the filename.

ADFS::HardDisc4.$.!TarCtrl.Files.Bin.tar vxf RAM::RamDisc0.$/ptp-gadget.tar
will error unless I set the CSD to the RAM directory, which also means the
full RAM path isn't necessary anyway.

However the full path works without setting CSD if I use --file=RAM::RA...
form.

I'll try applying this later finding to another ELF binary to see if
I can replicate the later illustration.

Thanks, Ron M.






More information about the gcc mailing list