Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

renaming symbols #950

Open
yamt opened this issue Mar 2, 2024 · 5 comments
Open

renaming symbols #950

yamt opened this issue Mar 2, 2024 · 5 comments

Comments

@yamt
Copy link
Contributor

yamt commented Mar 2, 2024

sometimes a user wants to have multiple copies of littlefs in a binary.

eg.
nuttx embeds littlefs for its filesystem: https://github.com/apache/nuttx/tree/master/fs/littlefs
toywasm also can embed littlefs: https://github.com/yamt/toywasm/blob/master/libwasi_littlefs/README.md
if you enable toywasm on nuttx -> multiple copies of littlefs. (note: nuttx with flat model links everything together)

it would be nice if we can use a different set of symbols to avoid conflicts.
eg. if built with "-DLFS_PREFIX=foo_", provide foo_lfs_mount instead of lfs_mount.
how do you think?

@geky
Copy link
Member

geky commented Mar 8, 2024

Hi @yamt, thanks for creating an issue.

I think this is better solved with external tooling.

littlefs has the scripts/changeprefix.py, which is how we generated the v2-prefix branch in CI.

Though this is just a glorified sed script:

sed 's/\<lfs_/mylfs_/g; s/\<LFS_/MYLFS_/g' lfs.c > lfs.p.c

You could even do this at link time with objcopy's --prefix-symbols or --redefine-sym(s).

You could run one of these when you update littlefs, or add it as an additional preprocessing step during compilation.


In most cases I would think you would want to actually link to the same littlefs to avoid the ~2x code cost, though I realize this isn't always possible if dependencies need different versions of littlefs.

@yamt
Copy link
Contributor Author

yamt commented Mar 8, 2024

Hi @yamt, thanks for creating an issue.

I think this is better solved with external tooling.

littlefs has the scripts/changeprefix.py, which is how we generated the v2-prefix branch in CI.

oh, i wasn't aware of the script.
i will take a look. thank you.

i had concerns about making such mechanical changes as it can make an update difficult.
but as far as it's the "officially supported" way, it's probably fine.

In most cases I would think you would want to actually link to the same littlefs to avoid the ~2x code cost, though I realize this isn't always possible if dependencies need different versions of littlefs.

in my case, they can have different compile-time options.

@geky
Copy link
Member

geky commented Mar 8, 2024

i had concerns about making such mechanical changes as it can make an update difficult.
but as far as it's the "officially supported" way, it's probably fine.

If it's implemented as a preprocessing step, it shouldn't be an update burden in theory.

# pretend these are build rules
sed 's/\<lfs_/mylfs_/g; s/\<LFS_/MYLFS_/g' lfs.c > lfs.p.c
cc -c lfs.p.c -o lfs.o
ld lfs.o main.o -o myapp

Or

# pretend these are build rules
cc -c lfs.c -o lfs.o
objcopy --prefix-symbols=my lfs.o lfs.p.o
ld lfs.p.o main.o -o myapp

@yamt
Copy link
Contributor Author

yamt commented Mar 11, 2024

ok.

i prefer the sed version because objcopy for mach-o is often broken from my experience.

@geky
Copy link
Member

geky commented Mar 11, 2024

That's fair. Also more chances for the type-checker to find script issues. It's unfortunate link-time tools are so failure-prone...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants