On 06/13/2016 03:28 PM, Peter Maydell wrote:
On 13 June 2016 at 23:21, Richard Henderson <r...@twiddle.net> wrote:
On 06/13/2016 03:04 PM, Peter Maydell wrote:
+ .global safe_syscall_base
+ .global safe_syscall_start
+ .global safe_syscall_end
+ .type safe_syscall_base, #function
+ .type safe_syscall_start, #function
+ .type safe_syscall_end, #function
_start and _end aren't function entry points, so is it OK
to mark them as functions?
Yes. Indeed, if you don't, the objdump will think these are data symbols
and fail to disassemble the instructions that follow.
I was told this was an objdump bug... it certainly
seems like an objdump bug to me, because this works
on the other architectures.
https://bugs.linaro.org/show_bug.cgi?id=815
This may be a hold-over from arm32, which as you recall has a rather
complicated scheme for annotating data vs instructions.
I took glibc as definitive, since that's code that definitely works.
If we never use the 7th syscall argument (and we can't,
since it doesn't exist on some hosts), then it's
unnecessary work, though I guess coming back to fix
all these host functions later might be tedious.
You're probably right about the 7th syscall argument on a 64-bit host.
glibc's syscall() takes the system parameter as an int and
does a sign-extending move into x0 with an uxtw.
safe_syscall() takes a long, so it's already 64 bits.
Well, uxtw is a zero-extending move. So...
r~
