search

sifive / cinco

Port of Arduino environment for Freedom E 300 Dev Kit & HiFive Board
31 stars 21 forks source link

Use custom malloc implementation #9

Closed a0u closed 7 years ago

a0u commented 7 years ago

This replaces newlib's malloc() with the simplified implementation in the freedom-e-sdk.

Unfortunately, as far as I know, Arduino's build system is too restrictive to support the reuse of the libwrap make-based flow from the SDK, so symlinks will have to do.

mwachs5 commented 7 years ago

You mean because we can't include the code from other directories? Or because we can't add the necessary ld flags?

If it is the former, I'm fine with simlinking to directories in freedom-e-sdk

mwachs5 commented 7 years ago

Oh, I see you already are using the simlinks. Great. Is there any reason not to simlink all of them? I do see all of them showing up in the ELF files, even if we aren't calling them in our current tests

mwachs5 commented 7 years ago

Should we also simlink to the start.S and entry.S in freedom-e-sdk now?

a0u commented 7 years ago

Oh, I see you already are using the simlinks. Great. Is there any reason not to simlink all of them? I do see all of them showing up in the ELF files, even if we aren't calling them in our current tests

What do you mean by "all of them showing up"? If newlib uses any "syscalls" from libgloss, all of the functions become statically linked. They all reside in the same monolithic object file, so ld cannot selectively discard those that are unused. The ones we replace will have the __wrap prefix in the symbols, otherwise you are seeing the default implementations from newlib and libgloss.

Besides malloc(), only read() and write() are remotely interesting to symlink. The rest are unimplemented stubs that always return an error.

a0u commented 7 years ago

Anyway, there isn't any harm to symlinking the rest. It negligibly increases build time but shouldn't increase the static code size, and will probably reduce it by replacing libgloss because Arduino creates a static library (core.a ) to give the linker freedom to eliminate dead code.

mwachs5 commented 7 years ago

Yes, that's what I meant... I would like to avoid some other example code doing some weird behavior because it's doing ecall unexpectedly. Though I guess returning an error is potentially just as confusing.

On Wed, Dec 14, 2016 at 4:52 PM, Albert Ou notifications@github.com wrote:

Anyway. there isn't any harm to symlinking the rest. It negligibly increases build time but shouldn't increase the static code size, and will probably reduce it because Arduino creates a static library (core.a ) to give the linker freedom to eliminate dead code.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/sifive/cinco/pull/9#issuecomment-267203932, or mute the thread https://github.com/notifications/unsubscribe-auth/ARCAJK6PokkCiBtS_tXwUMURiYRDiphZks5rII8-gaJpZM4LNh53 .

-- Megan A. Wachs Engineer | SiFive, Inc 300 Brannan St, Suite 403 San Francisco, CA 94107 megan@sifive.com

a0u commented 7 years ago

Yes, that's what I meant... I would like to avoid some other example code doing some weird behavior because it's doing ecall unexpectedly. Though I guess returning an error is potentially just as confusing.

At least an error would still allow for the possibility of recovery, although I'm not sure if the Arduino code can cope with it anyway. I'm fine with symlinking everything - the downside would be further cluttering the cores/arduino directory. I have yet to figure out a way to introduce subdirectories and have the Arduino build system automatically detect the files.

Should we also simlink to the start.S and entry.S in freedom-e-sdk now?

Yes, good call.