Hi Iain,
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.
> > 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 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.
> 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.
> > 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?
> > 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
