[PATCH 00/18] Xfbdev Atari and Amiga support

Alan Coopersmith alan.coopersmith at oracle.com
Wed Apr 24 22:42:08 PDT 2013


On 04/24/13 10:28 PM, Geert Uytterhoeven wrote:
> On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith
> <alan.coopersmith at oracle.com> wrote:
>> On 04/24/13 10:00 PM, Keith Packard wrote:
>>> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
>>>> On 04/24/13 06:58 PM, Keith Packard wrote:
>>>>>
>>>>> Alan Coopersmith <alan.coopersmith at oracle.com> writes:
>>>>>
>>>>>> This broke my build:
>>>>>>
>>>>>> Undefined                       first referenced
>>>>>>     symbol                             in file
>>>>>> c2p_unsupported
>>>>>> ../../../miext/shadow/.libs/libshadow.a(shafb4.o)
>>>>>
>>>>>
>>>>> Builds fine with GCC; perhaps that figures out that this function can
>>>>> never be called?
>>>>
>>>>
>>>> If I build with gcc 4.7.2 with -O2 it indeed optimizes it out.
>>>> If I build with gcc 4.7.2 with -g and no -O flags, it fails the same
>>>> way.
>
> Sorry, I forgot that unlike Linux kernel people, xorg people sometimes
> do compile
> without optimization.

Or in the case I first hit this, with optimization using compilers that
aren't gcc.  (Xorg is built on several non-Linux platforms, with compilers
such as clang or Solaris Studio.)

>>> That makes sense at least. We could either make c2p_unsupported call
>>> FatalError or just be a no-op. Any preference?
>>
>>
>> I'd prefer at least a BUG_WARN() over a no-op, to give us a hint why
>> stuff isn't working, though FatalError() also works for something that
>> should be impossible to hit.
>
> Or assert(), or <insert xorg favorite runtime check method here>.
>
> This should be indeed impossible to hit, as all calls to the c2p functions
> use hardcoded parameters.
>
> I'm just a bit afraid that adding real error handling will slow down the code.
> Can it be dependent on DEBUG or so?

Does it matter if the compiler optimizes out the call to c2p_unsupported?
The performance should be the same for you.

Or does this code even need to be built for non-68k platforms at all?
(I'm still confused why we just took a big chunk of code for a platform
  with no active maintainer, but if Keith's willing to maintain it himself,
  that's his call.   I do hope we can fix the license before release to be
  a standard license, not yet another one-off we all have to add to our
  packages to comply with the terms of.)

-- 
	-Alan Coopersmith-              alan.coopersmith at oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc


More information about the xorg-devel mailing list