Use asm_syscall (..., SYS_close) for close () on Epiphany.

[alexrp]

As documented in Adapteva's architecture reference manual.

[jeremybennett]

Hi alexrp,

Can you point me at the part of the Architecture reference manual where this is documented. I have version 3.12.12.18 and I can't find the call you describe.

Thanks,

Jeremy

[alexrp]

If you go to the documentation for TRAP, there is a table listing the system calls. close has system call number 3 there.

[jeremybennett]

Hi alexrp,

Thanks - I've found it. I don't know why the reserved TRAP 6 is used for closing a file in asm_close, rather than TRAP 7 and the file close system call. I'll make some inquiries to see if there is something extra we need to know.

Jeremy

[alexrp]

If I had to guess, I'd say it's just an artifact of the old system call style where the trap code indicated the system call.

[jeremybennett]

Hi alexp,

With Andreas help, we have dug out the old discussion about this. It dates back about 2 years, to when we were finalizing the interfaces. The current implementation uses the old trap architecture, which could now be implemented as syscalls.

Except...

The syscalls and traps are intercepted by GDB, so they can be supported using the host file system (this is standard practice). So changing from trap 6 to trap 7 may break stuff.

I'm currently working on improvements to GDB and e-server, and when those are finished (aiming for February), we should look at bringing consistency to use of syscalls as you propose in this patch.

One thing you could help with is extending the epiphany specific GDB regression tests, or even adding some libgloss tests. That way when we change the calls, we can ensure that nothing breaks.

Thanks for the submissions. Please keep up the good work.

Jeremy

[alexrp]

I'm not sure about GDB, but the syscall is handled in the official simulator: https://github.com/adapteva/epiphany-gdb/blob/epiphany-gdb-7_4/sim/epiphany/epiphany.c#L296

Where would the relevant code in GDB be?

[jeremybennett]

Hi alexrp,

It's in gdb/remote-fileio.c.

I've done a quick bit of digging, but I can't see where the syscall numbers are mapped to the host syscall numbers. I'm not sure if those syscall numbers are mapped for close etc.

Something to be looked at in the future. As I've noted, a set of regression tests to ensure that syscalls correctly map, whether simulated or with a real target would be really useful.

[alexrp]

It's in gdb/remote-fileio.c.

I can't seem to spot any Epiphany-specific stuff there.

I've done a quick bit of digging, but I can't see where the syscall numbers are mapped to the host syscall numbers. I'm not sure if those syscall numbers are mapped for close etc.

As far as the simulator is concerned, sim/common/nltvals.def (grep for epiphany).

[jeremybennett]

It is not Epiphany-specific, but somehow it needs to know about the syscall number mapping, in the same way that the simulator does from nltvals.def. I'll add it to the list of things to be checked for GDB.

[alexrp]

FWIW I just spent some time digging through GDB and the only files relating to syscall numbers I could find are those in gdb/syscalls which appear to only be relevant on hosted Linux environments.

[alexrp]

Just noticed today that still PR is still open - I'd completely forgotten about it. Have there been any developments in this area? Is this PR still wanted?

(Edit: Not sure how that unassign happened, btw. I didn't touch the assignee settings...)

[jeremybennett]

Hi alexrp. Not sure how actively Epiphany tool chain is being maintained. We haven't worked on it for several years.