Expression evaluation which takes the non IRInterpreter::Interpret path fails on i386-*-freebsd. Following changes are done to enable it.
- Enable i386 ABI creation for freebsd
- Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap syscall
- Unlike linux, the last argument of mmap is actually 64-bit(off_t). This requires us to push an additional word for the higher order bits.
- Prior to this change, ktrace dump will show mmap failures due to invalid argument coming from the 6th mmap argument.
Prior Fix:
(lldb) expression printf("%d", d1)
error: Can't run the expression locally: Interpreter doesn't handle one of the expression's opcodes
(lldb) expression d1 + 5 << IRInterpreter path
(int) $0 = 10
(lldb) expression d1 + 5.0
error: Can't run the expression locally: Interpreter doesn't handle one of the expression's opcodes
(lldb) expression f1 * 5
error: Can't run the expression locally: Interpreter doesn't handle one of the expression's opcodes
(lldb) expression f1 / 5
error: Can't run the expression locally: Interpreter doesn't handle one of the expression's opcodes
With Fix:
(lldb) expression printf("%d", d1)
(int) $0 = 1
(lldb) expression printf("%2.3f", f1)
(int) $2 = 5
(lldb) expression d1 + 5
(int) $3 = 10
(lldb) expression d1 + 5.0
(double) $4 = 10
(lldb) expression f1 * 5
(float) $7 = 25.5
(lldb) expression f1 / 5
(float) $8 = 1.01999998
It would be great if we could avoid OS-specific code in this file. That's what we have tried to do with the Platform::ConvertMmapFlagsToPlatform call (line 82), but it looks like it may not have been the right abstraction.
How about we replace the ConvertMmapFlagsToPlatform function (it's only used in this place) with a more generic GetMmapArguments call (returning a vector of args)? It can still do the MAP_ANON dance as before, but in the freebsd case it will do this additional append.
What do you think?