From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg McGary To: Chris Lattner Cc: gcc@gcc.gnu.org, bernecky@acm.org, gnu@toad.com Subject: Re: Esthetics (or worse?) of Secure Pointers Date: Tue, 17 Apr 2001 16:36:00 -0000 Message-id: References: X-SW-Source: 2001-04/msg00822.html Chris Lattner writes: > Another alternative way to implement this (which would allow a single libc > that contains both bounded pointer code and nonbounded pointer code to > exist in the same library), would be to mangle function names, ala > C++. Of course you could do this really simply by simply prefixing all > functions (C as well) with __BP_ or some such ugly thing. I want to move in the opposite direction, and drop the __BP_ prefix, since it complicates symbolic debugging, and I don't want to burden gdb with hiding the prefix. OTOH, the reason I introduced the prefix in the first place remains valid: I wanted to catch unintentional mixing of BP and non-BP code at link time, so as to prevent much-more-painful-to-debug runtime incompatibilities. Perhaps that can be accomplished some other way. Since we all agree that compilation units will either be 100% or 0% BP, we needn't have a mechanism that operates at the granularity of functions as the current __BP_ prefix does. We could introduce a special symbol that marks a BP object (analogous to gcc2_compiled.), and make ld gripe if it sees any mixing of BP and non-BP objects. > This isn't a wonderful solution from a cleanliness standpoint, but it > would make it "impossible" to accidentally mismatch code. It would also > make it possible to have a library with both bounded pointer and > nonbounded pointer code linked into it, which would be nice. The libs should remain separate just as they do for other multilibs. Greg