NetSurf on ARMv7 platforms
by John-Mark Bell
Afternoon,
So, NetSurf runs mostly ok on ARMv7 platforms with their backwards
incompatible unaligned LDR behaviour turned on. Tinct, however, appears
to perform some LDRs from unaligned addresses, resulting in crashes.
Here's a backtrace:
> Fatal signal received: Segmentation fault
>
> Stack backtrace:
>
> Running thread 0x59e53c
> ( 5a7ee0) pc: 462860 lr: 74f4c sp: 5a7ee4 __write_backtrace()
> ( 5a7f10) pc: 74d64 lr: 463298 sp: 5a7f14 ^ro_gui_signal()
> ( 5a7f38) pc: 463288 lr: 462f58 sp: 5a7f3c __unixlib_exec_sig()
> ( 5a7fa0) pc: 462a18 lr: 463870 sp: 5a7fa4 __unixlib_raise_signal()
> ( 5a7fb0) pc: 463774 lr: 5a6c48 sp: 5a6c04 __h_cback()
>
> Register dump at 005a7fb4:
>
> a1: 12f a2: 2d a3: 1f4 a4: 0
> v1: 0 v2: 0 v3: 202513b4 v4: 1
> v5: 3d5 v6: 0 sl: 41b78d39 fp: 67197124
> ip: 20248394 sp: 5a6c04 lr: 5a6c48 pc: 2024609c
> cpsr: 80000113
>
> 20246088 : .p.â : e21a7003 : ANDS R7,R10,#3
> 2024608c : .... : 0a000008 : BEQ &202460B4
> 20246090 : .àgâ : e267e003 : RSB R14,R7,#3
> 20246094 : ..^á : e15e0000 : CMP R14,R0
> 20246098 : .à Á : c1a0e000 : MOVGT R14,R0
> 2024609c : .??å : e59a9000 : LDR R9,[R10,#0]
> 202460a0 : ..@Ð : d040000e : SUBLE R0,R0,R14
> 202460a4 : ..?Ò : d2800003 : ADDLE R0,R0,#3
> 202460a8 : ..?À : c0800007 : ADDGT R0,R0,R7
>
> Invalid pc address bebeec
For reference, Tinct is loaded at 202416B4.
J.
12 years, 10 months
Re: r9034 MarkieB - in /branches/MarkieB/gtkmain: content/fetchcache.c desktop/save_complete.c
by John-Mark Bell
On Tue, 2009-08-04 at 06:32 +0000, netsurf(a)semichrome.net wrote:
> Modified: branches/MarkieB/gtkmain/content/fetchcache.c
> URL: http://source.netsurf-browser.org/branches/MarkieB/gtkmain/content/fetchc...
> ==============================================================================
> --- branches/MarkieB/gtkmain/content/fetchcache.c (original)
> +++ branches/MarkieB/gtkmain/content/fetchcache.c Tue Aug 4 01:32:27 2009
> @@ -506,6 +506,7 @@
> msg_data);
> } else {
> content_reset(c);
> + printf("fetchcache_callback\n");
> fetchcache_error_page(c, data);
> }
> break;
This change looks spurious. Please revert it.
> Modified: branches/MarkieB/gtkmain/desktop/save_complete.c
> URL: http://source.netsurf-browser.org/branches/MarkieB/gtkmain/desktop/save_c...
> ==============================================================================
> --- branches/MarkieB/gtkmain/desktop/save_complete.c (original)
> +++ branches/MarkieB/gtkmain/desktop/save_complete.c Tue Aug 4 01:32:27 2009
> @@ -709,22 +721,27 @@
> * Create the inventory file listing original URLs.
> */
>
> -bool save_complete_inventory(const char *path)
> -{
> - char spath[256];
> +bool save_complete_inventory(const char *path,
> + struct save_complete_entry *list)
> +{
> + char urlpath[256];
> FILE *fp;
> - char *pathstring;
> -
> - pathstring = strdup("%s/Inventory");
> - if (!pathstring) {
> + char *urlstring, *pathstring;
> +
> + urlstring = strdup("file://%s/Inventory");
> + if (urlstring == NULL) {
> warn_user("NoMemory", 0);
> return false;
> }
> - pathstring[2] = pathsep;
> - snprintf(spath, sizeof spath, pathstring, path);
> + snprintf(urlpath, sizeof urlpath, urlstring, path);
> + free(urlstring);
This seems overly complex. This is better:
snprintf(urlpath, sizeof urlpath, "file://%s/Inventory", path);
Are you certain that path always begins with a '/'?
J.
13 years, 7 months
Assistance with the RISC OS front end
by Christopher Martin
Dear NetSurf Developers,
I am responding to a message posted to csa.announce on August 9, which
may give you a fair indication of how much time I have to keep up with
developments online. :-(
However, I have been keeping up quite regularly with the NetSurf builds
via SVN. I have made changes to the RISC OS GUI code that I have never
tried to submit. These changes keep rolling over from one SVN update to
the next. For example, I prevent NetSurf from passing left/right
keypresses on because moving the cursor in (say) the address bar would
cause PCITV to change channels. Small stuff, but it does indicate that I
am quite familiar with C and the WIMP. My primary shortcoming as an
assistant would be in the amount of time I can commit.
So just how much work do you estimate will be required to align the WIMP
development with the core? And do you already have plenty of offers from
others with much time to spare?
--
Regards, Christopher Martin.
13 years, 7 months
css/dump.c
by Gavin Wraith
I refetched the sources and !NSTools today, but compilation stops
with
css/dump.c: In function `nscss_dump_computed_style':
css/dump.c:1475: error: `CSS_TEXT_ALIGN_LIBCSS_LEFT' undeclared (first use in this function)
css/dump.c:1475: error: (Each undeclared identifier is reported only once
css/dump.c:1475: error: for each function it appears in.)
css/dump.c:1478: error: `CSS_TEXT_ALIGN_LIBCSS_CENTER' undeclared (first use in this function)
css/dump.c:1481: error: `CSS_TEXT_ALIGN_LIBCSS_RIGHT' undeclared (first use in this function)
make: *** [build-riscos-riscos/css_dump.o] Error 1
Has something been left out?
--
Gavin Wraith (gavin(a)wra1th.plus.com)
Home page: http://www.wra1th.plus.com/
13 years, 7 months
Re: Assistance with the RISC OS front end
by WP Blatchley
Hi Christopher,
Well, I'm not a Netsurf developer (yet!) but I just wanted to say it's great that you're thinking of helping out with the RISC OS side of it. Myself and Steve Fryatt have both also expressed an interested on this list, so that's three of us now!
I think I come bottom of the pile in terms of up-to-date experience with C and experience programming for RISC OS, but nevertheless I've now managed to get myself set up so I can keep my source tree up to date with SVN and compile at will. Now I'm beginning to look through the RISC OS side of the source code and trying to get a general feel for how things work. It's going to be a long haul though, I think!
It sounds like you've definitely got a head start in that respect, given that you've already made some mods to Netsurf, so that's great. JMB gave quite a lot of detail about what the current state of play is on this list a week or so back (digest volume 39, issue 16) - don't know if you spotted that or not?
Anyway, it's not my place to welcome you on board, as I'm barely on board myself, but I'm going to anyway!
Cheers,
WPB
----- Original Message ----
From: "netsurf-dev-request(a)netsurf-browser.org" <netsurf-dev-request(a)netsurf-browser.org>
To: netsurf-dev(a)netsurf-browser.org
Sent: Sunday, August 23, 2009 1:00:15 PM
Subject: netsurf-dev Digest, Vol 39, Issue 39
Send netsurf-dev mailing list submissions to
netsurf-dev(a)netsurf-browser.org
To subscribe or unsubscribe via the World Wide Web, visit
http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-dev-netsurf...
or, via email, send a message with subject or body 'help' to
netsurf-dev-request(a)netsurf-browser.org
You can reach the person managing the list at
netsurf-dev-owner(a)netsurf-browser.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of netsurf-dev digest..."
Today's Topics:
1. Assistance with the RISC OS front end (Christopher Martin)
2. Re: r9405 jmb - in /trunk/libcss: include/libcss/properties.h
src/select/properties.c (Chris Young)
3. Re: r9405 jmb - in /trunk/libcss: include/libcss/properties.h
src/select/properties.c (John-Mark Bell)
4. Re: r9405 jmb - in /trunk/libcss: include/libcss/properties.h
src/select/properties.c (Chris Young)
----------------------------------------------------------------------
Message: 1
Date: Sat, 22 Aug 2009 18:05:11 +0930
From: Christopher Martin <belles(a)internode.on.net>
Subject: Assistance with the RISC OS front end
To: netsurf-dev(a)netsurf-browser.org
Message-ID: <9e48b98e50.belles(a)ivy.at.home>
Content-Type: text/plain; charset="us-ascii"
Dear NetSurf Developers,
I am responding to a message posted to csa.announce on August 9, which
may give you a fair indication of how much time I have to keep up with
developments online. :-(
However, I have been keeping up quite regularly with the NetSurf builds
via SVN. I have made changes to the RISC OS GUI code that I have never
tried to submit. These changes keep rolling over from one SVN update to
the next. For example, I prevent NetSurf from passing left/right
keypresses on because moving the cursor in (say) the address bar would
cause PCITV to change channels. Small stuff, but it does indicate that I
am quite familiar with C and the WIMP. My primary shortcoming as an
assistant would be in the amount of time I can commit.
So just how much work do you estimate will be required to align the WIMP
development with the core? And do you already have plenty of offers from
others with much time to spare?
--
Regards, Christopher Martin.
13 years, 7 months
Re: Porting to an embedded device
by John-Mark Bell
Please ensure that you CC the mailing list.
On Thu, 2009-08-20 at 10:21 +0000, JULIAN GARDNER wrote:
> iConv from the iConv website
Right.
> I have no window system, was going to build that on the fly, I have a
> 2d graphics library with all the normal stuff and i have also
> freetype2 running.
In which case, the framebuffer frontend is probably what you want
(initially, at least).
> OS is uCos which is only available for use in non-commercial apps
Ok. I've no experience of this OS. Perhaps someone else has?
> Resolving the headers is the main problem with the amount of different
> libraries involved, and as my system has no linux, windows or anything
> else, just getting things to configure is a real pain.
There's not a great deal we can do to help with building the 3rd-party
libraries that NetSurf depends on. Some of them do provide standalone
makefiles, however. For those that don't, I suspect you're going to have
to manually divorce them from autoconf. This usually involves writing a
makefile and manually producing a suitable config.h
> Maybe i will take a look at the riscos version and maybe do a HAL to
> the riscos libraries,
I strongly recommend against this. RISC OS has a somewhat weird stack
implementation that isn't supported by the RealView tools. There's
probably other oddities that I've forgotten about, too.
> unless someone can build an ARM11 version of the code as a library and
> i can see about linking this into my build system and see what would
> be needed to get it linking and running.
I'm not sure about the intricacies of binary compatibility between
libraries built with GCC and RealView.
J.
13 years, 7 months
Re: Porting to an embedded device
by John-Mark Bell
Please ensure that you CC the mailing list.
On Thu, 2009-08-20 at 06:43 +0000, JULIAN GARDNER wrote:
> On Thu, 20/8/09, John-Mark Bell <jmb(a)netsurf-browser.org> wrote:
>
> > It would help if you told us what toolchain you intend to use.
>
> Thanks for the positive replies. Compiler will be RealView Development
> Suite 4.0, and its not goiing into a mobile phone!!!
Well, that should work fine.
> The problems are in building, i use JAM for my build system and has
> started adding in the libraries but becuase we dont use ./configure or
> autoconfig etc
NetSurf does not use autoconf at all, nor do any of the libraries that
we wrote. 3rd party dependencies probably do use some form of
configuration system, as that's usually the way that such things are
done.
Is there any reason why you need to integrate NetSurf into your build
system?
What OS/Windowing system are you targetting?
> Ive got a few libraires building, but last night iconv stopped the
> port in its tracks.
I hope this isn't the iconv in NetSurf's SVN repository -- that is for
RISC OS only.
> Resolving most of the header problems is easy in JAM but it when a
> library needs to be configured first
Can you describe these header problems? I'm not entirely sure what they
might be.
J.
13 years, 7 months
Re: r9285 MarkieB - in /branches/MarkieB/gtkmain: desktop/search.c desktop/search.h gtk/gtk_scaffolding.c gtk/gtk_search.c gtk/gtk_search.h gtk/gtk_tabs.c
by John-Mark Bell
On Wed, 2009-08-19 at 12:18 +0200, Mark wrote:
> John-Mark Bell wrote:
> > All of these callbacks should take a void * for the client context.
> >
> then I'll give them a void * :-)
search_step and search_create_context will need to be modified to take
the client context pointer to pass back to the callbacks, too.
> > +void search_step(struct browser_window *bw, search_flags_t flags,
> > + const char * string, struct search_callbacks *callbacks);
> >
> >
> > Why does this need a pointer to the callbacks? Surely it's stored in the
> > relevant search context?
> >
> for a very similar reason to the reason that we send a browser_window
> rather than a search_context; the search_context could be NULL [the
> sign that the search is a new search], so the function needs the
> necessary references in case we're creating a new search_context
Right. Can you remind me why it's this way, rather than the frontend
creating/destroying the search context as appropriate?
J.
13 years, 7 months
