Jan Engelhardt | 2 Nov 14:48 2005
Picon

Re: [parisc-linux] [2.6 patch] parisc: "extern inline" -> "static inline"


>> "extern inline" doesn't make much sense.

But GNU's ld is said to be smart enough to handle this like the 
developerwants "extern AND inline". I did not try, though.

Jen

Matthew Wilcox | 2 Nov 14:53 2005

Re: [parisc-linux] [2.6 patch] parisc: "extern inline" -> "static inline"

On Wed, Nov 02, 2005 at 02:48:42PM +0100, Jan Engelhardt wrote:
> 
> >> "extern inline" doesn't make much sense.
> 
> But GNU's ld is said to be smart enough to handle this like the 
> developerwants "extern AND inline". I did not try, though.

I think you're gravely confused.  Look at the assembly that gcc spits
out for extern inline functions.  The linker never even gets to see the
function.  Try it out, it'll be good practice for you.
Matthew Wilcox | 12 Nov 07:39 2005

2.6.15-rc1 freeing a reserved page from uart_shutdown


I'm having some trouble with 2.6.15-rc1:

VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 640k freed
Bad page state at free_hot_cold_page (in process 'init', page 108a24a0)
flags:0x00000400 mapping:00000000 mapcount:0 count:0
Backtrace:
Backtrace:
 [<101481cc>] bad_page+0x70/0xc4
 [<10148920>] free_hot_cold_page+0x74/0x124
 [<10275e68>] uart_shutdown+0xf0/0xf8
 [<102775f8>] uart_close+0xc8/0x214
 [<1025c710>] release_dev+0x72c/0x734
 [<1025cddc>] tty_release+0x10/0x20
 [<101680f0>] __fput+0x15c/0x170
 [<10166520>] filp_close+0x58/0x94
 [<1010d114>] syscall_exit+0x0/0x14

This is on a parisc system, though a very similar tree boots fine on a
different machine.  The machine which produces this message is a K460
which uses the Mux serial driver.  As far as I can tell, the only call
to free_hot_cold_page() in uart_shutdown() is to free info->xmit.buf
which seems to be always filled by a call to get_zeroed_page().

This problem doesn't show with 2.6.14.  I can give access to this
machine to anyone who wants to do some debugging.  It has remote power
capabilities ;-)
Matthew Wilcox | 13 Nov 15:06 2005

Re: [parisc-linux] 2.6.15-rc1 freeing a reserved page from uart_shutdown

On Fri, Nov 11, 2005 at 11:39:14PM -0700, Matthew Wilcox wrote:
> I'm having some trouble with 2.6.15-rc1:
> 
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 640k freed
> Bad page state at free_hot_cold_page (in process 'init', page 108a24a0)
> flags:0x00000400 mapping:00000000 mapcount:0 count:0

False alarm.  I did a make clean and then rebuilt and the resulting kernel
booted fine.  Not sure what went wrong, but now it's unreproducible.
Fabio Bizzi | 30 Nov 09:38 2005
Picon

Strange compiler behavior

Hi PA-Gurus! :)

I've tried to compile a LiveMedia test program on my B180L with sarge 
and etch 2.6.12-1-parisc kernel installed.

If I give all the correct include all goes well and a correct executable 
is produced, the following is the working compile string:

bizzi <at> b180l:~/examples$ g++ testMP3Streamer.cpp -o testMP3Streamer 
-I/usr/include/liveMedia/ -I/usr/include/groupsock/ 
-I/usr/include/BasicUsageEnvironment -I/usr/include/UsageEnvironment 
-lliveMedia -lgroupsock -lBasicUsageEnvironment -lUsageEnvironment

But if I miss a couple of include dir I have a correct error generation 
and a strange message in /var/log/debug , the uncorrect compile string is:

g++ testMP3Streamer.cpp -o testMP3Streamer -I/usr/include/liveMedia/ 
-I/usr/include/groupsock/ -lliveMedia -lgroupsock 
-lBasicUsageEnvironment -lUsageEnvironment

and the /var/log/debug message is:

8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-

do_page_fault() pid=19583 command='cc1plus' type=15 address=0x000000ec

      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001101111100100001111 Not tainted
r00-03  00000000 0036c198 0002570f 4062eaf0
r04-07  40014cb0 4062eaf0 0036c198 00000000
(Continue reading)

Fabio Bizzi | 30 Nov 11:08 2005
Picon

Re: Strange compiler behavior

Hi Randolph

Randolph Chung wrote:
> Looks like you found a gcc bug. What happened is that g++ crashed
> (SIGSEGV) while processing your file.
> 
> It seems to be only in g++-3.3. I tried with g++-3.3 and g++-4.0.2 and
> can not reproduce the problem.
[...]
> Perhaps you can try a newer gcc, or file a bug upstream with the gcc
> developers. See http://gcc.gnu.org/bugs.html

Thank you for the help Randolph!!! :)

I've installed g++-3.4 from sarge archives, now I have another problem.
When I try to compile the same source with the correct string and 
includes I get a lot of undefined references, I suppose that it is due 
because LiveMedia libraries was compiled with g++3.3.5 (The default 
sarge compiler).

How can I test it?

Can I download the source code of LiveMedia and compile it from scratch 
with 3.4 g++ and do again the test with new liblivemdia.a library?

Thank You again!

Ciao.

	Fabio.
(Continue reading)

Randolph Chung | 30 Nov 10:28 2005

Re: Strange compiler behavior

> But if I miss a couple of include dir I have a correct error generation
> and a strange message in /var/log/debug , the uncorrect compile string is:

Looks like you found a gcc bug. What happened is that g++ crashed
(SIGSEGV) while processing your file.

It seems to be only in g++-3.3. I tried with g++-3.3 and g++-4.0.2 and
can not reproduce the problem.

The limited stack trace is:

Program received signal SIGSEGV, Segmentation fault.
0x000255fc in pop_everything ()
(gdb) bt
#0  0x000255fc in pop_everything ()
#1  0x0002f834 in cxx_insert_default_attributes ()
#2  0x00072688 in cxx_make_type ()
#3  0x000b7870 in c_common_parse_file ()
#4  0x0022bb8c in rtx_addr_varies_p ()
#5  0x00231224 in rtx_addr_varies_p ()
#6  0x002312e8 in rtx_addr_varies_p ()
#7  0x401ee6e4 in __libc_start_main () from /lib/libc.so.6
#8  0x00016a58 in ?? ()
(gdb) x/i $pc
0x255fc <pop_everything+808>:   ldw ec(,r20),r3
(gdb) print /x $r20
$1 = 0x0

Perhaps you can try a newer gcc, or file a bug upstream with the gcc
developers. See http://gcc.gnu.org/bugs.html
(Continue reading)

John David Anglin | 30 Nov 13:49 2005
Picon

Re: [parisc-linux] Strange compiler behavior

> g++ testMP3Streamer.cpp -o testMP3Streamer -I/usr/include/liveMedia/ 
> -I/usr/include/groupsock/ -lliveMedia -lgroupsock 
> -lBasicUsageEnvironment -lUsageEnvironment
> 
> and the /var/log/debug message is:
> 
> 8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-8<-
> 
> do_page_fault() pid=19583 command='cc1plus' type=15 address=0x000000ec

The compiler shouldn't produce a page fault without an internal compiler
error message (ICE).  All ICEs are bugs.  You should generate the
preprocessed source for your program ('-E' option) and file a GCC PR
report.  There are instructions on gcc.gnu.org on how to file a bug
report.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

John David Anglin | 30 Nov 13:59 2005
Picon

Re: [parisc-linux] Re: Strange compiler behavior

> I've installed g++-3.4 from sarge archives, now I have another problem.
> When I try to compile the same source with the correct string and 
> includes I get a lot of undefined references, I suppose that it is due 
> because LiveMedia libraries was compiled with g++3.3.5 (The default 
> sarge compiler).

Unlikely.  More likely you are missing a library specification in
your link command, or you have an incompatible installation of development
and runtime packages for LiveMedia and/or one of the packages it requires.

Check this using dpkg.  The names of the undefined symbols should also
give a clue as to which library they are in.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

John David Anglin | 30 Nov 13:51 2005
Picon

Re: [parisc-linux] Re: Strange compiler behavior

> The limited stack trace is:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x000255fc in pop_everything ()
> (gdb) bt
> #0  0x000255fc in pop_everything ()
> #1  0x0002f834 in cxx_insert_default_attributes ()
> #2  0x00072688 in cxx_make_type ()
> #3  0x000b7870 in c_common_parse_file ()
> #4  0x0022bb8c in rtx_addr_varies_p ()
> #5  0x00231224 in rtx_addr_varies_p ()
> #6  0x002312e8 in rtx_addr_varies_p ()
> #7  0x401ee6e4 in __libc_start_main () from /lib/libc.so.6
> #8  0x00016a58 in ?? ()

This stack trace looks wierd at the higher numbers.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


Gmane