On 2014/03/12 19:19:52, rmcilroy wrote:
On 2014/03/12 18:59:25, Alexandre Rames wrote:
> On 2014/03/12 18:40:13, Alexandre Rames wrote:
> > Fixes the specific test. Running sanity checks...
>
> More details: fixes tools/run-tests.py --arch-and-mode=a64.debug
> mozilla/ecma/Date/15.9.5.23-11
>
> Other tests look ok
> $ make a64.optdebug.check -j15
> [15:12|% 100|+ 12123|- 0]: Done
>
> The check was failing because the branch over the pool can generate a
reloc_info
> for the code position.
> Can you confirm that the reloc_info_writer does not need to record the
reloc
'in
> order'? The check assumed it could not, but I actually see no reason it
cannot.
> And the veneer code does not care about it. (We take the offset - not
the
> address - of the position we are interested in, so even if the buffer
grows
> before the RecordRelocInfo we are fine)
There is a comment in serializer.cc:1765 which says:
// This assert will fail if the reloc info gives us the
target_address_address
// locations in a non-ascending order. Luckily that doesn't happen.
(Note: target_address_address returns the address of the constant pool
entry).
Would this change cause this assertion to fail?
I am not very familiar with the serializer code, but I think this is ok.
I think the Serializer does not need to visit the constant or veneer pool
declaration RelocInfos (RelocInfo::Visit agrees), so we never reach
OutputRawData with the address for a veneer pool RelocInfo.
I just ran the mozilla tests in optdebug mode and they are ok.
However I think this is worth a comment in RecordVeneerPool.
https://codereview.chromium.org/196413007/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
