Ticket #1663 (closed bug: fixed)

Opened 5 years ago

Last modified 4 years ago

Mixture of dyn opcodes

Reported by: fperrad Owned by: plobsing
Priority: critical Milestone:
Component: core Version: 2.4.0
Severity: high Keywords:
Cc: Language:
Patch status: new Platform:

Description

Since the merge of ops_massacre, all scripts setup.pir end without doing there job.

Here a minimalist example

.sub 'main' :main
    .param pmc args
    $S0 = shift args
    load_bytecode 'distutils.pbc'

    $P0 = new 'Hash'
    $P1 = new 'Hash'
    $P1['runtime/parrot/library/osutils.pbc'] = 'runtime/parrot/library/osutils.pir'
    $P0['pbc_pir'] = $P1

    .tailcall setup(args :flat, $P0 :flat :named)
.end

Here, the trailer of trace mode

044c find_sub_not_null P3, "newer"                                        P3=PMCNULL 
044f invokecc P3                                        P3=MultiSub=PMC(0xa292d8)
0092 get_params PC28 (2), S0, S1                                        PC28=FixedIntegerArray=PMC(0xa29218) S0="" S1=""
0096 localtime S0, I0                                        S0="runtime/parrot/libra" I0=0
0099 end
FileHandle objects (like stdout and stderr)are about to be closed, so clearing trace flags.

The opcodes 'localtime' & 'end' are called. But the code of this function is (in runtime/parrot/library/osutils.pir):

.sub 'newer' :multi(string, string)
    .param string target
    .param string depend
    $I0 = stat target, .STAT_EXISTS
    unless $I0 goto L1
    $I0 = stat target, .STAT_FILESIZE
    unless $I0 goto L1
    goto L2
  L1:
    .return (0)
  L2:
    $I1 = stat target, .STAT_MODIFYTIME
    $I2 = stat depend, .STAT_MODIFYTIME
    $I0 = $I1 > $I2
    .return ($I0)
.end

localtime & stat are now dynamic opcode in 2 different shared libraries (sys_ops & io_ops).

Attachments

tt1663-more-workarounds.patch Download (0.7 KB) - added by doughera 4 years ago.

Change History

Changed 5 years ago by plobsing

  • owner set to plobsing

stat is also available on the OS dynpmc. Using that should workaround this issue untill it is resolved.

Changed 4 years ago by NotFound

Here is a short example of the dynop loading problem:

dynopl.pir:

.loadlib 'io_ops'

.sub something
  $P0 = open 'dynopl.pir', 'r'
  $S0 = read $P0, 64
  printerr $S0
  printerr "\n"
.end

dynopmain.pir:

#.loadlib 'math_ops'

.sub main
  load_bytecode 'dynopl.pbc'
  something()
.end

Compile dynopl.pir to pbc and run dynopmain. It works. Now uncomment the .loadlib of dynopmain and run again: bizarre things happen.

Changed 4 years ago by doughera

Changed 4 years ago by doughera

  • patch set to new

The workaround in r47106 introduces a dependency on io_ops.so which is missing in the Makefile. The attached patch "tt1663-more-workarounds.patch" adds in those dependencies.

Changed 4 years ago by chromatic

Thanks, committed in r47566.

Changed 4 years ago by plobsing

  • status changed from new to closed
  • resolution set to fixed

This issue is resolved by the dynop_mapping branch which has been merged as of r48412.

Note: See TracTickets for help on using tickets.