[PATCH] fix inlining related build failures in mxser.c

[PATCH] fix inlining related build failures in mxser.c

[Jesper Juhl]

Hi,

An allyesconfig build of 2.6.10-rc3-bk16 revealed the following build 
failures (which arefixed by the patch below) :

  CC      drivers/char/mxser.o
drivers/char/mxser.c: In function `mxser_ioctl':
drivers/char/mxser.c:415: sorry, unimplemented: inlining failed in call to 
'mxser_check_modem_status': function body not available
drivers/char/mxser.c:1407: sorry, unimplemented: called from here
make[2]: *** [drivers/char/mxser.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

  CC      drivers/char/mxser.o
drivers/char/mxser.c: In function `mxser_interrupt':
drivers/char/mxser.c:413: sorry, unimplemented: inlining failed in call to 
'mxser_receive_chars': function body not available
drivers/char/mxser.c:1953: sorry, unimplemented: called from here
drivers/char/mxser.c:413: sorry, unimplemented: inlining failed in call to 
'mxser_receive_chars': function body not available
drivers/char/mxser.c:1960: sorry, unimplemented: called from here
drivers/char/mxser.c:414: sorry, unimplemented: inlining failed in call to 
'mxser_transmit_chars': function body not available
drivers/char/mxser.c:1969: sorry, unimplemented: called from here
drivers/char/mxser.c:414: sorry, unimplemented: inlining failed in call to 
'mxser_transmit_chars': function body not available
drivers/char/mxser.c:1978: sorry, unimplemented: called from here
make[2]: *** [drivers/char/mxser.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

  CC      drivers/char/mxser.o
drivers/char/mxser.c: In function `mxser_interrupt':
drivers/char/mxser.c:414: sorry, unimplemented: inlining failed in call to 
'mxser_transmit_chars': function body not available
drivers/char/mxser.c:1969: sorry, unimplemented: called from here
drivers/char/mxser.c:414: sorry, unimplemented: inlining failed in call to 
'mxser_transmit_chars': function body not available
drivers/char/mxser.c:1978: sorry, unimplemented: called from here
make[2]: *** [drivers/char/mxser.o] Error 1
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2


One simple way to fix those is to simply un-inline the functions in 
question (and since they are somewhat large that's what I did) - an 
alternative would be to rework the ordering of the file so the functions 
are defined before their first use.


Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>

diff -up linux-2.6.10-rc3-bk16-orig/drivers/char/mxser.c linux-2.6.10-rc3-bk16/drivers/char/mxser.c
--- linux-2.6.10-rc3-bk16-orig/drivers/char/mxser.c	2004-12-23 23:26:48.000000000 +0100
+++ linux-2.6.10-rc3-bk16/drivers/char/mxser.c	2004-12-24 01:54:15.000000000 +0100
@@ -410,9 +410,9 @@ static void mxser_start(struct tty_struc
 static void mxser_hangup(struct tty_struct *);
 static void mxser_rs_break(struct tty_struct *, int);
 static irqreturn_t mxser_interrupt(int, void *, struct pt_regs *);
-static inline void mxser_receive_chars(struct mxser_struct *, int *);
-static inline void mxser_transmit_chars(struct mxser_struct *);
-static inline void mxser_check_modem_status(struct mxser_struct *, int);
+static void mxser_receive_chars(struct mxser_struct *, int *);
+static void mxser_transmit_chars(struct mxser_struct *);
+static void mxser_check_modem_status(struct mxser_struct *, int);
 static int mxser_block_til_ready(struct tty_struct *, struct file *, struct mxser_struct *);
 static int mxser_startup(struct mxser_struct *);
 static void mxser_shutdown(struct mxser_struct *);
@@ -1989,7 +1989,7 @@ static irqreturn_t mxser_interrupt(int i
 	return handled;
 }
 
-static inline void mxser_receive_chars(struct mxser_struct *info, int *status)
+static void mxser_receive_chars(struct mxser_struct *info, int *status)
 {
 	struct tty_struct *tty = info->tty;
 	unsigned char ch, gdl;
@@ -2143,7 +2143,7 @@ intr_old:
 
 }
 
-static inline void mxser_transmit_chars(struct mxser_struct *info)
+static void mxser_transmit_chars(struct mxser_struct *info)
 {
 	int count, cnt;
 	unsigned long flags;
@@ -2206,7 +2206,7 @@ static inline void mxser_transmit_chars(
 	spin_unlock_irqrestore(&info->slock, flags);
 }
 
-static inline void mxser_check_modem_status(struct mxser_struct *info, int status)
+static void mxser_check_modem_status(struct mxser_struct *info, int status)
 {
 	/* update input line counters */
 	if (status & UART_MSR_TERI)

Re: [PATCH] fix inlining related build failures in mxser.c

[Alan Cox]

On Fri, Dec 24, 2004 at 02:01:18AM +0100, Jesper Juhl wrote:
> An allyesconfig build of 2.6.10-rc3-bk16 revealed the following build 
> failures (which arefixed by the patch below) :

Please send it on to Linus. I've never tried to build any moxa driver with
such a new compiler version. It looks the right thing to do.

(Moxa support removed from cc list)

Alan

Re: [PATCH] fix inlining related build failures in mxser.c

[Jesper Juhl]

Hi Linus,

Sending this to you as pr Alan's request.

On Thu, 23 Dec 2004, Alan Cox wrote:

> On Fri, Dec 24, 2004 at 02:01:18AM +0100, Jesper Juhl wrote:
> > An allyesconfig build of 2.6.10-rc3-bk16 revealed the following build 
> > failures (which arefixed by the patch below) :
> 
> Please send it on to Linus. I've never tried to build any moxa driver with
> such a new compiler version. It looks the right thing to do.
> 
> (Moxa support removed from cc list)
> 
> Alan
> 

Simple way to fix those is to simply un-inline the functions in question 
(and since they are somewhat large that's what I did) - an alternative 
would be to rework the ordering of the file so the functions are defined 
before their first use.
(for the actual build errors see my original post to Alan/lkml with same 
subject - I got this with gcc 3.4.1 btw)


Signed-off-by: Jesper juhl <juhl-lkml@dif.dk>

diff -up linux-2.6.10-rc3-bk16-orig/drivers/char/mxser.c linux-2.6.10-rc3-bk16/drivers/char/mxser.c
--- linux-2.6.10-rc3-bk16-orig/drivers/char/mxser.c	2004-12-23 23:26:48.000000000 +0100
+++ linux-2.6.10-rc3-bk16/drivers/char/mxser.c	2004-12-24 01:54:15.000000000 +0100
@@ -410,9 +410,9 @@ static void mxser_start(struct tty_struc
 static void mxser_hangup(struct tty_struct *);
 static void mxser_rs_break(struct tty_struct *, int);
 static irqreturn_t mxser_interrupt(int, void *, struct pt_regs *);
-static inline void mxser_receive_chars(struct mxser_struct *, int *);
-static inline void mxser_transmit_chars(struct mxser_struct *);
-static inline void mxser_check_modem_status(struct mxser_struct *, int);
+static void mxser_receive_chars(struct mxser_struct *, int *);
+static void mxser_transmit_chars(struct mxser_struct *);
+static void mxser_check_modem_status(struct mxser_struct *, int);
 static int mxser_block_til_ready(struct tty_struct *, struct file *, struct mxser_struct *);
 static int mxser_startup(struct mxser_struct *);
 static void mxser_shutdown(struct mxser_struct *);
@@ -1989,7 +1989,7 @@ static irqreturn_t mxser_interrupt(int i
 	return handled;
 }
 
-static inline void mxser_receive_chars(struct mxser_struct *info, int *status)
+static void mxser_receive_chars(struct mxser_struct *info, int *status)
 {
 	struct tty_struct *tty = info->tty;
 	unsigned char ch, gdl;
@@ -2143,7 +2143,7 @@ intr_old:
 
 }
 
-static inline void mxser_transmit_chars(struct mxser_struct *info)
+static void mxser_transmit_chars(struct mxser_struct *info)
 {
 	int count, cnt;
 	unsigned long flags;
@@ -2206,7 +2206,7 @@ static inline void mxser_transmit_chars(
 	spin_unlock_irqrestore(&info->slock, flags);
 }
 
-static inline void mxser_check_modem_status(struct mxser_struct *info, int status)
+static void mxser_check_modem_status(struct mxser_struct *info, int status)
 {
 	/* update input line counters */
 	if (status & UART_MSR_TERI)

Re: [PATCH] fix inlining related build failures in mxser.c

[Jan Engelhardt]

>Hi,
>
>An allyesconfig build of 2.6.10-rc3-bk16 revealed the following build 
>failures (which arefixed by the patch below) :
>
>  CC      drivers/char/mxser.o
>drivers/char/mxser.c: In function `mxser_ioctl':
>drivers/char/mxser.c:415: sorry, unimplemented: inlining failed in call to 
>'mxser_check_modem_status': function body not available
>drivers/char/mxser.c:1407: sorry, unimplemented: called from here
>make[2]: *** [drivers/char/mxser.o] Error 1
>make[1]: *** [drivers/char] Error 2
>make: *** [drivers] Error 2

Add -funit-at-a-time to the CFLAGS, and the compiler is happy.


Jan Engelhardt
-- 
ENOSPC

Re: [PATCH] fix inlining related build failures in mxser.c

[Jesper Juhl]

On Fri, 24 Dec 2004, Jan Engelhardt wrote:

> >Hi,
> >
> >An allyesconfig build of 2.6.10-rc3-bk16 revealed the following build 
> >failures (which arefixed by the patch below) :
> >
> >  CC      drivers/char/mxser.o
> >drivers/char/mxser.c: In function `mxser_ioctl':
> >drivers/char/mxser.c:415: sorry, unimplemented: inlining failed in call to 
> >'mxser_check_modem_status': function body not available
> >drivers/char/mxser.c:1407: sorry, unimplemented: called from here
> >make[2]: *** [drivers/char/mxser.o] Error 1
> >make[1]: *** [drivers/char] Error 2
> >make: *** [drivers] Error 2
> 
> Add -funit-at-a-time to the CFLAGS, and the compiler is happy.
> 
But, does unit-at-a-time work reliably for all compilers on all archs back 
to and including gcc 2.95.3 ?   Isn't is safer/simpler to just uninline 
the functions or reorder the file?

-- 
Jesper Juhl

acct() ?

[Folkert van Heusden]

Ehr,

Has the contents of the structures returned by acct() changed by any chance?
(I mean: 2.6.9 being different from 2.4.26)


Folkert van Heusden

Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+------------------------------------------------------------------+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See    |
|http://vanheusden.com/multitail/features.html for a feature list. |
+------------------------------------------= www.unixsoftware.nl =-+

Re: acct() ?

[Jasper Spaans]

On Fri, Dec 24, 2004 at 02:33:45PM +0100, Folkert van Heusden wrote:

> Has the contents of the structures returned by acct() changed by any chance?
> (I mean: 2.6.9 being different from 2.4.26)

That depends on whether you've set CONFIG_BSD_PROCESS_ACCT_V3=y in your
configuration.

-- 
Jasper Spaans                                       http://jsp.vs19.net/
 15:30:15 up 10173 days,  7:17, 0 users, load average: 7.52 6.58 5.72
  -... .- -.. --. . .-. -... .- -.. --. . .-. -... .- -.. --. . .-.

Re: [PATCH] fix inlining related build failures in mxser.c

[Florian Weimer]

* Jesper Juhl:

>> Add -funit-at-a-time to the CFLAGS, and the compiler is happy.
>> 
> But, does unit-at-a-time work reliably for all compilers on all archs back 
> to and including gcc 2.95.3 ? 

Unit-at-a-time is only available in GCC 3.4 and above.
Function-at-a-time will still be supported in GCC 4.0, but this
version will use unit-at-a-time by default (if optimization is
enable).

Re: [PATCH] fix inlining related build failures in mxser.c

[Adrian Bunk]

On Fri, Dec 24, 2004 at 02:54:43PM +0100, Florian Weimer wrote:
> * Jesper Juhl:
> 
> >> Add -funit-at-a-time to the CFLAGS, and the compiler is happy.
> >> 
> > But, does unit-at-a-time work reliably for all compilers on all archs back 
> > to and including gcc 2.95.3 ? 
> 
> Unit-at-a-time is only available in GCC 3.4 and above.
> Function-at-a-time will still be supported in GCC 4.0, but this
> version will use unit-at-a-time by default (if optimization is
> enable).

unit-at-a-time is already enabled at -O2 in 3.4 .

The kernel Makefile explicitely disables it on i386.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] fix inlining related build failures in mxser.c

[Mikael Pettersson]

On Fri, 24 Dec 2004 14:54:43 +0100, Florian Weimer wrote:
>* Jesper Juhl:
>
>>> Add -funit-at-a-time to the CFLAGS, and the compiler is happy.
>>> 
>> But, does unit-at-a-time work reliably for all compilers on all archs back 
>> to and including gcc 2.95.3 ? 
>
>Unit-at-a-time is only available in GCC 3.4 and above.

The problem with unit-at-a-time isn't compiler availability,
but the fact that at least with gcc-3.4 on x86 it causes
significant stack usage increases, which in the kernel lead
to stack overflow problems. This is not a theoretical issue,
the overflows have been observed in normal kernels.

So wrt inlining failures, the correct fix is to remove the
inlines or rearrange the code to allow inlining w/o unit-at-a-time.

/Mikael

Re: [PATCH] fix inlining related build failures in mxser.c

[Jan Engelhardt]

>>>> Add -funit-at-a-time to the CFLAGS, and the compiler is happy.
>>>> 
>>> But, does unit-at-a-time work reliably for all compilers on all archs back 
>>> to and including gcc 2.95.3 ? 
>>
>>Unit-at-a-time is only available in GCC 3.4 and above.

No, it's already in my 3.3.0 (SUSE Linux 8.2) and continues to exist in 3.3.3 
(9.2)

>The problem with unit-at-a-time isn't compiler availability,
>but the fact that at least with gcc-3.4 on x86 it causes
>significant stack usage increases, which in the kernel lead
>to stack overflow problems. This is not a theoretical issue,
>the overflows have been observed in normal kernels.
>
>So wrt inlining failures, the correct fix is to remove the
>inlines or rearrange the code to allow inlining w/o unit-at-a-time.

Or making some pressure on gcc developers to fix the increase.



Jan Engelhardt
-- 
ENOSPC

Re: [PATCH] fix inlining related build failures in mxser.c

[Jesper Juhl]

On Sat, 25 Dec 2004, Jan Engelhardt wrote:

> >>>> Add -funit-at-a-time to the CFLAGS, and the compiler is happy.
> >>>> 
> >>> But, does unit-at-a-time work reliably for all compilers on all archs back 
> >>> to and including gcc 2.95.3 ? 
> >>
> >>Unit-at-a-time is only available in GCC 3.4 and above.
> 
> No, it's already in my 3.3.0 (SUSE Linux 8.2) and continues to exist in 3.3.3 
> (9.2)
> 
> >The problem with unit-at-a-time isn't compiler availability,
> >but the fact that at least with gcc-3.4 on x86 it causes
> >significant stack usage increases, which in the kernel lead
> >to stack overflow problems. This is not a theoretical issue,
> >the overflows have been observed in normal kernels.
> >
> >So wrt inlining failures, the correct fix is to remove the
> >inlines or rearrange the code to allow inlining w/o unit-at-a-time.
> 
> Or making some pressure on gcc developers to fix the increase.
> 
But that won't do people using older gcc's to build the kernel any good.


-- 
Jesper Juhl