[gccsdk] unixlib directory iteration doesn't work on Fat32FS

I've been trying to build a project stored on a Fat32FS USB pen drive and found make wasn't locating any of the files using the wildcard function. The wildcard was looking for *.cc files so I believe it is to do with suffix swapping.

 

After further investigation I think I've tracked the problem down to the unixlib directory iteration in the unix/dirent.c file. I believe the following comments from the top of the file are relevant.

 

/* It is a common mistake to assume that the offsets returned from

   OS_GBPB is monotonic increasing with unity steps from the start

   offset 0 onwards.  Accoring to the PRMs, the only thing you may

   be sure of is that offset 0 starts the GBPB enumeration and

   offset -1 returned indicates the end of the enumeration.

...

/* After preaching the passion, now the hack : when we're going to do

   the reverse suffix swapping, we will have up to two outstanding OS_GBPB

   sessions : one in the main dir and another in the suffix dir.

   How we're going to give an 'off_t' result in telldir describing these

   two offsets in OS_GBPB ? Well, we are going to rely on unity monotonic

   increase of the offsets and this up to GBPB_MAX_ENUM.  If these

   conditions are not fullfilled, we stop the enumeration.

   Another solution is to return table index numbers which, when presented

   to seekdir, will get looked up in a table giving the two internal dir

   offsets.  */

 

From comments when I mentioned this bug on the ROOL forum it made me think Fat32FS does not increment the value as expected by the hack.

 

Is there anybody who could look at to confirm my findings (and possibly fix) this?

 

Regards,

Alan

Re: [gccsdk] stderr 2 file advantage

On 03/03/2013 02:43, Ron wrote:
[snippity]
>
> I have noticed lately a lot of tar/gz files from the web are actually
> just plain tar files, so if a compressed archive doesn't extract, try
> setting compression to none.
>

Sometimes that can be due to the browser automatically ungzipping the
file - IIRC there's some HTTP header which says "this content is
gzipped", so it might be that you're seeing.

Alex.



_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Re: [gccsdk] stderr 2 file advantage

In message <2d6cc70253.beeb@ron1954.woosh.co.nz>
Ron <beeb@woosh.co.nz> wrote:

> In message <20121223124205.46E522522B@orac.inputplus.co.uk>
> Ralph Corderoy <ralph@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.
>
<snip more inuendo>

Just to update, I made a lot of changes to circumnavigate suspicious
areas, replaced arguments with environment variable, did away with
fork/exec to the CLI for file renaming, (a modified tar now does this
much easier) but still got a few segmentation erorrs.

By looking at the backtrace, I removed a couple of un-needed functions
in the vicinity of the crash and haven't had any more errors since.
The last one removed was related to pwuid (or something similar)

The new bright shining !TarCtrl app is available at
http://homepages.woosh.co.nz/ron.may/tarctrl.zip

I have noticed lately a lot of tar/gz files from the web are actually
just plain tar files, so if a compressed archive doesn't extract, try
setting compression to none.

Thanks, Ron M.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

HTML5 potential problem

Hi

Not sure if the developers are aware of this, but as HTML5 is in
progress for NetSurf, it is worth pointing the following out.

A developer has found a bug in other browsers that exploits the
local storage specifications and can dump lots of data on users
computers:

<http://bbc.co.uk/news/technology-21628622>

<http://feross.org/fill-disk/>

--
Kev Wells http://riscos.kevsoft.co.uk/
http://kevsoft.co.uk/ http://kevsoft.co.uk/AleQuest/
ICQ 238580561
Motorcycling News http://bikes.kevsoft.co.uk/

Re: lwc PPC460ex on-chip memory optimisations

On 02/03/2013 00:43, Chris Young wrote:
> As alluded to earlier, I've modified libwapcaplet so it is
> optimised for the PPC460ex's on-chip memory, under AmigaOS 4.1.
>
> The changes are:
> * The lwc_string structures are now allocated from memory pools of
> 64KB chunks (this is largely because the PPC460's OCM is 64K in size,
> so that becomes the first pool)

How is the allocation of the OCM itself handled?
By the OS?
Does it still work if some other app (or another NS instance) already
uses it?

François.

Re: lwc PPC460ex on-chip memory optimisations

On Sat, 02 Mar 2013 14:16:20 +0100, François Revol wrote:

> How is the allocation of the OCM itself handled?
> By the OS?

There's a library (a resource actually, but there's not much
difference) which allows an application to gain and relinquish
exclusive access to that memory.

> Does it still work if some other app (or another NS instance) already
> uses it?

It won't be able to use the OCM if some other task has already
obtained access to it. In the case of lwc, it will fail over to using
main memory. NetSurf here has always been restricted to one instance
(running it twice signals the first instance to open another window)

Chris

lwc PPC460ex on-chip memory optimisations

As alluded to earlier, I've modified libwapcaplet so it is
optimised for the PPC460ex's on-chip memory, under AmigaOS 4.1.

The changes are:
* The lwc_string structures are now allocated from memory pools of
64KB chunks (this is largely because the PPC460's OCM is 64K in size,
so that becomes the first pool)
* The strings themselves are now allocated separately to the
lwc_string structure via malloc (this moves the malloc allocation to
the string, with the structure taken from the pool - so we're
still only doing one malloc per string for minimal performance impact)
* Destructor added to free all used memory and pools

I'm seeing an approx 10% improvement in string interning on the
PPC460ex, and no material change on my PPC440 (with no OCM) in basic
tests. I'd quite like to get this or something like it merged in to
trunk, as it provides a small improvement to NetSurf on the right
architecture (and the SAM460s are quite popular).

I've pushed these changes to the branch "chris/sam460-ocm" for
testing, benchmarking, criticism, etc.

Chris