hi Andre, > On 1 Oct 2025, at 16:40, Andre Vehreschild <[email protected]> wrote:
> thanks for the reply. Please note, I am normaly working on Linux and know my > way around when doing Windows system programming. MacOS was new for me and I > needed to figure the differences from Linux. > >>> while debugging a fortran runtime library on a recent MacOS, I tried to use >>> the libsanitizer provided with gcc. It compiled, but no asan enabled >>> program could start on MacOS Sequoia. I figured from libsanitizers github, >>> that the shared cache needs to be consulted from some OS version on. >> >> Right, which is why I’d disabled it until we have support. > > Ok, so what do you use to track down an error, you would use an address > sanitizer for, on MacOS in a multi-process program? I asked some of my > colleagues which use Macs and they do not have that use case and therefore no > answer. It is a missing piece at the moment - as the macOS maintainer, fortunately I do have access to earlier (quite recent) versions on which the sanitizers are still functional - but this does need fixing. For the record, valgrind is also usually somewhat ‘behind’ c.f. the most recent OS versions. >>> The support present in >>> github uses proprietary extensions to C++, that do not compile on gcc. >> >> Well Apple Blocks are publicly specified and available on open source >> clang, so I think that they are more “clang-extension” than “proprietary" >> the barrier to implementing them in GCC is time only. > > Are they used on different OSes? Or are they Mac-specific? I only found some > documentation about them in an apple kernel documentation. And there only > their > application was described, not their structure. I’m not aware of any use outside of macOS (but, I guess, there could be uses elsewhere on platforms that support clang - the runtime part is not too complex to implement, and the blocks implementation is in upstream clang). AFAIR, Apple Blocks were offered some time ago ( > 20 years) for standardisation but that did not succeed - I don’t know exactly why not, before my time amongst the details; they provide a closure that works for both C and C++ (and Objective-C and C++) which has some merits in commonality. Of course, now C++ has lambdas, but those post-date the original Apple Blocks impl (gcc-4.2.1). >>> I figured >>> how to translate this into pure C++, which what the patch is about. The >>> solution is somewhat hacky and I don't know what to do with it. It works, >>> address faults are reported correctly at least on >>> x86_64-apple-darwin24.something. I am open for suggestions what to do it. >>> I do not assume, that upstream libsanitizer will apply the patch, because >>> it is GCC specific. >> >> The API that needs to be emulated is “Apple Blocks” (which looks a bit like >> some of the Objective-C stuff - but actually has more state). We do not, >> yet, indeed support - so I think it might be necessary to apply some tweaks >> to >> what you’ve done to make sure that the file-scope structures that the >> blocks system requires are present - what works now might not in the future >> unless we emulate the whole thing. > > Agreed. For the moment it works. I will certainly be looking to solve this for GCC-16. >> That work-around is in my WIP but not quite ready - so perhaps the two >> patches >> can be combined. > > My patch is open source. Just do with it what you can or discard it. I just > wanted to let people know about a small work around that helped me a lot. much appreciated - if you find yourself investing significant effort on macOS, please ping me in case I have WIP that could help (since it’s $hobby I have quite a bit in flight and not yet ready to post). >>> I tried to rebase GCC's libsanitizer to the github's state, but there are >>> more locations where now proprietary extensions are used. >> >> Do you mean “proprietary” or “clang” here? >> - AFAIU the sanitizers are still open-sourced. > > I deemed these extensions in a C++-file to be something that works on > AppleClang only. Because all of this is only present in files that treat > Mac-specifics. May be "proprietary" is the wrong word (mind you, I am Geman), > and Mac-specific or AppleClang-specific would be more precise? I think the important distinction is that “proprietary” to me implies that the technology is not free to be re-implemented elsewhere (i.e. protected as intellectual property in some way) … whereas a “clang extension” is no different from a “gnu extension” the other toolchain is free to implement it if that is desired (which in this case it is for macOS at least, it’s just a question of finding time for it since it’s quite a big project). thanks again Iain >>> To not loose the patch, I >>> thought I publish it here, so that at least some one may find it. >> >> thanks, we do want a solution to this, >> Iain >> > Your welcome and regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de
