Skip to content

Conversation

@bc-lee
Copy link

@bc-lee bc-lee commented Aug 20, 2021

LC_BUILD_VERSION contains the min OS version on which this binary
was built to run for its platform in mach object. It is required for
targets like iOS Catalyst.

Also, emit the __LLVM segment, __asm section to tell the Apple
toolchain that this object is from assembler and has no bitcode.
This trick is used in Kotlin/Native, Rust, Flutter, Golang and yasm.

LC_BUILD_VERSION contains the min OS version on which this binary
was built to run for its platform in mach object. It is required for
targets like iOS Catalyst.

Also, emit the __LLVM segment, __asm section to tell the Apple
toolchain that this object is from assembler and has no bitcode.
This trick is used in Kotlin/Native, Rust, Flutter, Golang and yasm.
@bc-lee
Copy link
Author

bc-lee commented Aug 20, 2021

This patch was originally uploaded to the mailing list [1] but didn't have
any reviews, so I'm reposting it to Github. Please take a look.

[1] https://lists.nasm.us/archives/nasm-devel/2021-July/000035.html

sorokin added a commit to sorokin/nasm that referenced this pull request Feb 26, 2023
When running with -fsanitize=leak enabled nasm prints this error:

==19965==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 360 byte(s) in 90 object(s) allocated from:
    #0 0x7faee9396867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    netwide-assembler#1 0x5645d39a401c in nasm_malloc nasmlib/alloc.c:55
    netwide-assembler#2 0x5645d3a41f9d in string_transform asm/strfunc.c:356
    netwide-assembler#3 0x5645d3a37d40 in eval_strfunc asm/eval.c:761
    netwide-assembler#4 0x5645d3a37d40 in expr6 asm/eval.c:906
    netwide-assembler#5 0x5645d3a3968d in expr5 asm/eval.c:627
    netwide-assembler#6 0x5645d3a39aca in expr4 asm/eval.c:602
    netwide-assembler#7 0x5645d3a39b72 in expr3 asm/eval.c:563
    netwide-assembler#8 0x5645d3a39db8 in expr2 asm/eval.c:537
    netwide-assembler#9 0x5645d3a39f38 in expr1 asm/eval.c:511
    netwide-assembler#10 0x5645d3a3a0b8 in expr0 asm/eval.c:485
    netwide-assembler#11 0x5645d3a3a242 in rexp3 asm/eval.c:422
    netwide-assembler#12 0x5645d3a3a508 in rexp2 asm/eval.c:396
    netwide-assembler#13 0x5645d3a3a6a8 in rexp1 asm/eval.c:369
    netwide-assembler#14 0x5645d3a3a838 in rexp0 asm/eval.c:342
    netwide-assembler#15 0x5645d3a3a838 in cexpr asm/eval.c:305
    netwide-assembler#16 0x5645d3a3ad08 in bexpr asm/eval.c:298
    netwide-assembler#17 0x5645d3a3ad08 in evaluate asm/eval.c:1032
    netwide-assembler#18 0x5645d39e4f20 in parse_line asm/parser.c:959
    netwide-assembler#19 0x5645d399e243 in assemble_file asm/nasm.c:1735
    netwide-assembler#20 0x5645d3998801 in main asm/nasm.c:719
    netwide-assembler#21 0x7faee8aaed8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    netwide-assembler#22 0x7faee8aaee3f in __libc_start_main_impl ../csu/libc-start.c:392
    netwide-assembler#23 0x5645d399acd4 in _start (/home/ivan/d/nasm/nasm+0x2e5cd4)

SUMMARY: AddressSanitizer: 360 byte(s) leaked in 90 allocation(s).

This problem is reproducible on test utf.asm.

The problem was caused by the fact that eval_strfunc doesn't free the string
allocated by string_transform.
sorokin added a commit to sorokin/nasm that referenced this pull request Mar 5, 2023
When running with -fsanitize=leak enabled nasm prints this error:

==19965==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 360 byte(s) in 90 object(s) allocated from:
    #0 0x7faee9396867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    netwide-assembler#1 0x5645d39a401c in nasm_malloc nasmlib/alloc.c:55
    netwide-assembler#2 0x5645d3a41f9d in string_transform asm/strfunc.c:356
    netwide-assembler#3 0x5645d3a37d40 in eval_strfunc asm/eval.c:761
    netwide-assembler#4 0x5645d3a37d40 in expr6 asm/eval.c:906
    netwide-assembler#5 0x5645d3a3968d in expr5 asm/eval.c:627
    netwide-assembler#6 0x5645d3a39aca in expr4 asm/eval.c:602
    netwide-assembler#7 0x5645d3a39b72 in expr3 asm/eval.c:563
    netwide-assembler#8 0x5645d3a39db8 in expr2 asm/eval.c:537
    netwide-assembler#9 0x5645d3a39f38 in expr1 asm/eval.c:511
    netwide-assembler#10 0x5645d3a3a0b8 in expr0 asm/eval.c:485
    netwide-assembler#11 0x5645d3a3a242 in rexp3 asm/eval.c:422
    netwide-assembler#12 0x5645d3a3a508 in rexp2 asm/eval.c:396
    netwide-assembler#13 0x5645d3a3a6a8 in rexp1 asm/eval.c:369
    netwide-assembler#14 0x5645d3a3a838 in rexp0 asm/eval.c:342
    netwide-assembler#15 0x5645d3a3a838 in cexpr asm/eval.c:305
    netwide-assembler#16 0x5645d3a3ad08 in bexpr asm/eval.c:298
    netwide-assembler#17 0x5645d3a3ad08 in evaluate asm/eval.c:1032
    netwide-assembler#18 0x5645d39e4f20 in parse_line asm/parser.c:959
    netwide-assembler#19 0x5645d399e243 in assemble_file asm/nasm.c:1735
    netwide-assembler#20 0x5645d3998801 in main asm/nasm.c:719
    netwide-assembler#21 0x7faee8aaed8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    netwide-assembler#22 0x7faee8aaee3f in __libc_start_main_impl ../csu/libc-start.c:392
    netwide-assembler#23 0x5645d399acd4 in _start (/home/ivan/d/nasm/nasm+0x2e5cd4)

SUMMARY: AddressSanitizer: 360 byte(s) leaked in 90 allocation(s).

This problem is reproducible on test utf.asm.

The problem was caused by the fact that eval_strfunc doesn't free the string
allocated by string_transform.

Signed-off-by: Ivan Sorokin <[email protected]>
@mstorsjo
Copy link
Contributor

mstorsjo commented Nov 9, 2023

FWIW, I'm also interested in getting this added.

In Xcode 15.0, which was released recently, a brand-new linker is used, and this linker produces warnings like this, when linking nasm object files:

ld: warning: no platform load command found in 'obj.o', assuming: macOS

Actually, when Xcode 12.0 was released ~3 years ago, that also produced a similar warning:

Building for macOS, but linking in object file (obj.o) built for free standing

In that case, I believe the warning went away in the next minor update - so I guess it's plausible it will go away this time away; but if not, we'd need an option like this.

Yasm did implement something similar here: yasm/yasm@41762be However they control it via source directives, not command line options. I believe command line options are the better choice there, as they could be controlled in the same way as choosing between targeting macOS/iOS simulator etc. Yasm did choose to set macOS as default always, if nothing was chosen though. This avoids the linker warning when this matches the actual target, but produces hard errors instead of a soft warning if it turns out not to be the right choice.

@ePirat
Copy link

ePirat commented Sep 26, 2024

I am also very much interested in getting this merged, for the same reason mentioned above by @mstorsjo.

@rygorous rygorous mentioned this pull request Oct 4, 2024
@softworkz
Copy link

PR not merged or responded after 4 years? That's a somewhat long turnaround time...

It would be really nice to have this included.

Thanks

hpax pushed a commit that referenced this pull request Oct 6, 2025
When running with -fsanitize=leak enabled nasm prints this error:

==19965==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 360 byte(s) in 90 object(s) allocated from:
    #0 0x7faee9396867 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145
    #1 0x5645d39a401c in nasm_malloc nasmlib/alloc.c:55
    #2 0x5645d3a41f9d in string_transform asm/strfunc.c:356
    #3 0x5645d3a37d40 in eval_strfunc asm/eval.c:761
    #4 0x5645d3a37d40 in expr6 asm/eval.c:906
    #5 0x5645d3a3968d in expr5 asm/eval.c:627
    #6 0x5645d3a39aca in expr4 asm/eval.c:602
    #7 0x5645d3a39b72 in expr3 asm/eval.c:563
    #8 0x5645d3a39db8 in expr2 asm/eval.c:537
    #9 0x5645d3a39f38 in expr1 asm/eval.c:511
    #10 0x5645d3a3a0b8 in expr0 asm/eval.c:485
    #11 0x5645d3a3a242 in rexp3 asm/eval.c:422
    #12 0x5645d3a3a508 in rexp2 asm/eval.c:396
    #13 0x5645d3a3a6a8 in rexp1 asm/eval.c:369
    #14 0x5645d3a3a838 in rexp0 asm/eval.c:342
    #15 0x5645d3a3a838 in cexpr asm/eval.c:305
    #16 0x5645d3a3ad08 in bexpr asm/eval.c:298
    #17 0x5645d3a3ad08 in evaluate asm/eval.c:1032
    #18 0x5645d39e4f20 in parse_line asm/parser.c:959
    #19 0x5645d399e243 in assemble_file asm/nasm.c:1735
    #20 0x5645d3998801 in main asm/nasm.c:719
    #21 0x7faee8aaed8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #22 0x7faee8aaee3f in __libc_start_main_impl ../csu/libc-start.c:392
    #23 0x5645d399acd4 in _start (/home/ivan/d/nasm/nasm+0x2e5cd4)

SUMMARY: AddressSanitizer: 360 byte(s) leaked in 90 allocation(s).

This problem is reproducible on test utf.asm.

The problem was caused by the fact that eval_strfunc doesn't free the string
allocated by string_transform.

Signed-off-by: Ivan Sorokin <[email protected]>
@hpax
Copy link
Member

hpax commented Oct 9, 2025

@softworkz it wasn't until just a few weeks ago that we started using github. Somehow people submitted pull requests here anyway, that we never saw.

@hpax
Copy link
Member

hpax commented Oct 9, 2025

I would really much rather see this implemented as an output %pragma. Only allowing it on the command line really is not desirable, and if it is a %pragma then --pragma allows it on the command line, too.

@softworkz
Copy link

softworkz commented Oct 10, 2025

@softworkz it wasn't until just a few weeks ago that we started using github. Somehow people submitted pull requests here anyway, that we never saw.

Ah, alright - that's the point that (probably) nobody knew :-)

The other site looked kind of abandoned, I suppose,this let us think that GitHub is the place to go..
Thanks a lot for responding

@bc-lee
Copy link
Author

bc-lee commented Oct 10, 2025

Finally got a review after 4 years! :)

Before modifying this PR, I’d like to clarify — is the mailing list no longer used for discussions and patch submissions? It seems that several PRs are being merged directly on GitHub, so I just want to make sure that’s the current process.

@hpax
Copy link
Member

hpax commented Oct 10, 2025

Yes, that is the current process. However, it turns out that this was already implemented as a %pragma and merged in NASM 3.00rc20, so this PR is redundant and can be closed.

@hpax hpax closed this Oct 10, 2025
@bc-lee
Copy link
Author

bc-lee commented Oct 11, 2025

Understood. It would’ve been nice to get at least a quick review or acknowledgment before closing — this patch was posted on both GitHub and the mailing list four years ago, and the recently added %pragma feature covers what this originally implemented.

@bc-lee bc-lee deleted the feature/lc-load-version branch October 11, 2025 04:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants