Re: [gccsdk] ^H^H^H

In message <6e71c20a55.gavin@wra1th.plus.com>
Gavin Wraith <gavin@wra1th.plus.com> wrote:

> Running a C program in a Taskwindow. It reads from stdio and
> outputs it. The backspace key, instead of backspacing,
> produces ^H. I am assuming that this is because the program
> is using gets and puts from the stdio library. Is that
> right? Are there alternative functions that interpret control
> sequences gracefully rather than display control characters with a
> ^-prefix?
>
I'll leave the alternative functions to someone who knows them,
But a quick fix for StrongEd is to have a Taskwindow ModeFile
with
Delete CharstoBuffer("<4>")
Left CharstoBuffer("<2>")
Right CharstoBuffer("<6>")
Up CharstoBuffer("<16>")
Down CharstoBuffer("<14>")

optionally, to enable the use of Ctrl-C that some programs use
change
# c-C ReleaseShiftCtrl BlockCopy
to
cs-C ReleaseShiftCtrl BlockCopy
I also have
c-C CharstoBuffer("<3>")

The arrow key changes allow programs with line editting to have history

Cheers 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

Re: New Netsurf - improved Javascript stability

In message <550abce24acvjazz@waitrose.com>
Chris Newman <cvjazz@waitrose.com> wrote:

> In article <fae9b50a55.jim@abbeypress.net>,
> Jim Nagel <netsurf@abbeypress.co.uk> wrote:
>> Dave Higton wrote on 21 Sep:
>
>> > I downloaded the latest CI build of NS yesterday. There hasn't been
>> > one for quite a while. I noticed that it doesn't crash when opening a
>> > sport page of the BBC News website, for example. This is a big
>> > improvement.
>> > I think we're seeing evidence of big changes within Netsurf.
>
>> Anybody concur?
>
>> I'm on #2935 (Aug 25) and have been suffering a great many sites that
>> time out with no display at all. Sometimes hourglassing goes on
>> forever and there's nothing for it but Alt-Break to kill Netsurf.
>> Some of these cases will succeed if I relaunch Netsurf, switch off
>> Javascript from its iconbar menu, and only then reload the site.
>
> Same here with #2964
>
I recently upgraded to #2964 from #2953 and AFAICS the
javascript-enabled behaviour and functionality* is identical in both,
and I too have the endless hourglassing behaviour unless JS is
disabled. I don't mean to be downbeat or decry the efforts of the
developers - NetSurf is a fine lightweight browser, better than any
RISC OS alternative that I've tried**, and no doubt the developers
would be the first to agree that javascript functionality is very much
a work in progress.

(* virtually non-existent)
(** that doesn't include the recent Otter port)

--
George

[gccsdk] ^H^H^H

Running a C program in a Taskwindow. It reads from stdio and
outputs it. The backspace key, instead of backspacing,
produces ^H. I am assuming that this is because the program
is using gets and puts from the stdio library. Is that
right? Are there alternative functions that interpret control
sequences gracefully rather than display control characters with a
^-prefix?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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: New Netsurf - improved Javascript stability

In article <fae9b50a55.jim@abbeypress.net>,
Jim Nagel <netsurf@abbeypress.co.uk> wrote:
> Dave Higton wrote on 21 Sep:

> > I downloaded the latest CI build of NS yesterday. There hasn't been
> > one for quite a while. I noticed that it doesn't crash when opening a
> > sport page of the BBC News website, for example. This is a big
> > improvement.
> > I think we're seeing evidence of big changes within Netsurf.

> Anybody concur?

> I'm on #2935 (Aug 25) and have been suffering a great many sites that
> time out with no display at all. Sometimes hourglassing goes on
> forever and there's nothing for it but Alt-Break to kill Netsurf.
> Some of these cases will succeed if I relaunch Netsurf, switch off
> Javascript from its iconbar menu, and only then reload the site.

Same here with #2964

--
Chris

Re: New Netsurf - improved Javascript stability

On Tue, 29 Sep 2015 13:39:02 +0100 Jim Nagel wrote:

> Dave Higton wrote on 21 Sep:
>
>> I downloaded the latest CI build of NS yesterday. There hasn't been
>> one for quite a while. I noticed that it doesn't crash when opening a
>> sport page of the BBC News website, for example. This is a big
>> improvement.
>> I think we're seeing evidence of big changes within Netsurf.
>
> Anybody concur?
>
> I'm on #2935 (Aug 25) and have been suffering a great many sites that
> time out with no display at all. Sometimes hourglassing goes on
> forever and there's nothing for it but Alt-Break to kill Netsurf.
> Some of these cases will succeed if I relaunch Netsurf, switch off
> Javascript from its iconbar menu, and only then reload the site.

I still get that, yes.

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: New Netsurf - improved Javascript stability

Dave Higton wrote on 21 Sep:

> I downloaded the latest CI build of NS yesterday. There hasn't been
> one for quite a while. I noticed that it doesn't crash when opening a
> sport page of the BBC News website, for example. This is a big
> improvement.
> I think we're seeing evidence of big changes within Netsurf.

Anybody concur?

I'm on #2935 (Aug 25) and have been suffering a great many sites that
time out with no display at all. Sometimes hourglassing goes on
forever and there's nothing for it but Alt-Break to kill Netsurf.
Some of these cases will succeed if I relaunch Netsurf, switch off
Javascript from its iconbar menu, and only then reload the site.


--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscoslondonshow.co.uk October 24

Re: Netsurf RISC OS and abebooks.co.uk

In article <f3021c0a55.cris@cdewhurst2010.btinternet.com>, Chris Dewhurst
<cdewhurst2010@btinternet.com> wrote:

[Snip]

> Of course the website's code could have changed since I last used t
> but anyone know what's causing this and can it be fixed?

[Snip]

Any page which has 107 instances of the word 'javascript' is likely to
fail in NetSurf, IME.

f8 - search and replace 'javas' for 'javas' in StrongED.

--
Tim Hill
www.timil.com

web sites * multimedia * training

Netsurf RISC OS and abebooks.co.uk

Hi all,

I'm fairly sure Netsurf used to be able to cope with
www.abebooks.co.uk (a while since I've bought any books from it)

At the moment the search results are bunched up in a column on the
right hand side, making it very difficult to read the search results.

Of course the website's code could have changed since I last used t
but anyone know what's causing this and can it be fixed?

thanks :)

--
Chris

Re: href targets and Javascript functions

On Sun, 27 Sep 2015 17:10:14 +0100, Dave Higton wrote:

> There were two lines with links calling Javascript functions that
> had been defined:
>
> <a href="javascript:confirmLeave('jsindex.htm')">Link text</a>
> <a href="javascript:calcVAT()">Link text</a>
[...]
> So can anyone give me any quick start on this:
>
> 1) Am I trying to jump to functionality that is much to far away
> to be implemented now?

I think you're trying to do something which isn't implemented yet,
although I doubt it is so far away that it couldn't be implemented
(I'm really not the best person to advise on this though).

Similar code snippets in onClick, onChange etc aren't implemented yet
either AFAIK.

> 2) If it is within reach, where should I be looking for code that
> should be parsing for link targets that begin with "javascript:"?

I believe the relevant code is javascript/fetcher.c. This is what
controls the "fetching" of "javascript:" URIs. What it is supposed to
do is run the code pointed at, however it looks unimplemented. I'm
surprised you're getting anything out of it, although IIRC there is a
Javascript URL hack somewhere else which might still be active.

Chris

href targets and Javascript functions

I was just looking around some simple Javascript examples, and I
saw some more basic stuff that isn't there yet.

There were two lines with links calling Javascript functions that
had been defined:

<a href="javascript:confirmLeave('jsindex.htm')">Link text</a>
<a href="javascript:calcVAT()">Link text</a>

Clicking the first line's link text changes the window to a 404
complaining that "jsindex.htm" (prepended with the full local path,
of course) is missing.

Clicking the second line's link text opens a "Warning from NetSurf"
box with "BadType", which presumably starts off as the same wrong
action but fails differently because the "file name" is null.

This means that no Javascript function or command can be called
from an HTML href link.

I searched for "href" in the source code, hoping to find where
its arguments are parsed, but there are many references.

So can anyone give me any quick start on this:

1) Am I trying to jump to functionality that is much to far away
to be implemented now?

2) If it is within reach, where should I be looking for code that
should be parsing for link targets that begin with "javascript:"?

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: Patch to correct Javascript date() result

In message <OUT-5605AFD5.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>
"Chris Young" <chris.young@unsatisfactorysoftware.co.uk> wrote:

>On Fri, 25 Sep 2015 20:04:53 +0100, Dave Higton wrote:
>
>> >If you can point us to a test page, maybe we can find out whether this
>> >is RISC OS only or (as I suspect) a problem with all supported
>> >platforms?
>>
>> The attached will do.
>>
>> Please bear in mind that there are various possible paths through the
>> code that gets the date. (It's definitely the Date() function that
>> is in error, not the toString() function.) So a different platform
>> may or may not show the error.
>>
>> The addition of 3600 seconds is such a deliberate inclusion that I
>> have to ask whether it was required on some platform. It is my
>> understanding that localtime() should return the time taking into
>> account both the time zone and possible daylight savings, so really
>> it shouldn't be necessary.
>
>A quick check on AmigaOS reveals it's wrong here on two counts.... or
>maybe it's wrongly correct, I'm not sure.
>Today is 2015-09-25 21:28:16.916+02:00
>Are you getting the correct timezone on RISC OS?

Without my patch, the time is 1 hour in advance and the offset is
shown as +02:00, like you see.

With my patch, the time is correct and the offset is shown as +01:00.

It's possible that the AmigaOS code is running through the error.
All I did was prevent the error on RISC OS, leaving the code for
other platforms unchanged.

Dave

____________________________________________________________
Can't remember your password? Do you need a strong and secure password?
Use Password manager! It stores your passwords & protects your account.
Check it out at http://mysecurelogon.com/manager

Re: Patch to correct Javascript date() result

On Fri, 25 Sep 2015 20:04:53 +0100, Dave Higton wrote:

> >If you can point us to a test page, maybe we can find out whether this
> >is RISC OS only or (as I suspect) a problem with all supported
> >platforms?
>
> The attached will do.
>
> Please bear in mind that there are various possible paths through the
> code that gets the date. (It's definitely the Date() function that
> is in error, not the toString() function.) So a different platform
> may or may not show the error.
>
> The addition of 3600 seconds is such a deliberate inclusion that I
> have to ask whether it was required on some platform. It is my
> understanding that localtime() should return the time taking into
> account both the time zone and possible daylight savings, so really
> it shouldn't be necessary.

A quick check on AmigaOS reveals it's wrong here on two counts.... or
maybe it's wrongly correct, I'm not sure.
Today is 2015-09-25 21:28:16.916+02:00
Are you getting the correct timezone on RISC OS?
Chris

Re: Patch to correct Javascript date() result

On Fri, 25 Sep 2015 20:04:53 +0100, Dave Higton wrote:

> >If you can point us to a test page, maybe we can find out whether this
> >is RISC OS only or (as I suspect) a problem with all supported
> >platforms?
>
> The attached will do.
>
> Please bear in mind that there are various possible paths through the
> code that gets the date. (It's definitely the Date() function that
> is in error, not the toString() function.) So a different platform
> may or may not show the error.
>
> The addition of 3600 seconds is such a deliberate inclusion that I
> have to ask whether it was required on some platform. It is my
> understanding that localtime() should return the time taking into
> account both the time zone and possible daylight savings, so really
> it shouldn't be necessary.

A quick check on AmigaOS reveals it's wrong here on two counts.... or
maybe it's wrongly correct, I'm not sure.

Today is 2015-09-25 21:28:16.916+02:00

Are you getting the correct timezone on RISC OS?

Chris

Re: Patch to correct Javascript date() result

In message <OUT-5605862A.MD-1.4.17.chris.young@unsatisfactorysoftware.co.uk>
"Chris Young" <chris.young@unsatisfactorysoftware.co.uk> wrote:

>On Thu, 24 Sep 2015 22:02:21 +0100, Dave Higton wrote:
>
>> The error is in duktape.c and, as discussed on Monday, I don't think
>> the code can ever be right - but I've made the deliberate error apply
>> only to platforms other than RISC OS.
>
>If you can point us to a test page, maybe we can find out whether this
>is RISC OS only or (as I suspect) a problem with all supported
>platforms?

The attached will do.

Please bear in mind that there are various possible paths through the
code that gets the date. (It's definitely the Date() function that
is in error, not the toString() function.) So a different platform
may or may not show the error.

The addition of 3600 seconds is such a deliberate inclusion that I
have to ask whether it was required on some platform. It is my
understanding that localtime() should return the time taking into
account both the time zone and possible daylight savings, so really
it shouldn't be necessary.

Dave

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: Patch to correct Javascript date() result

On Thu, 24 Sep 2015 22:02:21 +0100, Dave Higton wrote:

> The error is in duktape.c and, as discussed on Monday, I don't think
> the code can ever be right - but I've made the deliberate error apply
> only to platforms other than RISC OS.

If you can point us to a test page, maybe we can find out whether this
is RISC OS only or (as I suspect) a problem with all supported
platforms?

Chris

Patch to correct Javascript date() result

This patch removes the 3600 second error in the date/time returned by
the Javascript date() function in RISC OS.

The error is in duktape.c and, as discussed on Monday, I don't think
the code can ever be right - but I've made the deliberate error apply
only to platforms other than RISC OS.

There may be a better solution than this, which I'd like to research,
but this fixes the problem today.

Dave

diff --git a/javascript/duktape/duktape.c b/javascript/duktape/duktape.c
index 5ee88ad..9cd1b10 100644
--- a/javascript/duktape/duktape.c
+++ b/javascript/duktape/duktape.c
@@ -27893,7 +27893,9 @@ DUK_INTERNAL duk_int_t duk_bi_date_get_local_tzoffset_gmtime(duk_double_t d) {
goto error;
}
if (tms[1].tm_isdst > 0) {
+#if !defined(riscos)
t2 += 3600;
+

Patch to make Javascript writeln() work (attempt 3)

This patch to Document/bnd makes the Javascript writeln() function
work as well as write(). This version inserts "\n", which seems
to be what the language requires. <br> was wrong.

It duplicates code from write(), but I'm really not keen on Daniel's
alternative suggestion. Sorry. (Re. the earlier thread: I think
it pays a third price, that of being less clear than duplicating
code.)

Hope this helps.

Dave

diff --git a/javascript/duktape/Document.bnd b/javascript/duktape/Document.bnd
index 6d11ea9..a97f30e 100644
--- a/javascript/duktape/Document.bnd
+++ b/javascript/duktape/Document.bnd
@@ -13,6 +13,7 @@ class Document {
#include "utils/corestrings.h"
#include "render/html_internal.h"
#include "utils/libdom.h"
+#include "utils/utils.h"
%};
}

@@ -37,6 +38,27 @@ method Document::write()
return 0;
%}

+method Document::writeln()
+%{
+ const char nl[] = "\n";
+ struct html_content *htmlc;
+ duk_size_t text_len;
+ for (int i = 0; i < duk_get_top(ctx); ++i)
+ duk_safe_to_string(ctx, i);
+ duk_concat(ctx, duk_get_top(ctx));
+ const char *text = duk_safe_to_lstring(ctx, 0, &text_len);
+ LOG("Writeln %*s", (int)text_len, text);
+ dom_exception err;
+ err = dom_node_get_user_data(priv->parent.node,
+ corestring_dom___ns_key_html_content_data,
+ &htmlc);
+ if (err == DOM_NO_ERR && htmlc->parser != NULL) {
+ dom_hubbub_parser_insert_chunk(htmlc->parser, (uint8_t *)text, text_len);
+ dom_hubbub_parser_insert_chunk(htmlc->parser, (uint8_t *)nl, SLEN(nl));
+ }
+ return 0;
+%}
+
method Document::createTextNode()
%{
dom_node *newnode;

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

Re: Patch to make Javascript writeln() work

Hi Dave,

On 24/09/15 21:02, Dave Higton wrote:

> You pay two small prices:
>
> 1) it's slower;

I wouldn't worry too much about that unless profiling actually shows it
as in any way significant.

> 2) the log says "Writing..." regardless of whether write() or writeln()
> has been called.

At the moment the JavaScript code logs excessively because its useful
while its being developed. I expect we will remove much of it once
it's more mature.

--
Michael Drake http://www.netsurf-browser.org/

Re: Patch to make Javascript writeln() work

In message <20150924082904.GA14703@somnambulist.local>
Daniel Silverstone <dsilvers@netsurf-browser.org> wrote:

>On Wed, Sep 23, 2015 at 21:43:13 +0100, Dave Higton wrote:
>> Second version using SLEN() instead of strlen().
>>
>> This patch to Document/bnd makes the Javascript writeln() function
>> work as well as write().
>
>>From my reading of the spec, it inserts a newline, not a line break.

I agree! I was playing with some test code today that made me realise
the the results of writeln() are very different if enclosed within
<pre></pre> tags. When I submit a test method, I'll use that.

>Also, you could chain through Document.write to reduce code duplication
>
>(untested)
>
>method Document::writeln()
>%{
> duk_push_this(ctx);
> duk_insert(ctx, 0);
> duk_push_lstring(ctx, "write", SLEN("write"));
> duk_insert(ctx, 1);
> duk_push_lstring(ctx, "\n", SLEN("\n"));
> duk_call_prop(ctx, 0, duk_get_top(ctx) - 1);
> return 0;
>%}
>
>This has the advantage that if we change how Document::write functions
>then we don't need to remember to change that in writeln. Also it gives
>us an example in the codebase of how to invoke a method on an object
>in our bindings which may be of use later.
>
>I don't object to your previous approach, just think this might be cleaner.
>
>Opinions?

If I understand correctly, this builds a call to the write() function,
although at my present level of knowledge I don't understand how it
differentiates between "write" being a call to a function and "\n"
being data that will be appended to the evaluated expression that the
function renders to screen.

You pay two small prices:

1) it's slower;

2) the log says "Writing..." regardless of whether write() or writeln()
has been called.

Neither of them is in any way a show stopper of course.

Like you, I prefer to share code where possible, but I don't find this
solution very appealing.

I'd like to call a third function, passing a boolean argument to
represent whether write() or writeln() is called, and make the choice
at two places in the code. But where do you put the third function,
which looks like the Document::write() method but doesn't map to any
Javascript method?

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Re: Patch to make Javascript writeln() work

On Wed, Sep 23, 2015 at 21:43:13 +0100, Dave Higton wrote:
> Second version using SLEN() instead of strlen().
>
> This patch to Document/bnd makes the Javascript writeln() function
> work as well as write().

>From my reading of the spec, it inserts a newline, not a line break.

Also, you could chain through Document.write to reduce code duplication

(untested)

method Document::writeln()
%{
duk_push_this(ctx);
duk_insert(ctx, 0);
duk_push_lstring(ctx, "write", SLEN("write"));
duk_insert(ctx, 1);
duk_push_lstring(ctx, "\n", SLEN("\n"));
duk_call_prop(ctx, 0, duk_get_top(ctx) - 1);
return 0;
%}

This has the advantage that if we change how Document::write functions
then we don't need to remember to change that in writeln. Also it gives
us an example in the codebase of how to invoke a method on an object
in our bindings which may be of use later.

I don't object to your previous approach, just think this might be cleaner.

Opinions?

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

Patch to make Javascript writeln() work

Second version using SLEN() instead of strlen().

This patch to Document/bnd makes the Javascript writeln() function
work as well as write().

diff --git a/javascript/duktape/Document.bnd b/javascript/duktape/Document.bnd
index 6d11ea9..0e07f24 100644
--- a/javascript/duktape/Document.bnd
+++ b/javascript/duktape/Document.bnd
@@ -13,6 +13,7 @@ class Document {
#include "utils/corestrings.h"
#include "render/html_internal.h"
#include "utils/libdom.h"
+#include "utils/utils.h"
%};
}

@@ -37,6 +38,27 @@ method Document::write()
return 0;
%}

+method Document::writeln()
+%{
+ const char br[] = "<br>";
+ struct html_content *htmlc;
+ duk_size_t text_len;
+ for (int i = 0; i < duk_get_top(ctx); ++i)
+ duk_safe_to_string(ctx, i);
+ duk_concat(ctx, duk_get_top(ctx));
+ const char *text = duk_safe_to_lstring(ctx, 0, &text_len);
+ LOG("Writeln %*s", (int)text_len, text);
+ dom_exception err;
+ err = dom_node_get_user_data(priv->parent.node,
+ corestring_dom___ns_key_html_content_data,
+ &htmlc);
+ if (err == DOM_NO_ERR && htmlc->parser != NULL) {
+ dom_hubbub_parser_insert_chunk(htmlc->parser, (uint8_t *)text, text_len);
+ dom_hubbub_parser_insert_chunk(htmlc->parser, (uint8_t *)br, SLEN(br));
+ }
+ return 0;
+%}
+
method Document::createTextNode()
%{
dom_node *newnode;

Hope this helps.

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Patch to make Javascript writeln() work

This patch to Document/bnd makes the Javascript writeln() function
work as well as write().

diff --git a/javascript/duktape/Document.bnd b/javascript/duktape/Document.bnd
index 6d11ea9..ee5d7af 100644
--- a/javascript/duktape/Document.bnd
+++ b/javascript/duktape/Document.bnd
@@ -37,6 +37,27 @@ method Document::write()
return 0;
%}

+method Document::writeln()
+%{
+ const char br[] = "<br>";
+ struct html_content *htmlc;
+ duk_size_t text_len;
+ for (int i = 0; i < duk_get_top(ctx); ++i)
+ duk_safe_to_string(ctx, i);
+ duk_concat(ctx, duk_get_top(ctx));
+ const char *text = duk_safe_to_lstring(ctx, 0, &text_len);
+ LOG("Writeln %*s", (int)text_len, text);
+ dom_exception err;
+ err = dom_node_get_user_data(priv->parent.node,
+ corestring_dom___ns_key_html_content_data,
+ &htmlc);
+ if (err == DOM_NO_ERR && htmlc->parser != NULL) {
+ dom_hubbub_parser_insert_chunk(htmlc->parser, (uint8_t *)text, text_len);
+ dom_hubbub_parser_insert_chunk(htmlc->parser, (uint8_t *)br, strlen(br));
+ }
+ return 0;
+%}
+
method Document::createTextNode()
%{
dom_node *newnode;

Hope this helps.

Dave

____________________________________________________________
Share photos & screenshots in seconds...
TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if1
Works in all emails, instant messengers, blogs, forums and social networks.

Re: [gccsdk] OS_GBPB heeby jeebies

Hi Gavin,

> You are a genius. Thanks.

I'm often told I "full of it". ;-)
But it was not I that pointed this out, but Nick Burrett.
http://www.riscos.info/pipermail/gcc/2015-September/006473.html

> I guess I had not properly appreciated what 'const' meant.

I recommend Chris Lattner's three posts on what a C compiler can assume;
I think you may be surprised. It starts with
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Cheers, Ralph.

_______________________________________________
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] OS_GBPB heeby jeebies

Ralph

> This is the problem.

You are a genius. Thanks. That solved the problem.
I guess I had not properly appreciated what 'const'
meant.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] OS_GBPB heeby jeebies

Hi Gavin,

> > ^ shouldn't that be static int? Wouldn't the const imply that the
> > buffer never changes

This is the problem.

> The buffer doesn't change. It's its contents that change. I will try
> removing the const.

The buffer is its contents. As an array rather than a pointer the
address of its first element will never change with or without the
const. The const is saying the elements' values are constant. Constant
at zero since it's a static and not initialised to anything else.

> Why are the filetypes coming out as zero, rather than some other
> value?

Because the compiler can assume the contents of a static const array
that's not initialised to anything are zero and doesn't need to load
from memory; check the assembler.

Cheers, Ralph.

_______________________________________________
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

[gccsdk] OS_GBPB heeby jeebies

By the way, I think I should have spelled it OS_GBPB. I always get this
wrong. Think 'heeby-jeeby'.

> ^ shouldn't that be static int? Wouldn't the const imply that the buffer
> never changes

The buffer doesn't change. It's its contents that change. I will try
removing the const.

> Sounds like rdir_buf is being re-used

The same code worked fine when compiled with Norcroft. With other stuff
omitted the code is:

#include sys.h

where sys.h contains:

extern int rdir(const char *dir, const int *buf, int offset);

followed by:

static int rdir_iter (lua_State *L);
#define RDIR_BUFLEN 256
static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];

static int rdir_read (lua_State *L) {
lua_pushinteger(L,0); /* start */
lua_pushstring(L,lua_tostring(L,1));
lua_pushcclosure(L,&rdir_iter,2);
return 1;
}

static int rdir_iter (lua_State *L) {
int n;
int offset = (int) lua_tointeger(L,lua_upvalueindex(1));
const char * dir = lua_tostring(L,lua_upvalueindex(2));
n = rdir(dir,rdir_buf,offset);
if (n == -1) {
lua_pushnil(L);
return 1;
}
else {
lua_pushinteger(L, n);
lua_replace(L, lua_upvalueindex(1)); /* new offset */
lua_pushstring(L, (char *)(&rdir_buf[6])); /* name */
lua_pushinteger(L, rdir_buf[5]); /* filetype */
return 2;
}
}

and where rdir is defined in sys.s by:

.global rdir
.set BUFLEN, 256

rdir:
stmfd sp!,{r1-r6,r14}
mov r6,#0 @ no wild card
mov r5,#BUFLEN @ bufferlength
mov r4,r2 @ offset
mov r3,#1 @ number of items
mov r2,r1 @ buffer
mov r1,r0 @ directory name
mov r0,#12
swi 0x2000c @ XOS_GBPB
movvs r3,#0
cmp r3,#1
moveq r0,r4 @ next offset
mvnne r0,#0 @ -1 if no more
ldmfd sp!,{r1-r6,pc}
.type rdir %function
.size rdir, .-rdir

I am pretty sure that there is nothing wrong with rdir. After all,
the names are getting returned OK. Every time rdir is called from
within rdir_iter the buffer rdir_buf gets overwritten by the SWI.
That is how it is supposed to work. Nothing else messes with it.
You can forget about rdir_read; that is just the top level of the
C code called by RiscLua's riscos.dir function. The pages 2-70
and 2-71 in the PRMs explain what OS_GBPB is supposed to be doing.

Why are the filetypes coming out as zero, rather than some other value?
It has to be something trivial that I am not seeing. Actually, it does
not really matter; if I cut out the filetype part and just had the name
returned, that would be quite adequate for practical purposes. But then
I would still be left wondering why this code is not doing what is wanted.
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] OS_GPBP conundrum

On 21 September 2015 at 13:31, Gavin Wraith <gavin@wra1th.plus.com> wrote:

I have some code that uses OS_GPBP 12 to iterate
over objects in a directory, returning for each one
its name and filetype. It has been working for years
in RiscLua, when compiled with Norcroft and Objasm.
Now that I am using GCC the filetype is always
returned as zero, and I cannot see why.

OS_GPBP 12 uses a buffer to return its results,
with the object's name as a zero-terminated
string at buf+24, and the filetype in the word
at buf+20. I declare a buffer with

static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];

^ shouldn't that be static int? Wouldn't the const imply that the buffer never changes and could be liable to some optimisation in the way members are accessed?

Nick

Re: [gccsdk] OS_GPBP conundrum

Hi Gavin,

> static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];
...
> lua_pushstring(L, (char *)(&rdir_buf[6])); /* name */
> lua_pushinteger(L, rdir_buf[5]); /* file type */
> return 2; /* number of returned values */
...
> The 'name' part comes out OK, but the 'ftype' is always zero, and I
> just cannot see why.

Sounds like rdir_buf is being re-used, but only the first 24 bytes of
it, trampling the filetype, but not the filename, before the push. Do
you see filetype in rdir_buf[5] when you lua_pushinteger() above? If
so, what happens between the push of the correct filetype and the pull
where it's wrong? If not, show us the OS_GPBP 12 call?

Cheers, Ralph.

_______________________________________________
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

[gccsdk] OS_GPBP conundrum

I have some code that uses OS_GPBP 12 to iterate
over objects in a directory, returning for each one
its name and filetype. It has been working for years
in RiscLua, when compiled with Norcroft and Objasm.
Now that I am using GCC the filetype is always
returned as zero, and I cannot see why.

OS_GPBP 12 uses a buffer to return its results,
with the object's name as a zero-terminated
string at buf+24, and the filetype in the word
at buf+20. I declare a buffer with

static const int rdir_buf[RDIR_BUFLEN/sizeof(int)];

After the call to OS_GPBP 12 my code grabs the
name and filetype with

lua_pushstring(L, (char *)(&rdir_buf[6])); /* name */
lua_pushinteger(L, rdir_buf[5]); /* file type */
return 2; /* number of returned values */

This stuff is what makes the construction

for name, ftype in dir (foo) do .... end

work - well it used to The 'name' part comes out OK, but the
'ftype' is always zero, and I just cannot see why.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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: Javascript date function

On Sun, Sep 20, 2015 at 21:52:05 +0100, Dave Higton wrote:
> Right, I've tracked this down... sort of.

Thanks for your investigation.

I wonder if this might be, in part, due to the horrors of the mess I made
of the time functions for our duktape binding.

If you're confident that it's a fault built into duktape then we can go to
duktape's authors, but before then, be aware that in order to be more
cross-platform, we do replace some of duktape's time functions with our own
which might be subtly different in their interpretations (thus causing the
issue).

If you continue to believe it to be duktape's problem then let me know and
I'll contact the upstream author (or you can yourself).

Again thank you for doing this investigatory work.

D.

--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69

New Netsurf - improved Javascript stability

I downloaded the latest CI build of NS yesterday. There hasn't been one
for quite a while. I noticed that it doesn't crash when opening a sport
page of the BBC News website, for example. This is a big improvement.

I think we're seeing evidence of big changes within Netsurf.

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Re: Javascript date function

In message <5eb0fefc54.DaveMeUK@my.inbox.com>
Dave Higton <dave@davehigton.me.uk> wrote:

>I don't know whether this is relevant at this stage.
>
>I've been putting together a few noddy Javascript examples. I noticed
>tonight that the date function shows the time zone as being +02:00 and
>shows the time as being 2 hours later than UTC. I'm wondering if it
>is adding DST to a time that already has DST. My Iyonix is completely
>set up for the UK. AFAIK it's the settings you'd expect anyone in the
>UK to have.
>
>NS #2953.

Right, I've tracked this down... sort of.

In duktape.c, function duk_bi_date_get_local_tzoffset_gmtime() is
called, but returns 7200.

The salient pints are:

gmtime_r(&t, &tms[0]);
localtime_r(&t, &tms[1]);

/* At ths point, tms[0].tm_hour is the UTC hour, tms[0].tm_isdst is 0;
tms[1].tm_hour is the local hour (1 greater than the UTC hout 'cos
we're currently in daylight savings), and tms[1].tm_isdst = 1.
I think those values are what one would expect. */

t1 = mktime(&tms[0]);
t2 = mktime(&tms[1]);

if (tms[1].tm_isdst > 0) {
t2 += 3600;
}

/* Now why on earth do they do that? t2 is a local time, and as such
is already corrected for DST - shouldn't it be? */

return (t2 - t1);

This is around lines 27864 to 27910 in duktape.c.

I'm not finding clear answers on the Internet as to whether localtime_r()
should return numbers that already directly represent the local legal
time, or the non-DST time in that time zone and expect the tm_isdst flag
to be used to add an hour offset.

Dave

____________________________________________________________
FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family!
Visit http://www.inbox.com/photosharing to find out more!

Re: [gccsdk] GCC 4.7.4 numbers

On 19/09/15 15:29, Gavin Wraith wrote:
> I am still not sure how one uses GCC to compile a dynamically
> loadable single elf file from several sources. When I tried a
> compilation of the form
>
> gcc -fPIC -Wl,-E ... -o output foo.s bar.c
>
> it compiled OK but when dynamically loaded it was clear
> that the references in bar.c to (.global) symbols in foo.s
> had not been resolved. So I went back to using the inline
> assembler - this time with some progress, as more of my test
> programs worked, though not all.

If you'd like to email me the two source files, I'll have a look
to see if I can spot anything that may cause runtime linking problems.

Lee.


_______________________________________________
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

[gccsdk] Announcement of GCC 4.7.4 release 2

I've just posted this announcement on riscos.info:

----

The RISC OS GCCSDK developers are pleased to announce the GNU Compiler
Collection version 4.7.4 RISC OS release 2, which is now available for
download.

The main feature of this GCC release is Vector Floating Point (VFP) support,
suitable for use on ARMv6 and ARMv7 platforms. This behaves similarly to VFP
on other GCC ARM platforms. See the documentation inside !GCC for more
details on how to build programs with VFP support.

Other changes include:
- Unixlib: Add support for __cxa_atexit (r6754,r6778,r6916).
- Unixlib: Add support for clang/llvm (r6755).
- Unixlib: When the size of an mmapped file is not a multiple of the page
- size, zero the remainder (r6772).
- Unixlib: Add VFP support (r6795,r6867).
- Unixlib: Add support for naming pthreads.
- Unixlib: select() fix; only report a file descriptor as bad if it was
- given in one of the sets (r6862).
- GCC: VFP fixes (r6869).
- GCC: Make -mno-unaligned-access the default (r6796).
- GCC: Fix handling of section anchors in module code (r6866,r6871).
- GCC: Fix potential stack frame corruption (r6897)
- Dynamic Linker: Fix handling of ':' in path variables (r6870).
- Dynamic Linker: Add VFP support (r6797).
- SharedUnixLib: VFP support (v1.13, r6795)
- SharedUnixLib: fix memory leak (v1.14, r6905)

The release can be downloaded from the riscos.info repositories using
!PackMan, which will fetch and install all the pieces for you, or you can
!follow the manual installation instructions here:
http://www.riscos.info/index.php/GCC

Our thanks go to all those who have contributed to this release.

Theo Markettos
on behalf of the GCCSDK developers

----

Archives are up on riscos.info, overnight they should get pushed into the
Raspberry Pi package list too.

If there's no last minute issues, I'll do announcements on csa.announce and
ROOL forum tomorrow.

Thanks everyone for your input :-)

Theo

_______________________________________________
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] GCC 4.7.4 numbers

On Sat, Sep 19, 2015 at 05:17:52PM +0200, John Tytgat wrote:
> On 09/19/2015 04:29 PM, Gavin Wraith wrote:
> >[...]
> >The Acorn C manual had a useful chapter "Implementation Details"
> >that assured me that ints and longs were 32-bit and so on.
> >Where do I find something similar for the RISC OS implementation
> >of 4.7.4? There is a dizzying range of possibilities for
> >what numbers are in Lua. New to Lua 5.3 is a distinction
> >(in the C code) between the types LUA_NUMBER and LUA_INTEGER
> >so I need to check out what GCC is producing.
>
> Probably the most interesting info is that int/long/wchar_t/wint_t
> are signed 32 bit, char is unsigned, long long/long double 8 bytes
> wide, short 2 bytes wide. AFAIK all in sync with Norcroft C
> implementation details.

If you have control over what types Lua is using (because there's a header
file with typedefs somewhere), and you're using C99 or later, I recommend
using stdint.h. This defines a series of types like uint32_t which do
exactly what they say on the tin, so there's no worries that another
compiler or another platform will do something different.

Theo

_______________________________________________
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] GCC 4.7.4 numbers

On 09/19/2015 04:29 PM, Gavin Wraith wrote:
> [...]
> The Acorn C manual had a useful chapter "Implementation Details"
> that assured me that ints and longs were 32-bit and so on.
> Where do I find something similar for the RISC OS implementation
> of 4.7.4? There is a dizzying range of possibilities for
> what numbers are in Lua. New to Lua 5.3 is a distinction
> (in the C code) between the types LUA_NUMBER and LUA_INTEGER
> so I need to check out what GCC is producing.

gcc defines a bunch of __* preprocessor defines which can be used by the
runtime library headers to define useful types. To reveal such
implementation details, I would use:

arm-unknown-riscos-gcc -dM -E -x c /dev/null | sort

This might work on RISC OS native compiler as well when you replace
"/dev/null | sort" by "null:$.foo or" specifying an empty c.foo file
instead.

Probably the most interesting info is that int/long/wchar_t/wint_t are
signed 32 bit, char is unsigned, long long/long double 8 bytes wide,
short 2 bytes wide. AFAIK all in sync with Norcroft C implementation
details.

> Does GCC look
> after coercions/restrictions integers to/from floats when
> the flag -mfpu=vfp is used, or do I have to code those myself?

Not 100% sure what details you're after here but -mfpu=vfp does not
matter when the compiler is doing int/float type conversions. It
follows C89 (or whatever standard you specify with -std=) standard. If
you do type conversions at runtime (say, ceil()) then it is a matter of
the runtime library (unless you feed it with constant data, then gcc can
optimize such calls). But then again -mfpu=vfp should not matter
(ignoring possible bugs).

Is this what you want to know ?

John.


_______________________________________________
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

[gccsdk] GCC 4.7.4 numbers

I am still not sure how one uses GCC to compile a dynamically
loadable single elf file from several sources. When I tried a
compilation of the form

gcc -fPIC -Wl,-E ... -o output foo.s bar.c

it compiled OK but when dynamically loaded it was clear
that the references in bar.c to (.global) symbols in foo.s
had not been resolved. So I went back to using the inline
assembler - this time with some progress, as more of my test
programs worked, though not all.

The Acorn C manual had a useful chapter "Implementation Details"
that assured me that ints and longs were 32-bit and so on.
Where do I find something similar for the RISC OS implementation
of 4.7.4? There is a dizzying range of possibilities for
what numbers are in Lua. New to Lua 5.3 is a distinction
(in the C code) between the types LUA_NUMBER and LUA_INTEGER
so I need to check out what GCC is producing. Does GCC look
after coercions/restrictions integers to/from floats when
the flag -mfpu=vfp is used, or do I have to code those myself?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] Data synchronization and SWIs

In message <55FC6759.9090809@aaug.net>
John Tytgat <John.Tytgat@aaug.net> wrote:


>This corrupts r0-r3, possibly r14 when this gets executed in SVC. You
>need to tell gcc this. Inline assembler does not follow the APCS-32 ABI
>calling conventions (which I think you seem to assume here).

I was. That probably explains a lot.

>Aside, it is very easy to get things subtly wrong with inline
>assembler. Even when it seems to be working and you got it wrong in the
>first place, one day it will bite you when changing optimization level,
>ask for global optimisation or doing simply a minor version upgrade.
>
>A much safer approach for SWI calling and with additional C type safety
>is to use OSLib (http://ro-oslib.sf.net/).

Thanks for this tip. Looking at the assembly listing of bits of the
elf output I soon realized that GCC was playing fast and loose
with my chosen register assignments - fine for optimizing compiled
C code, not so jolly for calling SWIs.

@Lee

> I think your operand numbering is a bit out:

I now realize that I had been totally misconstruing the ARM GCC
Inline Assembler Cookbook.

I started using the inline assembler because I did not know how to
setup GCC to compile a dynamically loadable file by statically
linking two files, one compiled from C source, the other from
assembly source. I had been assuming APCS-32 calling conventions.
So I think I will now revert to separate source files for C
and assembler. Where do I read up the calling conventions for
linking with GCC output?

Thanks again for the advice.
--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] Data synchronization and SWIs

On 09/18/2015 08:18 PM, Lee Noar wrote:
> [...]
>
> asm volatile(
> "stmfd sp!, {r4-r8,r12}" "\n\t"
> "orr r12,%[swinum],#0x20000 @ X-bit" "\n\t"
> "mov r8,%[r] @ register buffer" "\n\t"
> "ldmia r8,{r0-r7}" "\n\t"
> "swi 0x71 @ OS_CALLASWIR12" "\n\t"
> "stmvcia r8,{r0-r7}" "\n\t"
> "movvc r0,#0 @ 0 for success" "\n\t"
> "ldmfd sp!,{r4-r8,r12}" "\n\t"
> : [p] "=r" (p)
> : [L] "r" (L), [swinum] "r" (swinum), [r] "r" (r)
> : "memory" );

This corrupts r0-r3, possibly r14 when this gets executed in SVC. You
need to tell gcc this. Inline assembler does not follow the APCS-32 ABI
calling conventions (which I think you seem to assume here).

Aside, it is very easy to get things subtly wrong with inline
assembler. Even when it seems to be working and you got it wrong in the
first place, one day it will bite you when changing optimization level,
ask for global optimisation or doing simply a minor version upgrade.

A much safer approach for SWI calling and with additional C type safety
is to use OSLib (http://ro-oslib.sf.net/).

John.


_______________________________________________
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] Data synchronization and SWIs

On 18/09/15 15:07, Gavin Wraith wrote:
> Has anyone any advice about the use of data synchronization
> barriers when calling SWIs from C code compiled with GCC?
>
> To give RiscLua a command 'sys' analogous to BASIC's SYS
> command I use this code
>
> asm volatile(
> "stmfd sp!, {r4-r8,r12}" "\n\t"
> "orr r12,%1,#0x20000 @ X-bit" "\n\t"
> "mov r8,%2 @ register buffer" "\n\t"
> "ldmia r8,{r0-r7}" "\n\t"
> "swi 0x71 @ OS_CALLASWIR12" "\n\t"
> "stmvcia r8,{r0-r7}" "\n\t"
> "movvc r0,#0 @ 0 for success" "\n\t"
> "ldmfd sp!,{r4-r8,r12}" "\n\t"
> : "=r" (p)
> : "r" (L),"r" (swinum), "r" (r)
> : "memory" );
>
> entered with the SWI number in R1 and R2 pointing to a
> buffer from which to load registers R0-R7 before entry,
> and to which to save them on exit. I never thought much
> about data synchronization, and when I compiled with
> the Norcroft C compiler and Objasm it all worked fine
> without.
> Now I am using GCC and it does not seem to work.

I think your operand numbering is a bit out:

p is %0
L is %1
swinum is %2
r is %3

In the above, your swi number is coming from %1 'L' which is
probably a stack address.

It occurs to me that you might think that %1 is R1 and %2 is R2,
but that's not the case. These refer to the operands starting
with %0 (p) after the first colon, then %1 (L), and so on.
The compiler will substitute the correct registers that match
the operands.

You can name the operands rather than numbering them to
help eliminate numbering errors. The names between [] do not have
to be the same as the variable names in () although it
does help readability:

asm volatile(
"stmfd sp!, {r4-r8,r12}" "\n\t"
"orr r12,%[swinum],#0x20000 @ X-bit" "\n\t"
"mov r8,%[r] @ register buffer" "\n\t"
"ldmia r8,{r0-r7}" "\n\t"
"swi 0x71 @ OS_CALLASWIR12" "\n\t"
"stmvcia r8,{r0-r7}" "\n\t"
"movvc r0,#0 @ 0 for success" "\n\t"
"ldmfd sp!,{r4-r8,r12}" "\n\t"
: [p] "=r" (p)
: [L] "r" (L), [swinum] "r" (swinum), [r] "r" (r)
: "memory" );

(From memory and untested :-) )

I'm assuming here that 'r' is your register buffer.

As Theo says, you don't need any special synchronization
instructions.

Lee.


_______________________________________________
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] Data synchronization and SWIs

On Fri, Sep 18, 2015 at 05:29:38PM +0100, Gavin Wraith wrote:
> In message <20150918150505.GP22681@chiark.greenend.org.uk> you wrote:
>
>
> >In what way does it not seems to work?
>
> Well,
>
> local sys, $, dim in (require "riscos")
> local x, mesg = sys (16)
> print (x and "ok" or mesg)
>
> should not be returning "SWI &48F1C not known"!

Can you look at the output assembly and see if it looks sensible? And
supply the whole function you are compiling? I notice you don't save R14
there - I assume the wrapper emitted by GCC will do that, but it's worth
checking.

> Thanks for this info. I am going to try linking the riscos library
> statically to see if that makes a difference.

Theo
(copying the list again since Lee or others may have suggestions)

_______________________________________________
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] Data synchronization and SWIs

On Fri, Sep 18, 2015 at 03:07:43PM +0100, Gavin Wraith wrote:
> Has anyone any advice about the use of data synchronization
> barriers when calling SWIs from C code compiled with GCC?
>
> To give RiscLua a command 'sys' analogous to BASIC's SYS
> command I use this code
>
> asm volatile(
> "stmfd sp!, {r4-r8,r12}" "\n\t"
> "orr r12,%1,#0x20000 @ X-bit" "\n\t"
> "mov r8,%2 @ register buffer" "\n\t"
> "ldmia r8,{r0-r7}" "\n\t"
> "swi 0x71 @ OS_CALLASWIR12" "\n\t"
> "stmvcia r8,{r0-r7}" "\n\t"
> "movvc r0,#0 @ 0 for success" "\n\t"
> "ldmfd sp!,{r4-r8,r12}" "\n\t"
> : "=r" (p): "r" (L),"r" (swinum), "r" (r) : "memory" );
>
> entered with the SWI number in R1 and R2 pointing to a
> buffer from which to load registers R0-R7 before entry,
> and to which to save them on exit. I never thought much
> about data synchronization, and when I compiled with
> the Norcroft C compiler and Objasm it all worked fine
> without.
> Now I am using GCC and it does not seem to work.

In what way does it not seems to work?

I'm not familiar with the asm side of GCC, but in general I would have
expected that a DSB is not necessary here.

DSB will ensure all in-flight memory accesses are completed before
proceeding, and that any ongoing cache, branch predictor and TLB maintenance
operations are completed. This is most relevant because the ARM memory
model does not enforce ordering of memory operations except with explicit barriers
- the instruction scheduler will identify load/store dependencies, but
implicit dependencies (between cores, or via hardware eg address aliasing)
have to be handled with barriers.

The only relevant point here is that if you modify an instruction in memory,
you need to achieve that there isn't a stale copy in the I-cache. That is
acheived by an I-cache invalidate (of that line at least) and ISB. That's
what OS_SynchroniseCodeAreas is for.

In this case you're calling OS_CallASWI, so any synchronisation is a problem
for it, not for you. If you were assembling SWI instructions manually then
you would have to call OS_SynchroniseCodeAreas (or, less portably, do the
invalidate yourself).

https://en.wikipedia.org/wiki/Memory_ordering
(which is worth a read) indicates that GCC >=4.4.0 supports
__sync_sychronize to make it emit barriers. But that's almost certainly not
required here.

Theo

_______________________________________________
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

[gccsdk] Data synchronization and SWIs

Has anyone any advice about the use of data synchronization
barriers when calling SWIs from C code compiled with GCC?

To give RiscLua a command 'sys' analogous to BASIC's SYS
command I use this code

asm volatile(
"stmfd sp!, {r4-r8,r12}" "\n\t"
"orr r12,%1,#0x20000 @ X-bit" "\n\t"
"mov r8,%2 @ register buffer" "\n\t"
"ldmia r8,{r0-r7}" "\n\t"
"swi 0x71 @ OS_CALLASWIR12" "\n\t"
"stmvcia r8,{r0-r7}" "\n\t"
"movvc r0,#0 @ 0 for success" "\n\t"
"ldmfd sp!,{r4-r8,r12}" "\n\t"
: "=r" (p): "r" (L),"r" (swinum), "r" (r) : "memory" );

entered with the SWI number in R1 and R2 pointing to a
buffer from which to load registers R0-R7 before entry,
and to which to save them on exit. I never thought much
about data synchronization, and when I compiled with
the Norcroft C compiler and Objasm it all worked fine
without.
Now I am using GCC and it does not seem to work.

I tried inserting a DSB instruction before SWI &71, but GCC
complained that this instruction was not available in ARM mode.
But it is not clear to me whether it is needed, seeing that
the code has worked fine in the past. I have used
'asm volatile' to assemble the code, but I am not sure whether
this is sufficient to stop GCC from optimizing it.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] no main

On 15/09/15 11:27, Gavin Wraith wrote:
> In message <55F7E5F4.1000002@sky.com>
> Lee Noar <leenoar@sky.com> wrote:
>
>> Does the interpreter reference these two symbols directly rather than
>> via dlsym?
>>
>> Lee.
>
> No - absolutely not. Nor should dlsym.

Ok.

> When a pack of object files are linked I would expect that the internal references
> are resolved,

Yes.

> and any other references are taken to be external,

Yes.

> and hence to be put into a table in the resulting elf output for later resolution.

Yes, dynamic relocations.

> Is that how gcc is supposed to function?

That sounds about right.

> Or does gcc need extra information
> about which symbols are to be considered local and which global?

There are symbols tables that the compiler/assembler generates that aid
in static linking (ie, at build time). Some symbols may end up not being
visible at all if they're local to a single object file, eg, a static
global variable.

> In my mind's eye I have a picture of a labelled directed graph, the vertices being
> object files, the arrows being labelled by symbols, referenced in the source
> vertex and exported within the target vertex. Is that a sensible picture?
> Any symbol not referenced from within the graph has to be external, and
> anything that is has to be internal.

Erm, TBH, I'm finding that hard to picture :-)

> I think sys.s has only one symbol not referenced by riscoslib.c - I might as
> well delete it. No symbols in sys.s are referenced by anything outside sys.s
> except from riscoslib.c. In particular sys.s makes no references to
> anything in liblua or the C libraries. It imports nothing.
> Am I right in thinking that I can write assembler directly into C source
> with GCC? That might simplify these linkage problems.

Yes, GCC's inline assembly is quite comprehensive.

> There are very few lines of it - especially in relation to the trouble they
> seem to be causing ;). There is no other way of giving RiscLua access to
> RISC OS SWIs, of course. Using the Norcroft compiler I had to use Objasm
> but perhaps GCC offers more flexible alternatives?

You can also call SWIs in C using either _kernel_swi, eg:

#include <kernel.h>
#include <swi.h>

...

_kernel_swi_regs r;
_kernel_oserror *err;

r.r[0] = 10;
r.r[1] = (int)"ram:$.test";
r.r[2] = 0xfff; /* file type */
r.r[4] = (int)start_addr;
r.r[5] = (int)end_addr;
err = _kernel_swi(XOS_Bit | OS_File, &r, &r);

or using _swix, eg:

_swix(OS_File, _IN(0)|_IN(1)|_IN(2)|_IN(4)|_IN(5),
10, "ram:$.test", 0xfff, start_addr, end_addr);

Completely off the top of my head and untested of course. The
first is probably easier to read and understand than the
second. Both are error prone due to weak type checking, but
that can be improved by wrapping them up as a function.

Lee.


_______________________________________________
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] Dirty hacks

On 15/09/15 14:24, Gavin Wraith wrote:
> Those of a delicate disposition should avert their eyes from this
> post, because I am asking for the best, I hesitate to say official,
> way to do a dirty coercive hack with C code.
>
> BBC BASIC conflates addresses with integers. Alas, there is no way
> to communicate with RISC OS SWIs without doing this. I tried to do
> this in early versions of RiscLua, but eventually found it more
> practical to adopt the evil ways of BBC BASIC. Using the Norcroft
> C compiler and Objasm my method basically consisted of having
> a piece of assembler code
>
> AREA HACK
> EXPORT hack
>
> hack MOV PC, R14
> END
>
> with a header file containing
>
> extern void *hack(int n);
>
> You get the idea? It means wasting time with an extra call to an identity
> function. I have just been reading up on GCC's inline assembler
> and I find that its syntax has been designed to thwart this kind of
> cavalier behaviour with types. Obviously I should be using a macro to avoid
> unnecessary function calls. But what is the pukka way to do the hack?

Usually, you just use a cast:

int number;
void *number_is_now_a_pointer = (void *)number;

There are some good examples of inline assembler SWI veneers here:

<http://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Frecipe%2Ffiles%2Fgcc%2Flibunixlib%2Fincl-local%2Fsys%2Fsocket.h>

Lee.


_______________________________________________
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

[gccsdk] Dirty hacks

Those of a delicate disposition should avert their eyes from this
post, because I am asking for the best, I hesitate to say official,
way to do a dirty coercive hack with C code.

BBC BASIC conflates addresses with integers. Alas, there is no way
to communicate with RISC OS SWIs without doing this. I tried to do
this in early versions of RiscLua, but eventually found it more
practical to adopt the evil ways of BBC BASIC. Using the Norcroft
C compiler and Objasm my method basically consisted of having
a piece of assembler code

AREA HACK
EXPORT hack

hack MOV PC, R14
END

with a header file containing

extern void *hack(int n);

You get the idea? It means wasting time with an extra call to an identity
function. I have just been reading up on GCC's inline assembler
and I find that its syntax has been designed to thwart this kind of
cavalier behaviour with types. Obviously I should be using a macro to avoid
unnecessary function calls. But what is the pukka way to do the hack?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] no main

In message <55F7E5F4.1000002@sky.com>
Lee Noar <leenoar@sky.com> wrote:

>Does the interpreter reference these two symbols directly rather than
>via dlsym?
>
>Lee.

No - absolutely not. Nor should dlsym.

When a pack of object files are linked I would expect that the internal references
are resolved, and any other references are taken to be external, and hence
to be put into a table in the resulting elf output for later resolution.
Is that how gcc is supposed to function? Or does gcc need extra information
about which symbols are to be considered local and which global?
In my mind's eye I have a picture of a labelled directed graph, the vertices being
object files, the arrows being labelled by symbols, referenced in the source
vertex and exported within the target vertex. Is that a sensible picture?
Any symbol not referenced from within the graph has to be external, and
anything that is has to be internal.

I think sys.s has only one symbol not referenced by riscoslib.c - I might as
well delete it. No symbols in sys.s are referenced by anything outside sys.s
except from riscoslib.c. In particular sys.s makes no references to
anything in liblua or the C libraries. It imports nothing.
Am I right in thinking that I can write assembler directly into C source
with GCC? That might simplify these linkage problems.
There are very few lines of it - especially in relation to the trouble they
seem to be causing ;). There is no other way of giving RiscLua access to
RISC OS SWIs, of course. Using the Norcroft compiler I had to use Objasm
but perhaps GCC offers more flexible alternatives?

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] no main

On 15/09/15 10:13, Gavin Wraith wrote:
> Apologies - scrub my last post. I had forgot the shared flag, among other idiocies.
> With the command
>
> gcc -std=gnu99 -fPIC -O2 -Wall -Wextra -Wl,-E -shared -mfpu=vfp -DRISCOS -o so/riscos riscoslib.c sys.s
>
> the plugin file gets created OK. However when I run my test program the dynamic linker
> complains that it cannot resolve two symbols: 'rdir' and 'swi_call'.
> These are declared .global in the gas source sys.s. In fact they are the first
> in the lists of such declarations that appear in the source. There are 12
> such symbols declared and I am not sure whether the other 10 have been recognized
> or whether the linker has simply bailed out after two failures. The
> latter seems most likely.
> Evidently the command shown above is not resolving the references in riscoslib.o to sys.o.
> I need sys.o to be statically linked to riscoslib.o to create the plugin.

Does the interpreter reference these two symbols directly rather than
via dlsym?

Lee.


_______________________________________________
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] no main

Apologies - scrub my last post. I had forgot the shared flag, among other idiocies.
With the command

gcc -std=gnu99 -fPIC -O2 -Wall -Wextra -Wl,-E -shared -mfpu=vfp -DRISCOS -o so/riscos riscoslib.c sys.s

the plugin file gets created OK. However when I run my test program the dynamic linker
complains that it cannot resolve two symbols: 'rdir' and 'swi_call'.
These are declared .global in the gas source sys.s. In fact they are the first
in the lists of such declarations that appear in the source. There are 12
such symbols declared and I am not sure whether the other 10 have been recognized
or whether the linker has simply bailed out after two failures. The
latter seems most likely.
Evidently the command shown above is not resolving the references in riscoslib.o to sys.o.
I need sys.o to be statically linked to riscoslib.o to create the plugin.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] Undefined reference to main

On 15/09/15 09:38, Gavin Wraith wrote:
>> Looks like we're on the right track.
>
> Yes, the interpreter now compiles. For making my sample plugin "riscos"
> I am just using an Obeyfile with
>
> dir <Obey$dir>
> gcc -std=gnu99 -fPIC -O2 -Wall -Wextra -mfpu=vfp -DRISCOS -o so/riscos riscoslib.c sys.s -Wl,-E liblua

gcc -std=gnu99 -fPIC -O2 -Wall -Wextra -mfpu=vfp -DRISCOS -o so/riscos
riscoslib.c sys.s -shared

> but when I run it I get (apart from a warning about a possibly uninitialized variable in
> a switch statement - which is OK) the error
>
> .... In function `crt1_data':
> crt0.S:(.data+0x14): undefined reference to `main'
> collect2: error: ld returned 1 exit status
>
> I am evidently omitting some flag to say that it is supposed to be a plugin, without a
> main function. There is no 'main' in riscoslib.c or sys.s or in any of the sources
> that make liblua.

Option "-shared" is the one that tells GCC to create a shared library.

I've also removed liblua, as you want to use what's in the
interpreter rather than link another copy into the plugin.

The -Wl,-E exports the dynamic symbols from the interpreter and should
be included on the interpreter's link line rather than the plugin's.

Lee.



_______________________________________________
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

[gccsdk] Undefined reference to main

> Looks like we're on the right track.

Yes, the interpreter now compiles. For making my sample plugin "riscos"
I am just using an Obeyfile with

dir <Obey$dir>
gcc -std=gnu99 -fPIC -O2 -Wall -Wextra -mfpu=vfp -DRISCOS -o so/riscos riscoslib.c sys.s -Wl,-E liblua

but when I run it I get (apart from a warning about a possibly uninitialized variable in
a switch statement - which is OK) the error

.... In function `crt1_data':
crt0.S:(.data+0x14): undefined reference to `main'
collect2: error: ld returned 1 exit status

I am evidently omitting some flag to say that it is supposed to be a plugin, without a
main function. There is no 'main' in riscoslib.c or sys.s or in any of the sources
that make liblua.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] -rdynamic

On 14/09/15 19:59, Gavin Wraith wrote:
> gcc: error: unrecognized command line option '-rdynamic'

Serves me right for not trying it first :-/

Now that I look at the Lua source I see that they use -Wl,-E
which is the equivalent of -Wl,--export-dynamic which is what
-rdynamic would do if it were recognised.

Looks like we're on the right track.

Lee.


_______________________________________________
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

[gccsdk] -rdynamic

gcc: error: unrecognized command line option '-rdynamic'

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] gccsdk 4.7.4, firefox, and arora

On 12/09/15 11:31, John Ballance wrote:
> Similar issue in Qt and arora. Several mods needed.. not yet building
> here, but hopefully soon. I know its your 'baby', Lee, so don't want to
> tread on toes.

By all means, as Theo said, if you have any patches, please do post them
to the mail list.

Thanks,
Lee.


_______________________________________________
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] dlopen query

On 13/09/15 17:17, Gavin Wraith wrote:
>> That means that either you have compiled one or more C source files
>> without the -fPIC option or some hand written assembler (sys.s?)
>
> Yes. I then put in the -fPIC flag for compiling the library and tried
> again. This time I get errors of the kind
>
> can't resolve symbol 'lua_setmetatable'
>
> for each of the functions imported into the library.

Are these functions defined in the Lua runtime? Is the runtime a shared
library or is it in the executable (where main() is)?

If the plugin "libriscos.so" directly calls functions from a
LUA runtime shared library, then you should add "-l<runtime library
soname>" to the link line of "libriscos.so".
For example, if the runtime is called "libLuaRT.so", add "-lLuaRT".

If the plugin calls functions from the executable, then the executable
should be linked using the "-rdynamic" option. This tells the linker to
add all symbols to the dynamic symbol table, so that they are visible
to libraries loaded by dlopen.

> So should I be using -fPIC also when compiling the interpreter?
> What about -shared?

If the interpreter is the exectuable containing main(), then no, it
should not be built with -fPIC or -shared.

> The interpreter uses the convention that, after a library 'foo'
> has been loaded, the symbol (i.e. function name) to pass to
> dlopen is 'luaopen_foo'.

Do you mean dlsym here?

> This means that library names have
> to be valid identifiers in C, so I have rearranged things a bit
> so that dots and backslashes can be avoided. Now I have
> LUA_CPATH set to "/lua600:solib/?". The error messages I am now
> getting are evidently about linking, so the problems of filenaming
> appear to have been surmounted; for which many thanks.

We'll get there in the end :-)

Lee.


_______________________________________________
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] gccsdk 4.7.4, firefox, and arora

On 13/09/15 21:38, Theo Markettos wrote:
> On Sat, Sep 12, 2015 at 01:54:16PM +0100, Lee Noar wrote:
>> On 12/09/15 13:40, Theo Markettos wrote:
>>> I'm currently stalling 4.7.4rel2 on a C++ bug from Alan; but happy to integrate
>>> patches for the time being - if it gets complicated I'll simply branch
>>> 4.7.4rel2 and work on it there.
>>
>> Ah, the missing __cxa_atexit in SCL one, yes I should have a fix for
>> that soon.
>
> Thanks for that fix (r6916). Do you have any more fixes in flight?

No, I only snook in r6917 because I noticed build#38 fell over :-)

> Jenkins is currently building r6919 - if not we can take that build and call it
> official, subject to final testing.

Ok. I'll download the result of #40 and give it a try.

Lee.


_______________________________________________
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] gccsdk 4.7.4, firefox, and arora

On Sat, Sep 12, 2015 at 01:54:16PM +0100, Lee Noar wrote:
> On 12/09/15 13:40, Theo Markettos wrote:
> >I'm currently stalling 4.7.4rel2 on a C++ bug from Alan; but happy to integrate
> >patches for the time being - if it gets complicated I'll simply branch
> >4.7.4rel2 and work on it there.
>
> Ah, the missing __cxa_atexit in SCL one, yes I should have a fix for
> that soon.

Thanks for that fix (r6916). Do you have any more fixes in flight? Jenkins
is currently building r6919 - if not we can take that build and call it
official, subject to final testing.

Theo

_______________________________________________
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] dlopen query

> That means that either you have compiled one or more C source files
> without the -fPIC option or some hand written assembler (sys.s?)

Yes. I then put in the -fPIC flag for compiling the library and tried
again. This time I get errors of the kind

can't resolve symbol 'lua_setmetatable'

for each of the functions imported into the library.

So should I be using -fPIC also when compiling the interpreter?
What about -shared?

The interpreter uses the convention that, after a library 'foo'
has been loaded, the symbol (i.e. function name) to pass to
dlopen is 'luaopen_foo'. This means that library names have
to be valid identifiers in C, so I have rearranged things a bit
so that dots and backslashes can be avoided. Now I have
LUA_CPATH set to "/lua600:solib/?". The error messages I am now
getting are evidently about linking, so the problems of filenaming
appear to have been surmounted; for which many thanks.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

_______________________________________________
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] dlopen query

On 13/09/15 15:01, Gavin Wraith wrote:
>> In RISC OS, your libraries should be of the form:
>>
>> MyApp:lib.foo/so
>>
>> ie, a library file called "foo/so" in directory "lib" on path "MyApp".
>> You then pass it to dlopen as:
>>
>> /MyApp:lib/foo.so
>>
>> ie, in Unix style. The dynamic linker will then convert to the RISC OS
>> format when performing file operations.
>> I assume you're setting LUA_CPATH to "/MyApp:lib/" and then expecting
>> the dlfcn library to use that to build the correct filename.
>
> Yes.
>
>> If your libraries are named correctly as above, then that may work, but you
>> may have to tweak the dlfcn library to get the filenames correct.
>
> Some progress. I no longer get the 'file not found' error, but instead I get
> a message
> Text relocation of data symbol '' found:
> lua600:lib.riscos/so (offset 0x145C)

That means that either you have compiled one or more C source files
without the -fPIC option or some hand written assembler (sys.s?)
refers to global data without making it position independent.
If you need help with the latter, let me know.
If you load riscos/so into Zap/StrongEd and look at offset 0x145c in
code mode, you should be able to search back to the function that is
causing the problem.

> Not sure how to "tweak the dlfcn library". Would I not need access to its sources?
> The message is presumably from ld?

That's my misunderstanding. I thought you were referring to a library in
the LUA runtime rather the dynamic linker/libdl.

Lee.


_______________________________________________
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