[webkit-dev] LLInt alignment problem on ARM

2013-09-26 Thread Gabor Rapcsanyi

Hello!

I'm fighting with a strange LLInt alignment problem on ARM. As I see we 
put the LLInt code into .rodata section instead of .text.
Is there a specific reason why we are doing this? If there is not I 
would put them to the .text section.


Here is the objdump:

./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: 
file format elf32-littlearm


Disassembly of section .rodata:

 _ZStL19piecewise_construct:
   0:   andeq   r0, r0, r0

0004 _ZStL13allocator_arg:
   4:   andeq   r0, r0, r0

0008 _ZStL6ignore:
...

0009 llint_begin:
   9:   e30b3eefmovwr3, #48879  ; 0xbeef
   d:   e34b3badmovtr3, #48045  ; 0xbbad
  11:   e583str r0, [r3]
  15:   e3a0mov r0, #0
  19:   e12fff30blx r0

001d llint_program_prologue:
  1d:   e1a0200emov r2, lr
  21:   e5852010str r2, [r5, #16]
  25:   e5951008ldr r1, [r5, #8]
...


The problem is that these traditional instructions are lying on odd 
adresses in the .rodata section.


Regards,
  Gabor

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Changes in QtWebKit development

2013-09-26 Thread Andreas Kling
On Sep 25, 2013, at 12:40 PM, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Saturday 14 September 2013, Andreas Kling wrote:
 On Sep 14, 2013, at 11:24 AM, Allan Sandfeld Jensen k...@carewolf.com 
 wrote:
 That said, in all likelihood the Qt port will not remain part of WebKit
 forever, ...
 
 (This being the main reason.)
 
 Since you already know you’re eventually going to leave, you could just
 move to a branch sooner rather than later. It’s unreasonable to expect
 WebKit to accommodate a port that has no forward-looking interest in the
 project.
 
 We do have a  branch tagged and being prepared for 5.2. It was taken before 
 the FTL merge and the following switch to require C++11 in all of the 
 project. 
 It will be very hard branch again after that point since we support 2-3 year 
 old platforms by default, and the Webkit project want to move to using the 
 latest and greatest compilers.

So you are saying that you'll never branch QtWebKit from WebKit trunk again?

 We also were not expecting much accommodation. Our continued engagement 
 should 
 mainly be seen as a gesture, we want to slowly pull out our code and help 
 clean up after ourselves. We don't have as many resources as Google so we can 
 not do that in just a few days, and since I am the one going to do so, I 
 prefer to tie up some loose ends and land the patches for review that affect 
 all of WebKit instead of just dropping everything and leaving. 

Google did not clean up after themselves, see:

https://lists.webkit.org/pipermail/webkit-dev/2013-April/024388.html

Adam and Eric offered to do some of this cleanup, but I think it's healthier
for people who will continue to be a part of WebKit to decide what gets cleaned
up, and execute on the plan.”

I think this should be handled the same way.

 If you feel the Qt port is a burden and in the way of major refactorings you 
 want to do, we could set a more specific time schedule for the transition. On 
 the Digia side we are just naturally hesitant due to emotional attachment to 
 WebKit and bad experience from the Nokia days with dropping a project before 
 its replacement is ready ;)

It’s commendable that you want to land your platform-agnostic patches before
withdrawing from the project, but assuming your last branch point is already
set, I don’t see why this necessitates keeping the Qt platform code around.

Your emotional attachment is nothing but EWS bots and rebaselines to me.

-Andreas
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] LLInt alignment problem on ARM

2013-09-26 Thread Oliver Hunt
I believe that there’s a mnemonic that forces alignment that we could (arguably 
should?) be using before these labels.

IIRC it’s something like .align N — if we aren’t doing this already we could 
make the lint assembler backend emit a .align 16 prior to each global symbol.

—Oliver

On Sep 26, 2013, at 1:09 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote:

 Hello!
 
 I'm fighting with a strange LLInt alignment problem on ARM. As I see we put 
 the LLInt code into .rodata section instead of .text.
 Is there a specific reason why we are doing this? If there is not I would put 
 them to the .text section.
 
 Here is the objdump:
 
 ./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: file 
 format elf32-littlearm
 
 Disassembly of section .rodata:
 
  _ZStL19piecewise_construct:
   0:   andeq   r0, r0, r0
 
 0004 _ZStL13allocator_arg:
   4:   andeq   r0, r0, r0
 
 0008 _ZStL6ignore:
...
 
 0009 llint_begin:
   9:   e30b3eefmovwr3, #48879  ; 0xbeef
   d:   e34b3badmovtr3, #48045  ; 0xbbad
  11:   e583str r0, [r3]
  15:   e3a0mov r0, #0
  19:   e12fff30blx r0
 
 001d llint_program_prologue:
  1d:   e1a0200emov r2, lr
  21:   e5852010str r2, [r5, #16]
  25:   e5951008ldr r1, [r5, #8]
 ...
 
 
 The problem is that these traditional instructions are lying on odd adresses 
 in the .rodata section.
 
 Regards,
  Gabor
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] LLInt alignment problem on ARM

2013-09-26 Thread Michael Saboff
I’m wondering if the alignment is the traditional ARM vs Thumb 2.  The movw 
after lint_begin with hex  0xe30b3eef is a Thumb 2 instruction.

- Michael

On Sep 26, 2013, at 9:24 AM, Oliver Hunt oli...@apple.com wrote:

 I believe that there’s a mnemonic that forces alignment that we could 
 (arguably should?) be using before these labels.
 
 IIRC it’s something like .align N — if we aren’t doing this already we could 
 make the lint assembler backend emit a .align 16 prior to each global symbol.
 
 —Oliver
 
 On Sep 26, 2013, at 1:09 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu wrote:
 
 Hello!
 
 I'm fighting with a strange LLInt alignment problem on ARM. As I see we put 
 the LLInt code into .rodata section instead of .text.
 Is there a specific reason why we are doing this? If there is not I would 
 put them to the .text section.
 
 Here is the objdump:
 
 ./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: 
 file format elf32-littlearm
 
 Disassembly of section .rodata:
 
  _ZStL19piecewise_construct:
  0:   andeq   r0, r0, r0
 
 0004 _ZStL13allocator_arg:
  4:   andeq   r0, r0, r0
 
 0008 _ZStL6ignore:
   ...
 
 0009 llint_begin:
  9:   e30b3eefmovwr3, #48879  ; 0xbeef
  d:   e34b3badmovtr3, #48045  ; 0xbbad
 11:   e583str r0, [r3]
 15:   e3a0mov r0, #0
 19:   e12fff30blx r0
 
 001d llint_program_prologue:
 1d:   e1a0200emov r2, lr
 21:   e5852010str r2, [r5, #16]
 25:   e5951008ldr r1, [r5, #8]
 ...
 
 
 The problem is that these traditional instructions are lying on odd adresses 
 in the .rodata section.
 
 Regards,
 Gabor
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Proposal: remove style scoped

2013-09-26 Thread Benjamin Poulain

Dear WebKit,

We have an unmaintained implementation of the scoped style feature in 
the tree. 
(http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped)
It is getting in the way of improvements so I would like to remove it 
for now.


From what I have found online, only Firefox ships the feature and it is 
not popular.


Does anyone plan to finish the feature and ship it? If not, I will 
remove it soon-ish.

We can always add the feature later if it becomes useful.

Cheers,
Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Proposal: remove style scoped

2013-09-26 Thread Antti Koivisto
I think it is a feature that we may want to have sooner or later. We will
probably want to change the implementation quite a bit though and removing
the dead code for now makes sense.


   antti


On Thu, Sep 26, 2013 at 3:42 PM, Benjamin Poulain benja...@webkit.orgwrote:

 Dear WebKit,

 We have an unmaintained implementation of the scoped style feature in
 the tree. (http://www.whatwg.org/specs/**web-apps/current-work/**
 multipage/semantics.html#attr-**style-scopedhttp://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped
 )
 It is getting in the way of improvements so I would like to remove it for
 now.

 From what I have found online, only Firefox ships the feature and it is
 not popular.

 Does anyone plan to finish the feature and ship it? If not, I will remove
 it soon-ish.
 We can always add the feature later if it becomes useful.

 Cheers,
 Benjamin
 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/**mailman/listinfo/webkit-devhttps://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev