Re: Weird inline/struct offset problem
Re: Weird inline/struct offset problem
- Subject: Re: Weird inline/struct offset problem
- From: Allen Cronce <email@hidden>
- Date: Fri, 18 Aug 2006 08:07:57 -0700
Hi Chris,
Ah, I'd forgotten that with a debug build the inline functions likely
result in a number of compiler generated out-of-line functions. No
telling which one the linker will choose. So that explains the weirdness
factor.
After reading the responses to my post and discussing the issue with the
other team members here, I think it's time to bite the bullet. Namely,
the only low risk way to resolve the problem is to change the legacy
code base to use an alternatively named BOOL type that's defined the same.
While this will result in hundreds (or thousands) of source code edits,
the binary code generated on both Mac and Windows will be identical to
today's code. And it will side step the Objective C compatibility issue.
It's an irritating that we have to do this, especially to our Windows
developers. But we made the choice a decade ago to use Windows types for
this library, so now we have to deal with it.
Time to dust off CodeWarrior, which I prefer to use for non-project
based find and replace...
Thanks for your thoughts and suggestions.
Best,
--
Allen Cronce
Chris Bergmann wrote:
> I'd suggest that the function is not actually being inlined (this can
> happen in any C++ code, but is especially likely with a debug target.)
> In this situation, I believe that each compilation unit will create an
> out-of-line version of the function in question, and then the linker
> may merge the duplicates (someone please correct me if i got this
> wrong..)
>
> In this situation, it sounds like the linker is choosing the
> out-of-line version generated from one of your objective-C files as
> the 'master', and ignoring the versions generated from your pure C/C++
> files. This is unfortunate, but not something that you can control
> safely. You're much better off to move away from the duplicate
> definition, otherwise you'll never be certain that you've caught every
> single case where something could go wrong (as you've noticed, you
> won't get a compile error since the definition will be consistent
> within any given compilation unit.)
>
> One possible workaround might be to use the preprocessor to #define
> BOOL as some new type (eg. LEGACY_BOOL) inside your legacy headers,
> and #undef BOOL at the end of the headers - this is a bit nasty but
> will have the desired effect. Of course, it's much better to go
> through your legacy files and replace your use of BOOL with something
> unique, but you've already suggested that that would be problematic.
>
> You could also muck around with the force_inline attributes, but I
> doubt that these guarantee anything, so it's probably still leaving
> yourself open for future troubles.
>
> hth,
>
> chris
>
>
> On 17/08/2006, at 05:09 , Allen Cronce wrote:
>>
>> Basically inline methods for objects defined in the legacy library that
>> have BOOL members are demonstrating an offset mismatch. That is, a given
>> object can successfully access a member variable downstream of a BOOL
>> member variable. But an inline method that references the same member
>> gets the wrong offset.
>>
>> I would expect that to happen if the inline was called from Objective C
>> because if it was truly inlined, it would have a different definition
>> for BOOL. But it's also happening when an inline is referenced only in
>> the legacy library itself, which should have a consistent idea of how
>> BOOL is defined. Note that this is happening in the debug build with no
>> optimization, and with DWARF symbols.
>>
>> What seems to be happening is that all inlines, even those that are only
>> used in the legacy library, are using Objective C's idea of BOOL instead
>> of the legacy library's BOOL. Maybe this has something to do with Xcode
>> 2.4's new ability to step into inline functions?
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden