[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