[PATCH 00/18] Xfbdev Atari and Amiga support

Geert Uytterhoeven geert at linux-m68k.org
Wed Apr 24 22:28:39 PDT 2013


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.

>> 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?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds


More information about the xorg-devel mailing list