[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH 00/18] Xfbdev Atari and Amiga support



On 04/24/13 10:28 PM, Geert Uytterhoeven wrote:
On Thu, Apr 25, 2013 at 7:23 AM, Alan Coopersmith
<alan.coopersmith@oracle.com> wrote:
On 04/24/13 10:00 PM, Keith Packard wrote:
Alan Coopersmith <alan.coopersmith@oracle.com> writes:
On 04/24/13 06:58 PM, Keith Packard wrote:

Alan Coopersmith <alan.coopersmith@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@oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc


Reply to: