Re: `print' does not print

Re: `print' does not print

[Eli Zaretskii]

On 20 Mar 2002, D. Goel wrote:

> If the folks at g.e.bug need more data-points, here's one more.:
> 
> >   % emacs-21.2 -batch -q -no-site-file -l foo
> >   %
> > does not print anything, whereas
> > 
> >   % emacs-19.34  -batch -q -no-site-file -l foo
> > 
> >   foo
> >   %
> > does the expected
> 
>   % emacs-21.1  -batch -q -no-site-file -l foo
>  
>    foo
>    %
> 
> 
> 
> also seems to do the expected for me on tcsh.
> 
> So, is this a problem specifically with 21.2

Unfortunately, I cannot reproduce this, at least not on a tty running on 
Debian.  It works for me, both in Emacs 21.1 and 21.2.  Can you two try 
this in "emacs -nw"?

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[D. Goel]

> Unfortunately, I cannot reproduce this, at least not on a tty running on 
> Debian.  It works for me, both in Emacs 21.1 and 21.2.  Can you two try 
> this in "emacs -nw"?


Again, it works for me on emacs21.1, with or without -nw (results
below).  What is funky is that for *me*, it does not work with
emacs-20.3 (see below).   Ralf, do you really get the exact opposite
of what i get, or did you misword your report? 


on a unix-xterm:
> > > ====================================================
student1:/usr/local/gnu/bin: uname
OSF1
student1:/usr/local/gnu/bin: ./emacs-21.1 -nw -q -batch -no-site-file -l ~/foo

foo
student1:/usr/local/gnu/bin: ./emacs-20.3 -nw -q -batch -no-site-file -l ~/foo
student1:/usr/local/gnu/bin: ./emacs-21.1 -q -batch -no-site-file -l ~/foo

foo
student1:/usr/local/gnu/bin: ./emacs-20.3 -q -batch -no-site-file -l ~/foo
student1:/usr/local/gnu/bin:
student1:/usr/local/gnu/bin: cat ~/foo
(print 'foo)
> > > ====================================================

The exact same results on another unix-machine which returns SunOS for
uname. 


D				   <http://www.glue.umd.edu/~deego>
-- 
One Editor to rule them all, one Editor to C-x C-f them,
One Editor to bring them all and to their keymaps bind them
In the land of Emacs where the Sexprs lie. -- James A. Crippen on g.e.gnus

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* "D. Goel" <deego@glue.umd.edu>
| > Unfortunately, I cannot reproduce this, at least not on a tty
| > running on Debian.  It works for me, both in Emacs 21.1 and 21.2.
| > Can you two try this in "emacs -nw"?

Does not work for me in 21.2 with or without -nw

% emacs-21.2 -nw -q -batch -no-site-file -l ./foo
%

| What is funky is that for *me*, it does not work with emacs-20.3
| (see below).  Ralf, do you really get the exact opposite of what i
| get, or did you misword your report?

I have no emacs 20.x at hand, only the 19.34 (which works) and two
xemacsen (20.4 and 21.4.6, all of which work).  So no, I don't get the
exact opposite, since I haven't any of your emacsen at hand.  Is that
a sufficient answer to your question (not sure whether I understood it
correctly)?

I'm about to compile 21.1 to see whether the problem persists.

R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* eliz@is.elta.co.il (Eli Zaretskii)
| It works for me, both in Emacs 21.1 and 21.2.  Can you two try this
| in "emacs -nw"?

As I said in another message, -nw does not help.

I checked with gdb, and emacs arrives quite fine at the fwrite() in
print.c:334 ( I added the `written' var to get at the fwrite return
value):

      else if (noninteractive)
	{
		size_t written;
=>		written = fwrite (str, 1, len, stdout);
	  noninteractive_need_newline = 1;
	}

But the return value is 0, indicating some I/O problem, errno at that
point is "Bad file number".


I inserted a fprintf right at the start of `main()', and it shows up
while dumping emacs via temacs:
    % gmake
    ...
    LC_ALL=C ./temacs -batch -l loadup dump
    STDOUT hello world
    STDERR hello world
    Loading loadup (source)...
    ...

    % ./temacs
    STDERR hello world
    STDOUT hello world

but when running the dumped emacs, nothing comes out.
    % ./emacs -batch -no-site-file -f kill-emacs
    %

Any idea how to go on?  I do not know much of the technical details of
the dump process.

R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* eliz@is.elta.co.il (Eli Zaretskii)
| It works for me, both in Emacs 21.1 and 21.2.  Can you two try this
| in "emacs -nw"?

Just compiled 21.1, which works.  Exactly the same compilation
environment.

    % cat foo
    (print emacs-version)
    % ./emacs -batch -no-site-file -l ./foo

    "21.1.2"
    %

    % cd ../../emacs-21.2/src
    % cat foo
    (print emacs-version)
    % ./emacs -batch -no-site-file -l ./foo
    % 

R', baffled

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> From: Ralf Fassel <ralfixx@gmx.de>
> Newsgroups: gnu.emacs.bug
> Date: 21 Mar 2002 22:14:53 +0100
> 
> * eliz@is.elta.co.il (Eli Zaretskii)
> | It works for me, both in Emacs 21.1 and 21.2.  Can you two try this
> | in "emacs -nw"?
> 
> Just compiled 21.1, which works.  Exactly the same compilation
> environment.

Can you please step with a debugger through the code of Fprint, and
see what happens there?

Let me know if you need guidance in running Emacs under a debugger.
The file etc/DEBUG has some useful information about that.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| Can you please step with a debugger through the code of Fprint, and
| see what happens there?

Fprint does what it is supposed to do, but the fwrite() calls in there
return 0 (should be 1 at that point) with errno = Bad File number.

I inserted an fprintf() right at the start of main(), and the output
shows up in temacs while dumping emacs, but not in the dumped emacs.

Then I took the BFI approach and compiled emacs with cc (Mips 7.30)
instead of gcc 2.95.3, and it works.  Grmbl.

    % ./src/emacs-cc -batch -no-site-file -l src/foo
    STDOUT hello world
    STDERR hello world

    "21.2.1"

So this does not seem to be a pure emacs problem, but also gcc is
involved.  As I said in another message, compiling 21.1 with gcc
works.

R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 22 Mar 2002 11:41:41 +0100
> From: Ralf Fassel <ralf@akutech.de>
> 
> Fprint does what it is supposed to do, but the fwrite() calls in there
> return 0 (should be 1 at that point) with errno = Bad File number.

That seems to indicate that the standard output handle is somehow
closed.  Could you please see if it is already closed when Emacs
starts, or is closed during the run?

To do that, you could either (a) use some utility, such as truss or
strace, to report system calls issued by Emacs; or (b) invoke fwrite
from GDB at the beginning of the Emacs `main' function (put a
breakpoint in `main' to stop Emacs there), and see what it returns.

> So this does not seem to be a pure emacs problem, but also gcc is
> involved.

Probably the library and the header files, not only the compiler, have
something to do with this.

Thanks for working on this.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| To do that, you could either (a) use some utility, such as truss or
| strace, to report system calls issued by Emacs;

This is `par' on IRIX, which shows close(4) and close(5), but no (!)
write:
   ...
  579mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
  579mS                 : close(5) OK
  580mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
  580mS                 : close(5) OK
  582mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
  582mS                 : close(5) OK
finish

If I compile print.c alone with cc, and all the rest with gcc, I see
  ...
  575mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
  575mS                 : close(5) OK
  576mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
  576mS                 : close(5) OK
  578mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
  581mS                 : close(5) OK
  587mS                 : write(1, "\n", 1) = 1
  603mS                 : write(1, ""21.2.3"\n", 9) = 9
finish

The CPP-preprocessed print.c shows the `fwrite' call in both cases,
and the code is the same (apart from whitespace diff) after
preprocessing.

| or (b) invoke fwrite from GDB at the beginning of the Emacs `main'
| function (put a breakpoint in `main' to stop Emacs there), and see
| what it returns.

    % gdb ./emacs
    ...
    (gdb) br main
    Breakpoint 3 at 0x10162410: file emacs.c, line 708.
    (gdb) br print.c:333
    Breakpoint 4 at 0x1024c220: file print.c, line 333.
    (gdb) run -batch -no-site-file -l ../foo

    Breakpoint 3, main (argc=0, argv=0x0, envp=0x0) at emacs.c:708
    708	{
    (gdb) call printf("hello\n")
    hello
    $1 = 6
    (gdb) call fwrite("hello\n",6,1,(&__iob[1]))
    hello
    $2 = 1
    (gdb) c
Both of these seem to work when called via gdb.

    Breakpoint 4, printchar (ch=10, fun=273132596) at print.c:333
    333		  fwrite (str, 1, len, stdout);
    (gdb) call fwrite (str, 1, len,(&__iob[1]) )

    $3 = 1
Seems to have worked, newline is printed.
    (gdb) p str
    $4 = "\n\000\000"
    (gdb) n
    334		  noninteractive_need_newline = 1;
Nothing is printed in this step.

    (gdb) c

    Breakpoint 4, printchar (ch=34, fun=273132596) at print.c:333
    333		  fwrite (str, 1, len, stdout);
    (gdb) p str
    $5 = "\"\000\002\""
    (gdb) call fwrite (str, 1, len,(&__iob[1]) )
    $6 = 1
Nothing is printed yet due to line buffering on stdout, see below.
    (gdb) n
    334		  noninteractive_need_newline = 1;
    (gdb) disable 4
    (gdb) c
    "
This is the quote from further abvove, fflushed on exit, but nothing
else is printed.
    Program exited normally.
    (gdb) 

So the calls via gdb seem to work, while the calls from emacs itself
don't.  I do not understand this at all.

R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 22 Mar 2002 15:22:25 +0100
> From: Ralf Fassel <ralfixx@gmx.de>
> 
> This is `par' on IRIX, which shows close(4) and close(5), but no (!)
> write:

This gets stranger and stranger...

> If I compile print.c alone with cc, and all the rest with gcc, I see
>   ...
>   575mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
>   575mS                 : close(5) OK
>   576mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
>   576mS                 : close(5) OK
>   578mS                 : open("/disk4/tmp/ralf/Software/emacs-21.2/foo", O_RDONLY, 0) = 5
>   581mS                 : close(5) OK
>   587mS                 : write(1, "\n", 1) = 1
>   603mS                 : write(1, ""21.2.3"\n", 9) = 9
> finish
> 
> The CPP-preprocessed print.c shows the `fwrite' call in both cases,

How about disassembly of printchar?  Does it show the call to fwrite
in both cases?

> So the calls via gdb seem to work, while the calls from emacs itself
> don't.  I do not understand this at all.

Very strange, indeed...

What happens if you replace `fwrite' with `fflush' followed by
`write'?  Does that change anything?

Another idea is to put a breakpoint inside fwrite, and see if it's
called at all.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| This gets stranger and stranger...

Indeed :-/

| How about disassembly of printchar?  Does it show the call to fwrite
| in both cases?

You mean the assembler code output as of gcc -S ... print.c?  Yes, it
does show a call to fwrite, although in different syntax for gcc and
cc (which doesn't surprise me).

------------------------------
gcc
    .L22:
    .LM36:

	    lw	$2,noninteractive
	    beq	$2,$0,.L25
    .LM37:

	    addu	$2,$fp,24
	    move	$4,$2
	    li	$5,1			# 0x1
	    lw	$6,32($fp)
	    lw	$7,.LC0
	    la	$25,fwrite
	    jal	$31,$25
    .LM38:

	    li	$2,1			# 0x1
	    sw	$2,noninteractive_need_newline
    .LM39:
------------------------------
cc:
    .BB25.printchar:	# 0x2c8
	    .loc	1 333 4
     # 332  	{
     # 333  	  fwrite (str, 1, len, stdout);
	    addiu $4,$sp,0                	#  str
	    addiu $5,$0,1                 	#  
	    lw $6,4($sp)                  	#  len
	    lw $7,%got_disp(__iob)($gp)   	#  __iob
	    addiu $7,$7,16                	#  
	    lw $25,%call16(fwrite)($gp)   	#  fwrite
	    jalr $25                      	#  fwrite
	    nop                           	#  
    .BB26.printchar:	# 0x2e8
	    .loc	1 334 4
     # 334  	  noninteractive_need_newline = 1;
	    addiu $8,$0,1                 	#  
-------------------------

| What happens if you replace `fwrite' with `fflush' followed by
| `write'?  Does that change anything?

Errr, yes, it does.  If I apply the following diff:
*** print.c~	Wed Aug  1 10:27:38 2001
--- print.c	Fri Mar 22 18:35:49 2002
***************
*** 330,336 ****
  	}
        else if (noninteractive)
  	{
! 	  fwrite (str, 1, len, stdout);
  	  noninteractive_need_newline = 1;
  	}
        else
--- 330,339 ----
  	}
        else if (noninteractive)
  	{
! 		fflush(stdout);
! 		write (1, str, len);
! 
! 		/* fwrite (str, 1, len, stdout); */
  	  noninteractive_need_newline = 1;
  	}
        else

I get
    ./emacs -batch -no-site-file -l foo

    "21.2.1"

I.e. it `works'.

If I put at the start of main:
  write(1,"write\n",6);
  fwrite("frwite\n", 7,1,stdout);
I see the `write', but not the fwrite when I compile with gcc.  I see
both when I compile with cc.
    
| Another idea is to put a breakpoint inside fwrite, and see if it's
| called at all.

While gdb accepts the break command, it does not stop in fwrite in
both cases (gcc and cc).  However, cc-compiled prints, gcc-compiled
does not.

cc:
    (gdb) br fwrite
    Breakpoint 4 at 0xfa52f48: file engine.c, line 592.
    (gdb) c

    "21.2.1"

    Program exited normally.

gcc:
    (gdb) br fwrite
    Breakpoint 4 at 0xfa52f48: file engine.c, line 592.
    (gdb) c

    Program exited normally.
    
I don't know whether it makes much sense to dig deeper here.  While
I'm as curious what is the problem here, maybe I just go and fetch the
CVS version and see what happens there.

R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 22 Mar 2002 18:47:20 +0100
> From: Ralf Fassel <ralfixx@gmx.de>
> 
> | How about disassembly of printchar?  Does it show the call to fwrite
> | in both cases?
> 
> You mean the assembler code output as of gcc -S ... print.c?

No, I meant the "disassembly printchar" command typed at GDB's prompt.

> | What happens if you replace `fwrite' with `fflush' followed by
> | `write'?  Does that change anything?
> 
> Errr, yes, it does.

Aha!  So this might be a buffering issue.  Does it help to keep
fwrite, but put fflush right after it?

> I don't know whether it makes much sense to dig deeper here.  While
> I'm as curious what is the problem here, maybe I just go and fetch the
> CVS version and see what happens there.

If you can try the CVS version, please do.  I don't think this
problem has anything to do with Emacs versions, though.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| No, I meant the "disassembly printchar" command typed at GDB's
| prompt.

There is something new to learn each day.  Those who know will be able
to make sense of this (appended at the end).  I can't see fwrite
anywhere in there, but then I donät see *anything* in there :-)

| Aha!  So this might be a buffering issue.  Does it help to keep
| fwrite, but put fflush right after it?

Nope (that was one of the first things I've tried and just check
again).

| If you can try the CVS version, please do.

I'll check that over the weekend, downloading right now.

R'

cc:
(gdb) br fwrite
Breakpoint 5 at 0xfa52f48: file engine.c, line 592.
(gdb) disassemble printchar
Dump of assembler code for function printchar:
0x10245448 <printchar>:	addiu	sp,sp,-64
0x1024544c <printchar+4>:	sd	ra,16(sp)
0x10245450 <printchar+8>:	sw	a0,52(sp)
0x10245454 <printchar+12>:	sw	a1,60(sp)
0x10245458 <printchar+16>:	lw	at,-15748(gp)
0x1024545c <printchar+20>:	lw	at,0(at)
0x10245460 <printchar+24>:	lw	v0,60(sp)
0x10245464 <printchar+28>:	beq	at,v0,0x102454a8 <printchar+96>
0x10245468 <printchar+32>:	nop
0x1024546c <printchar+36>:	lw	v0,-15744(gp)
0x10245470 <printchar+40>:	lw	v0,0(v0)
0x10245474 <printchar+44>:	lw	v1,60(sp)
0x10245478 <printchar+48>:	beq	v0,v1,0x102454a8 <printchar+96>
0x1024547c <printchar+52>:	nop
0x10245480 <printchar+56>:	lw	a0,60(sp)
0x10245484 <printchar+60>:	lw	a1,52(sp)
0x10245488 <printchar+64>:	lui	a2,0xfff
0x1024548c <printchar+68>:	ori	a2,a2,0xffff
0x10245490 <printchar+72>:	and	a1,a1,a2
0x10245494 <printchar+76>:	lw	t9,-26324(gp)
0x10245498 <printchar+80>:	jal	0x102287c8 <call1>
0x1024549c <printchar+84>:	nop
0x102454a0 <printchar+88>:	b	0x10245718 <printchar+720>
0x102454a4 <printchar+92>:	nop
0x102454a8 <printchar+96>:	lw	a3,52(sp)
0x102454ac <printchar+100>:	sltiu	a3,a3,256
0x102454b0 <printchar+104>:	beqz	a3,0x10245524 <printchar+220>
0x102454b4 <printchar+108>:	nop
0x102454b8 <printchar+112>:	lw	t0,52(sp)
0x102454bc <printchar+116>:	sltiu	t0,t0,128
0x102454c0 <printchar+120>:	bnez	t0,0x102454d8 <printchar+144>
0x102454c4 <printchar+124>:	nop
0x102454c8 <printchar+128>:	lw	t1,52(sp)
0x102454cc <printchar+132>:	sltiu	t1,t1,160
0x102454d0 <printchar+136>:	bnez	t1,0x102454f0 <printchar+168>
0x102454d4 <printchar+140>:	nop
0x102454d8 <printchar+144>:	lw	t3,52(sp)
0x102454dc <printchar+148>:	sb	t3,0(sp)
0x102454e0 <printchar+152>:	li	t2,1
0x102454e4 <printchar+156>:	sd	t2,24(sp)
0x102454e8 <printchar+160>:	b	0x10245514 <printchar+204>
0x102454ec <printchar+164>:	nop
0x102454f0 <printchar+168>:	li	t6,158
0x102454f4 <printchar+172>:	sb	t6,0(sp)
0x102454f8 <printchar+176>:	lw	t5,52(sp)
0x102454fc <printchar+180>:	addiu	t5,t5,32
0x10245500 <printchar+184>:	andi	t5,t5,0xff
0x10245504 <printchar+188>:	sd	t5,32(sp)
0x10245508 <printchar+192>:	sb	t5,1(sp)
0x1024550c <printchar+196>:	li	t4,2
0x10245510 <printchar+200>:	sd	t4,24(sp)
0x10245514 <printchar+204>:	ld	t7,24(sp)
0x10245518 <printchar+208>:	sd	t7,40(sp)
0x1024551c <printchar+212>:	b	0x10245540 <printchar+248>
0x10245520 <printchar+216>:	nop
0x10245524 <printchar+220>:	lw	a0,52(sp)
0x10245528 <printchar+224>:	addiu	a1,sp,0
0x1024552c <printchar+228>:	lw	t9,-29916(gp)
0x10245530 <printchar+232>:	jal	0x100ac108 <char_to_string>
0x10245534 <printchar+236>:	nop
0x10245538 <printchar+240>:	move	t8,v0
0x1024553c <printchar+244>:	sd	t8,40(sp)
0x10245540 <printchar+248>:	ld	t9,40(sp)
0x10245544 <printchar+252>:	sw	t9,4(sp)
0x10245548 <printchar+256>:	lw	ra,-15748(gp)
0x1024554c <printchar+260>:	lw	ra,0(ra)
0x10245550 <printchar+264>:	lw	at,-15356(gp)
0x10245554 <printchar+268>:	lw	at,0(at)
0x10245558 <printchar+272>:	beq	ra,at,0x102455a4 <printchar+348>
0x1024555c <printchar+276>:	nop
0x10245560 <printchar+280>:	lw	at,-15748(gp)
0x10245564 <printchar+284>:	lw	at,0(at)
0x10245568 <printchar+288>:	lw	v0,-15360(gp)
0x1024556c <printchar+292>:	lw	v0,0(v0)
0x10245570 <printchar+296>:	bne	at,v0,0x102455a4 <printchar+348>
0x10245574 <printchar+300>:	nop
0x10245578 <printchar+304>:	lw	a1,-15748(gp)
0x1024557c <printchar+308>:	lw	a1,0(a1)
0x10245580 <printchar+312>:	lw	a2,-15356(gp)
0x10245584 <printchar+316>:	sw	a1,0(a2)
0x10245588 <printchar+320>:	lw	a0,-15708(gp)
0x1024558c <printchar+324>:	lw	a0,0(a0)
0x10245590 <printchar+328>:	lw	a1,-15748(gp)
0x10245594 <printchar+332>:	lw	a1,0(a1)
0x10245598 <printchar+336>:	lw	t9,-26380(gp)
0x1024559c <printchar+340>:	jal	0x10225250 <Fsignal>
0x102455a0 <printchar+344>:	nop
0x102455a4 <printchar+348>:	nop
0x102455a8 <printchar+352>:	lw	a2,-15748(gp)
0x102455ac <printchar+356>:	lw	a2,0(a2)
0x102455b0 <printchar+360>:	lw	a3,60(sp)
0x102455b4 <printchar+364>:	bne	a2,a3,0x10245678 <printchar+560>
0x102455b8 <printchar+368>:	nop
0x102455bc <printchar+372>:	lw	t0,-15120(gp)
0x102455c0 <printchar+376>:	lw	t0,0(t0)
0x102455c4 <printchar+380>:	lw	a3,-15112(gp)
0x102455c8 <printchar+384>:	lw	a3,0(a3)
0x102455cc <printchar+388>:	lw	t1,4(sp)
0x102455d0 <printchar+392>:	addu	a3,a3,t1
0x102455d4 <printchar+396>:	slt	a3,a3,t0
0x102455d8 <printchar+400>:	bnez	a3,0x1024561c <printchar+468>
0x102455dc <printchar+404>:	nop
0x102455e0 <printchar+408>:	lw	a1,-15120(gp)
0x102455e4 <printchar+412>:	lw	a1,0(a1)
0x102455e8 <printchar+416>:	addu	a1,a1,a1
0x102455ec <printchar+420>:	lw	a2,-15120(gp)
0x102455f0 <printchar+424>:	sw	a1,0(a2)
0x102455f4 <printchar+428>:	lw	a0,-15124(gp)
0x102455f8 <printchar+432>:	lw	a0,0(a0)
0x102455fc <printchar+436>:	lw	a1,-15120(gp)
0x10245600 <printchar+440>:	lw	a1,0(a1)
0x10245604 <printchar+444>:	lw	t9,-27156(gp)
0x10245608 <printchar+448>:	jal	0x101f8088 <xrealloc>
0x1024560c <printchar+452>:	nop
0x10245610 <printchar+456>:	sd	v0,32(sp)
0x10245614 <printchar+460>:	lw	a2,-15124(gp)
0x10245618 <printchar+464>:	sw	v0,0(a2)
0x1024561c <printchar+468>:	addiu	a0,sp,0
0x10245620 <printchar+472>:	lw	a1,-15112(gp)
0x10245624 <printchar+476>:	lw	a1,0(a1)
0x10245628 <printchar+480>:	lw	a2,-15124(gp)
0x1024562c <printchar+484>:	lw	a2,0(a2)
0x10245630 <printchar+488>:	addu	a1,a1,a2
0x10245634 <printchar+492>:	lw	a2,4(sp)
0x10245638 <printchar+496>:	lw	t9,-32328(gp)
0x1024563c <printchar+500>:	jalr	t9
0x10245640 <printchar+504>:	nop
0x10245644 <printchar+508>:	lw	a3,-15116(gp)
0x10245648 <printchar+512>:	lw	a3,0(a3)
0x1024564c <printchar+516>:	addiu	a3,a3,1
0x10245650 <printchar+520>:	lw	t0,-15116(gp)
0x10245654 <printchar+524>:	sw	a3,0(t0)
0x10245658 <printchar+528>:	lw	a2,-15112(gp)
0x1024565c <printchar+532>:	lw	a2,0(a2)
0x10245660 <printchar+536>:	lw	a3,4(sp)
0x10245664 <printchar+540>:	addu	a2,a2,a3
0x10245668 <printchar+544>:	lw	a3,-15112(gp)
0x1024566c <printchar+548>:	sw	a2,0(a3)
0x10245670 <printchar+552>:	b	0x10245718 <printchar+720>
0x10245674 <printchar+556>:	nop
0x10245678 <printchar+560>:	lw	t0,-17400(gp)
0x1024567c <printchar+564>:	lw	t0,0(t0)
0x10245680 <printchar+568>:	beqz	t0,0x102456bc <printchar+628>
0x10245684 <printchar+572>:	nop
0x10245688 <printchar+576>:	addiu	a0,sp,0
0x1024568c <printchar+580>:	li	a1,1
0x10245690 <printchar+584>:	lw	a2,4(sp)
0x10245694 <printchar+588>:	lw	a3,-32464(gp)
0x10245698 <printchar+592>:	addiu	a3,a3,16
0x1024569c <printchar+596>:	lw	t9,-32304(gp)
0x102456a0 <printchar+600>:	jalr	t9
0x102456a4 <printchar+604>:	nop
0x102456a8 <printchar+608>:	li	t0,1
0x102456ac <printchar+612>:	lw	t1,-19500(gp)
0x102456b0 <printchar+616>:	sw	t0,0(t1)
0x102456b4 <printchar+620>:	b	0x10245718 <printchar+720>
0x102456b8 <printchar+624>:	nop
0x102456bc <printchar+628>:	lw	t2,-15748(gp)
0x102456c0 <printchar+632>:	lw	t2,0(t2)
0x102456c4 <printchar+636>:	lw	t3,-16608(gp)
0x102456c8 <printchar+640>:	lw	t3,0(t3)
0x102456cc <printchar+644>:	lw	t3,348(t3)
0x102456d0 <printchar+648>:	xor	t2,t2,t3
0x102456d4 <printchar+652>:	sltu	t2,zero,t2
0x102456d8 <printchar+656>:	sw	t2,8(sp)
0x102456dc <printchar+660>:	lw	a0,8(sp)
0x102456e0 <printchar+664>:	lw	t9,-30296(gp)
0x102456e4 <printchar+668>:	jal	0x10075f38 <setup_echo_area_for_printing>
0x102456e8 <printchar+672>:	nop
0x102456ec <printchar+676>:	lw	a0,52(sp)
0x102456f0 <printchar+680>:	lw	t9,-27884(gp)
0x102456f4 <printchar+684>:	jal	0x101a4030 <insert_char>
0x102456f8 <printchar+688>:	nop
0x102456fc <printchar+692>:	addiu	a0,sp,0
0x10245700 <printchar+696>:	lw	a1,4(sp)
0x10245704 <printchar+700>:	move	a2,zero
0x10245708 <printchar+704>:	lw	a3,8(sp)
0x1024570c <printchar+708>:	lw	t9,-30336(gp)
0x10245710 <printchar+712>:	jal	0x10073250 <message_dolog>
0x10245714 <printchar+716>:	nop
0x10245718 <printchar+720>:	ld	ra,16(sp)
0x1024571c <printchar+724>:	addiu	sp,sp,64
0x10245720 <printchar+728>:	jr	ra
0x10245724 <printchar+732>:	nop
End of assembler dump.
(gdb)

gcc:
(gdb) br fwrite
Breakpoint 2 at 0xfa52f48: file engine.c, line 592.
(gdb) disassemble printchar
Dump of assembler code for function printchar:
0x1024bfc0 <printchar>:	addiu	sp,sp,-80
0x1024bfc4 <printchar+4>:	sd	ra,72(sp)
0x1024bfc8 <printchar+8>:	sd	s8,64(sp)
0x1024bfcc <printchar+12>:	sd	gp,56(sp)
0x1024bfd0 <printchar+16>:	sd	s0,48(sp)
0x1024bfd4 <printchar+20>:	move	s8,sp
0x1024bfd8 <printchar+24>:	lui	at,0x1f
0x1024bfdc <printchar+28>:	addiu	at,at,4248
0x1024bfe0 <printchar+32>:	daddu	gp,at,t9
0x1024bfe4 <printchar+36>:	sw	a0,16(s8)
0x1024bfe8 <printchar+40>:	sw	a1,20(s8)
0x1024bfec <printchar+44>:	lw	v0,20(s8)
0x1024bff0 <printchar+48>:	lw	v1,-19432(gp)
0x1024bff4 <printchar+52>:	lw	v1,0(v1)
0x1024bff8 <printchar+56>:	beq	v0,v1,0x1024c040 <printchar+128>
0x1024bffc <printchar+60>:	nop
0x1024c000 <printchar+64>:	lw	v0,20(s8)
0x1024c004 <printchar+68>:	lw	v1,-19372(gp)
0x1024c008 <printchar+72>:	lw	v1,0(v1)
0x1024c00c <printchar+76>:	beq	v0,v1,0x1024c040 <printchar+128>
0x1024c010 <printchar+80>:	nop
0x1024c014 <printchar+84>:	lw	v0,16(s8)
0x1024c018 <printchar+88>:	lui	v1,0xfff
0x1024c01c <printchar+92>:	ori	v1,v1,0xffff
0x1024c020 <printchar+96>:	and	v0,v0,v1
0x1024c024 <printchar+100>:	lw	a0,20(s8)
0x1024c028 <printchar+104>:	move	a1,v0
0x1024c02c <printchar+108>:	lw	t9,-26244(gp)
0x1024c030 <printchar+112>:	jalr	t9
0x1024c034 <printchar+116>:	nop
0x1024c038 <printchar+120>:	b	0x1024c2bc <printchar+764>
0x1024c03c <printchar+124>:	nop
0x1024c040 <printchar+128>:	lw	v0,16(s8)
0x1024c044 <printchar+132>:	sltiu	v1,v0,256
0x1024c048 <printchar+136>:	beqz	v1,0x1024c0ac <printchar+236>
0x1024c04c <printchar+140>:	nop
0x1024c050 <printchar+144>:	lw	v0,16(s8)
0x1024c054 <printchar+148>:	sltiu	v1,v0,128
0x1024c058 <printchar+152>:	bnez	v1,0x1024c078 <printchar+184>
0x1024c05c <printchar+156>:	nop
0x1024c060 <printchar+160>:	lw	v0,16(s8)
0x1024c064 <printchar+164>:	sltiu	v1,v0,160
0x1024c068 <printchar+168>:	beqz	v1,0x1024c078 <printchar+184>
0x1024c06c <printchar+172>:	nop
0x1024c070 <printchar+176>:	b	0x1024c08c <printchar+204>
0x1024c074 <printchar+180>:	nop
0x1024c078 <printchar+184>:	lbu	v0,19(s8)
0x1024c07c <printchar+188>:	sb	v0,24(s8)
0x1024c080 <printchar+192>:	li	s0,1
0x1024c084 <printchar+196>:	b	0x1024c0a4 <printchar+228>
0x1024c088 <printchar+200>:	nop
0x1024c08c <printchar+204>:	li	v0,158
0x1024c090 <printchar+208>:	sb	v0,24(s8)
0x1024c094 <printchar+212>:	lbu	v0,19(s8)
0x1024c098 <printchar+216>:	addiu	v1,v0,32
0x1024c09c <printchar+220>:	sb	v1,25(s8)
0x1024c0a0 <printchar+224>:	li	s0,2
0x1024c0a4 <printchar+228>:	b	0x1024c0c8 <printchar+264>
0x1024c0a8 <printchar+232>:	nop
0x1024c0ac <printchar+236>:	addiu	v0,s8,24
0x1024c0b0 <printchar+240>:	lw	a0,16(s8)
0x1024c0b4 <printchar+244>:	move	a1,v0
0x1024c0b8 <printchar+248>:	lw	t9,-29832(gp)
0x1024c0bc <printchar+252>:	jalr	t9
0x1024c0c0 <printchar+256>:	nop
0x1024c0c4 <printchar+260>:	move	s0,v0
0x1024c0c8 <printchar+264>:	sw	s0,32(s8)
0x1024c0cc <printchar+268>:	lw	v0,-18072(gp)
0x1024c0d0 <printchar+272>:	lw	v0,0(v0)
0x1024c0d4 <printchar+276>:	lw	v1,-19432(gp)
0x1024c0d8 <printchar+280>:	lw	v1,0(v1)
0x1024c0dc <printchar+284>:	beq	v0,v1,0x1024c128 <printchar+360>
0x1024c0e0 <printchar+288>:	nop
0x1024c0e4 <printchar+292>:	lw	v0,-18084(gp)
0x1024c0e8 <printchar+296>:	lw	v0,0(v0)
0x1024c0ec <printchar+300>:	lw	v1,-19432(gp)
0x1024c0f0 <printchar+304>:	lw	v1,0(v1)
0x1024c0f4 <printchar+308>:	bne	v0,v1,0x1024c128 <printchar+360>
0x1024c0f8 <printchar+312>:	nop
0x1024c0fc <printchar+316>:	lw	v0,-19432(gp)
0x1024c100 <printchar+320>:	lw	v0,0(v0)
0x1024c104 <printchar+324>:	lw	at,-18072(gp)
0x1024c108 <printchar+328>:	sw	v0,0(at)
0x1024c10c <printchar+332>:	lw	a0,-18068(gp)
0x1024c110 <printchar+336>:	lw	a0,0(a0)
0x1024c114 <printchar+340>:	lw	a1,-19432(gp)
0x1024c118 <printchar+344>:	lw	a1,0(a1)
0x1024c11c <printchar+348>:	lw	t9,-26300(gp)
0x1024c120 <printchar+352>:	jalr	t9
0x1024c124 <printchar+356>:	nop
0x1024c128 <printchar+360>:	b	0x1024c138 <printchar+376>
0x1024c12c <printchar+364>:	nop
0x1024c130 <printchar+368>:	b	0x1024c0cc <printchar+268>
0x1024c134 <printchar+372>:	nop
0x1024c138 <printchar+376>:	lw	v0,20(s8)
0x1024c13c <printchar+380>:	lw	v1,-19432(gp)
0x1024c140 <printchar+384>:	lw	v1,0(v1)
0x1024c144 <printchar+388>:	bne	v0,v1,0x1024c210 <printchar+592>
0x1024c148 <printchar+392>:	nop
0x1024c14c <printchar+396>:	lw	v0,-14792(gp)
0x1024c150 <printchar+400>:	lw	v0,0(v0)
0x1024c154 <printchar+404>:	lw	v1,32(s8)
0x1024c158 <printchar+408>:	addu	v0,v0,v1
0x1024c15c <printchar+412>:	lw	v1,-14824(gp)
0x1024c160 <printchar+416>:	lw	v1,0(v1)
0x1024c164 <printchar+420>:	slt	v0,v0,v1
0x1024c168 <printchar+424>:	bnez	v0,0x1024c1ac <printchar+492>
0x1024c16c <printchar+428>:	nop
0x1024c170 <printchar+432>:	lw	v0,-14824(gp)
0x1024c174 <printchar+436>:	lw	v0,0(v0)
0x1024c178 <printchar+440>:	move	v1,v0
0x1024c17c <printchar+444>:	sll	a0,v1,0x1
0x1024c180 <printchar+448>:	move	v0,a0
0x1024c184 <printchar+452>:	lw	at,-14824(gp)
0x1024c188 <printchar+456>:	sw	v0,0(at)
0x1024c18c <printchar+460>:	lw	a0,-14744(gp)
0x1024c190 <printchar+464>:	lw	a0,0(a0)
0x1024c194 <printchar+468>:	move	a1,v0
0x1024c198 <printchar+472>:	lw	t9,-27076(gp)
0x1024c19c <printchar+476>:	jalr	t9
0x1024c1a0 <printchar+480>:	nop
0x1024c1a4 <printchar+484>:	lw	at,-14744(gp)
0x1024c1a8 <printchar+488>:	sw	v0,0(at)
0x1024c1ac <printchar+492>:	addiu	v0,s8,24
0x1024c1b0 <printchar+496>:	lw	v1,-14744(gp)
0x1024c1b4 <printchar+500>:	lw	v1,0(v1)
0x1024c1b8 <printchar+504>:	lw	a0,-14792(gp)
0x1024c1bc <printchar+508>:	lw	a0,0(a0)
0x1024c1c0 <printchar+512>:	addu	v1,v1,a0
0x1024c1c4 <printchar+516>:	move	a0,v0
0x1024c1c8 <printchar+520>:	move	a1,v1
0x1024c1cc <printchar+524>:	lw	a2,32(s8)
0x1024c1d0 <printchar+528>:	lw	t9,-31396(gp)
0x1024c1d4 <printchar+532>:	jalr	t9
0x1024c1d8 <printchar+536>:	nop
0x1024c1dc <printchar+540>:	lw	v0,-14764(gp)
0x1024c1e0 <printchar+544>:	lw	v0,0(v0)
0x1024c1e4 <printchar+548>:	addiu	v1,v0,1
0x1024c1e8 <printchar+552>:	lw	at,-14764(gp)
0x1024c1ec <printchar+556>:	sw	v1,0(at)
0x1024c1f0 <printchar+560>:	lw	v0,-14792(gp)
0x1024c1f4 <printchar+564>:	lw	v0,0(v0)
0x1024c1f8 <printchar+568>:	lw	v1,32(s8)
0x1024c1fc <printchar+572>:	addu	v0,v0,v1
0x1024c200 <printchar+576>:	lw	at,-14792(gp)
0x1024c204 <printchar+580>:	sw	v0,0(at)
0x1024c208 <printchar+584>:	b	0x1024c2bc <printchar+764>
0x1024c20c <printchar+588>:	nop
0x1024c210 <printchar+592>:	lw	v0,-19604(gp)
0x1024c214 <printchar+596>:	lw	v0,0(v0)
0x1024c218 <printchar+600>:	beqz	v0,0x1024c25c <printchar+668>
0x1024c21c <printchar+604>:	nop
0x1024c220 <printchar+608>:	addiu	v0,s8,24
0x1024c224 <printchar+612>:	move	a0,v0
0x1024c228 <printchar+616>:	li	a1,1
0x1024c22c <printchar+620>:	lw	a2,32(s8)
0x1024c230 <printchar+624>:	lw	a3,-32524(gp)
0x1024c234 <printchar+628>:	daddiu	a3,a3,-9628
0x1024c238 <printchar+632>:	lw	a3,0(a3)
0x1024c23c <printchar+636>:	lw	t9,-31192(gp)
0x1024c240 <printchar+640>:	jalr	t9
0x1024c244 <printchar+644>:	nop
0x1024c248 <printchar+648>:	li	v0,1
0x1024c24c <printchar+652>:	lw	at,-18852(gp)
0x1024c250 <printchar+656>:	sw	v0,0(at)
0x1024c254 <printchar+660>:	b	0x1024c2bc <printchar+764>
0x1024c258 <printchar+664>:	nop
0x1024c25c <printchar+668>:	lw	v0,-19456(gp)
0x1024c260 <printchar+672>:	lw	v0,0(v0)
0x1024c264 <printchar+676>:	lw	v1,348(v0)
0x1024c268 <printchar+680>:	lw	v0,-19432(gp)
0x1024c26c <printchar+684>:	lw	v0,0(v0)
0x1024c270 <printchar+688>:	xor	v1,v1,v0
0x1024c274 <printchar+692>:	sltu	v0,zero,v1
0x1024c278 <printchar+696>:	sw	v0,36(s8)
0x1024c27c <printchar+700>:	lw	a0,36(s8)
0x1024c280 <printchar+704>:	lw	t9,-30212(gp)
0x1024c284 <printchar+708>:	jalr	t9
0x1024c288 <printchar+712>:	nop
0x1024c28c <printchar+716>:	lw	a0,16(s8)
0x1024c290 <printchar+720>:	lw	t9,-27804(gp)
0x1024c294 <printchar+724>:	jalr	t9
0x1024c298 <printchar+728>:	nop
0x1024c29c <printchar+732>:	addiu	v0,s8,24
0x1024c2a0 <printchar+736>:	move	a0,v0
0x1024c2a4 <printchar+740>:	lw	a1,32(s8)
0x1024c2a8 <printchar+744>:	move	a2,zero
0x1024c2ac <printchar+748>:	lw	a3,36(s8)
0x1024c2b0 <printchar+752>:	lw	t9,-30252(gp)
0x1024c2b4 <printchar+756>:	jalr	t9
0x1024c2b8 <printchar+760>:	nop
0x1024c2bc <printchar+764>:	move	sp,s8
0x1024c2c0 <printchar+768>:	ld	ra,72(sp)
0x1024c2c4 <printchar+772>:	ld	s8,64(sp)
0x1024c2c8 <printchar+776>:	ld	gp,56(sp)
0x1024c2cc <printchar+780>:	ld	s0,48(sp)
0x1024c2d0 <printchar+784>:	addiu	sp,sp,80
0x1024c2d4 <printchar+788>:	jr	ra
0x1024c2d8 <printchar+792>:	nop
End of assembler dump.
(gdb)

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 22 Mar 2002 20:17:01 +0100
> From: Ralf Fassel <ralfixx@gmx.de>
> 
> | Aha!  So this might be a buffering issue.  Does it help to keep
> | fwrite, but put fflush right after it?
> 
> Nope

Hmmm... what about the stdout FILE object--can you look at its
members and see if something's wrong with it at that point?

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| Hmmm... what about the stdout FILE object--can you look at its
| members and see if something's wrong with it at that point?

gcc:
    Breakpoint 3, printchar (ch=10, fun=273132596) at print.c:333
    333		  fwrite (str, 1, len, stdout);
    (gdb) p __iob[1]
    $1 = {
      _cnt = 0, 
      _ptr = 0x0, 
      _base = 0x0, 
      _flag = 2 '\002', 
      _o_file = 1 '\001', 
      _file = 1
    }
    (gdb) next
    334		  noninteractive_need_newline = 1;
    (gdb) p __iob[1]
    $2 = {
      _cnt = 0, 
      _ptr = 0x0, 
      _base = 0x0, 
      _flag = 2 '\002', 
      _o_file = 1 '\001', 
      _file = 1
    }
unchanged.


cc:
    Breakpoint 4, printchar (ch=10, fun=272911412) at print.c:333
    333		  fwrite (str, 1, len, stdout);
    (gdb) p __iob[1]
    $6 = {
      _cnt = 0, 
      _ptr = 0x0, 
      _base = 0x0, 
      _flag = 2 '\002', 
      _o_file = 1 '\001', 
      _file = 1
    }
    (gdb) next
    334		  noninteractive_need_newline = 1;
    (gdb) p __iob[1]
    $7 = {
      _cnt = 0, 
      _ptr = 0x10389f20 "\n", 
      _base = 0x10389f20 "\n", 
      _flag = 66 'B', 
      _o_file = 1 '\001', 
      _file = 1
    }
filled.


So there _is_ a difference: cc fills the struct, gcc doesn't.

Here is what happens if I `step' into fwrite:
I see with
gcc:

    fwrite () at engine.c:601
    _wrtchk () at exportent.c:396
!   setoserror () at aio.c:314
    _wrtchk () at exportent.c:383
    383	exportent.c: No such file or directory.
    fwrite () at engine.c:554
    printchar (ch=34, fun=273132596) at print.c:334

==========================================================
cc:
    fwrite () at engine.c:601
    _wrtchk () at exportent.c:396
!   _findbuf () at aio.c:397
    ctlslave () at aio.c:549
    isatty () at aio.c:200
    ioctl () at mpconf.c:160
    Program received signal SIGTRAP, Trace/breakpoint trap.

and I always get that SIGTRAP which restarts the fwrite again, but the
difference at ! is obvious.

BTW, the bootstrap-emacs in the CVS tree shows the same symptoms as
21.2, no printing.  gmake has not yet finished completely (compiling
.elc files currently), but I don't expect it to behave differently in
the end :-(

Bedtime now.
R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 22 Mar 2002 23:18:44 +0100
> From: Ralf Fassel <ralf@akutech.de>
> 
> So there _is_ a difference: cc fills the struct, gcc doesn't.

Yes.  The important part in the difference is that with cc, a new
buffer is allocated to hold the buffered characters, while in the gcc
build, _base stays at 0x0, i.e. the buffer wasn't allocated.  (It is
normal for buffered I/O routines to start with the buffer of teh FILE
object unallocated, and only allocate it the first time any operation
is requested for that FILE object.)

> gcc:
> 
>     fwrite () at engine.c:601
>     _wrtchk () at exportent.c:396
> !   setoserror () at aio.c:314
>     _wrtchk () at exportent.c:383
>     383	exportent.c: No such file or directory.
>     fwrite () at engine.c:554
>     printchar (ch=34, fun=273132596) at print.c:334

setoserror means there's some kind of error where it should have
allocated the buffer (that's the _findbuf call in the cc build, I
guess).  Can you zero out errno before the call to fwrite, and see if
it gets any value after fwrite returns?

>     Program received signal SIGTRAP, Trace/breakpoint trap.
> 
> and I always get that SIGTRAP which restarts the fwrite again, but the
> difference at ! is obvious.

Probably a bug in GDB (SIGTRAP means that a breakpoint fired, but GDB
didn't think there was a breakpoint at that place in the program).

Anyway, this is a point where I'd strongly suggest compiling the
library routines with enough debug info to be able to step through
the library code and see what's wrong with Emacs.  I guess in your
case it's hard, since the library is proprietary, but the other
report about the same behavior was for GNU/Linux, where we have
glibc.  Can someone please step through the glibc code in this case
and see what's going on?

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| Can you zero out errno before the call to fwrite, and see if it gets
| any value after fwrite returns?

Errno is 2 (ENOENT) before and 9 after the fwrite call.

| Anyway, this is a point where I'd strongly suggest compiling the
| library routines with enough debug info to be able to step through
| the library code and see what's wrong with Emacs.  I guess in your
| case it's hard, since the library is proprietary,

Yup.  One thing I will check is to attach the dmalloc lib.  Maybe it's
a malloc problem somewhere else, making the fwrite buffer alloc fail
later.

R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Eli Zaretskii]

> Date: Sat, 23 Mar 2002 15:19:44 +0100
> From: Ralf Fassel <ralfixx@gmx.de>
> 
> * Eli Zaretskii
> | Can you zero out errno before the call to fwrite, and see if it gets
> | any value after fwrite returns?
> 
> Errno is 2 (ENOENT) before and 9 after the fwrite call.

9 is EBADF, AFAIK, so it might mean that the file handle is invalid.
But OTOH, you said that invoking fwrite from GDB works correctly, so
I'm confused.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| 9 is EBADF, AFAIK, so it might mean that the file handle is invalid.

Yup, that's correct, errno 9 is EBADF.

| But OTOH, you said that invoking fwrite from GDB works correctly, so
| I'm confused.

    Breakpoint 3, printchar (ch=10, fun=273515572) at print.c:333
    333		  fwrite (str, 1, len, stdout);
    (gdb) p str
    $8 = "\n\000\000"
    (gdb) next
1   334		  noninteractive_need_newline = 1;
    (gdb) call fwrite (str, 1, len, (&__iob[1]))
2
    $9 = 1
    (gdb)

At `1' I would have expected to see the newline printed as a result
from the `next' command , at `2' the newline ist printed as a result
of the gdb `call'.  This is what I referred to as `fwrite works when
called from gdb'.  I can even muck with the str:

    (gdb) set str = "ho\n"
    (gdb) set len = 3
    (gdb) p str
    $29 = "ho\n"
    (gdb) call fwrite (str, 1, len, (&__iob[1]))
    ho
    $30 = 3

I'm trying the CVS gcc version, though this will take some time,
naturally.
    
R'

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Stefan Monnier]

>>>>> "Ralf" == Ralf Fassel <ralfixx@gmx.de> writes:
> If I put at the start of main:
>   write(1,"write\n",6);
>   fwrite("frwite\n", 7,1,stdout);
> I see the `write', but not the fwrite when I compile with gcc.  I see
> both when I compile with cc.

It looks like the problem is that the `stdout' FILE* stuff got wedged.
Could you look at `stdout' ?  Maybe it got mangled during dump ?
Maybe it's an interaction between malloc (or mmap) and dumping (assuming
the `stdout' buffer was allocated with malloc).

Has any part of the dumping or memory management been changed between
21.1 and 21.2 ?


	Stefan

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Richard Stallman]

It would be useful to get the GCC sources from the CVS repository
(cvs.gnu.org) and try compiling with that.  If it still fails, then it
would be useful to identify the function that was miscompiled.  That
way you could help fix a bug in GCC.

    Probably the library and the header files, not only the compiler, have
    something to do with this.

stdio.h is not part of GCC, so the same stdio.h is used
in compiling both Emacs versions, the one that works and the one
that fails.  This doesn't prove for certain that stdio.h is correct,
but does suggest it is not the first place to look.

_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs

Re: `print' does not print

[Ralf Fassel]

* Richard Stallman
| It would be useful to get the GCC sources from the CVS repository
| (cvs.gnu.org) and try compiling with that.

I tried to compile the CVS-gcc (3.2 20020323 (experimental)), but this
fails on my machine, both using gcc-2.95.3 and SGI-cc.  The error is
in a generated source file:

Using gcc:
    ./genemit ../../gcc/config/mips/mips.md > tmp-emit.c
    /bin/sh ../../gcc/move-if-change tmp-emit.c insn-emit.c
    echo timestamp > s-emit
    gcc -DIN_GCC    -g  -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -c insn-emit.c \
      -o insn-emit.o
    insn-emit.c: In function `gen_fixuns_truncdfsi2':
    insn-emit.c:6186: incompatible type for argument 1 of `ereal_ldexp'
    insn-emit.c: In function `gen_fixuns_truncdfdi2':
    insn-emit.c:6247: incompatible type for argument 1 of `ereal_ldexp'
    insn-emit.c: In function `gen_fixuns_truncsfsi2':
    insn-emit.c:6308: incompatible type for argument 1 of `ereal_ldexp'
    insn-emit.c: In function `gen_fixuns_truncsfdi2':
    insn-emit.c:6369: incompatible type for argument 1 of `ereal_ldexp'
    insn-emit.c: In function `gen_indirect_jump':
    insn-emit.c:10411: warning: comparison between signed and unsigned
    insn-emit.c: In function `gen_tablejump':
    insn-emit.c:10458: warning: comparison between signed and unsigned
    gmake[2]: *** [insn-emit.o] Error 1
    gmake[2]: Leaving directory `/disk4/tmp/ralf/Software/gcc-cvs/gcc/IRIX-6/gcc'
    gmake[1]: *** [stage1_build] Error 2
    gmake[1]: Leaving directory `/disk4/tmp/ralf/Software/gcc-cvs/gcc/IRIX-6/gcc'
    gmake: *** [bootstrap] Error 2

Using cc:
    ./genemit ../../gcc/config/mips/mips.md > tmp-emit.c
    /bin/sh ../../gcc/move-if-change tmp-emit.c insn-emit.c
    echo timestamp > s-emit
    cc -DIN_GCC    -g    -DHAVE_CONFIG_H    -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config -I../../gcc/../include -c insn-emit.c \
      -o insn-emit.o
    cc-1164 cc: ERROR File = insn-emit.c, Line = 6186
      Argument of type "double" is incompatible with parameter of type
	      "REAL_VALUE_TYPE".

	REAL_VALUE_TYPE offset = REAL_VALUE_LDEXP (1.0, 31);
				 ^

    cc-1164 cc: ERROR File = insn-emit.c, Line = 6247
      Argument of type "double" is incompatible with parameter of type
	      "REAL_VALUE_TYPE".

	REAL_VALUE_TYPE offset = REAL_VALUE_LDEXP (1.0, 63);
				 ^

    cc-1164 cc: ERROR File = insn-emit.c, Line = 6308
      Argument of type "double" is incompatible with parameter of type
	      "REAL_VALUE_TYPE".

	REAL_VALUE_TYPE offset = REAL_VALUE_LDEXP (1.0, 31);
				 ^

    cc-1164 cc: ERROR File = insn-emit.c, Line = 6369
      Argument of type "double" is incompatible with parameter of type
	      "REAL_VALUE_TYPE".

	REAL_VALUE_TYPE offset = REAL_VALUE_LDEXP (1.0, 63);
				 ^

    4 errors detected in the compilation of "insn-emit.c".
    gmake[2]: *** [insn-emit.o] Error 2
    gmake[2]: Leaving directory `/disk4/tmp/ralf/Software/gcc-cvs/gcc/IRIX-6/gcc'
    gmake[1]: *** [stage1_build] Error 2
    gmake[1]: Leaving directory `/disk4/tmp/ralf/Software/gcc-cvs/gcc/IRIX-6/gcc'
    gmake: *** [bootstrap] Error 2

I can't make much sense of these, since I do not understand the code
in mips/mips.md, but I guess it might be simply some missing header
file.

R'

Re: `print' does not print

[Eli Zaretskii]

> Date: Sun, 24 Mar 2002 17:51:15 +0100
> From: Ralf Fassel <ralfixx@gmx.de>
> 
> I tried to compile the CVS-gcc (3.2 20020323 (experimental)), but this
> fails on my machine, both using gcc-2.95.3 and SGI-cc.

Picking up Stefan's idea, there was one change between v21.1 and 21.2
that could be relevant to this problem: the change in unexelf.c (IIRC,
Emacs uses unexelf.c on SGI, right?).  In Emacs 21.1, unexelf.c used
mmap to read the symbols and sections from temacs, while in Emacs
21.2 it uses file I/O instead.  (This was done because mmap is known
to be unreliable on NFS-mounted volumes.)

Could you see if this change is related to the problem?  For example,
what happens if you use unexelf.c from v21.1 with an otherwise
unmodified Emacs 21.2?

(I don't yet have an explanation why the effect of this change should
be different for GCC and the native compiler, but perhaps we will
understand this later.)

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| Could you see if this change is related to the problem?  For example,
| what happens if you use unexelf.c from v21.1 with an otherwise
| unmodified Emacs 21.2?

Ok, we're getting closer.
- I took a fresh copy of the 21.2 sources, compiled them with gcc -g,
  and confirmed that print does not print.
- then I moved the 21.2 unexelf.c aside, copied the 21.1 version into
  the 21.2 src tree and recompiled: this works: emacs now prints.
- I reinstalled the 21.2 unexelf.c version, recompiled again: no printing.

So it seems the changes in unexelf.c between 21.1 and 21.2 trigger this
problem.

R'

Re: `print' does not print

[Eli Zaretskii]

On Sun, 24 Mar 2002, Ralf Fassel wrote:

> * Eli Zaretskii
> | Could you see if this change is related to the problem?  For example,
> | what happens if you use unexelf.c from v21.1 with an otherwise
> | unmodified Emacs 21.2?
> 
> Ok, we're getting closer.

Yes; the question is how to investigate this further without having 
access to library sources.  Hmm...

Assuming for a moment that the problem is caused by some disruption of 
memory allocation for the standard handles, one thing to try is to use 
setvbuf to allocate a buffer for stdout, somewhere near the beginning of 
`main'.  Does that help?

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| Assuming for a moment that the problem is caused by some disruption
| of memory allocation for the standard handles, one thing to try is
| to use setvbuf to allocate a buffer for stdout, somewhere near the
| beginning of `main'.  Does that help?

The code snipped I tried is:

     if (initialized) {
	  if (setvbuf (stdout, stdout_buffer, _IOLBF, BUFSIZ)) {
		  write(2, "setvbuf failed\n", 15);
		  exit(1);
	  }
	  write (2,"setbuf ok\n",10);
     }

where `stdout_buffer' was a global char[BUFSIZ] in emacs.c (malloc'ing
it didn't make any difference).

Didn't help
- at the start of main in emacs.c, #737 just before calling `sort_args()'
- at the end of main before calling `Frecursive_edit()'
- in `printchar', where I had to trick a bit to invoke it only once at
  first invocation (reset a static init-var in main to 0, since that
  init-var was already initialized in the dumped emacs)
- any variation of
    _IOFBF  causes input/output to be fully buffered.
     _IOLBF  causes output to be line buffered; the buffer will be flushed
             when a newline is written, the buffer is full, or input is
             requested.
     _IONBF  causes input/output to be completely unbuffered.
  for the buffering.

It also tried to use unbuffered I/O via setbuf() with a NULL pointer,
didn't help either.

It also did not help to freopen() stdout to some file at the same
places.

=========================================================

I then had a look what had actually changed in unexelf.c, and with the
following diff applied to unexelf.c I can make it work again
(i.e. disabling the SGI-specials introduced for the .got section):

*** unexelf.c.21.2	Mon Jan 28 17:33:22 2002
--- unexelf.c	Mon Mar 25 14:40:55 2002
***************
*** 1033,1038 ****
--- 1033,1039 ----
  		      ".lit4")
  	  || !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
  		      ".lit8")
+ #if 0
  #if __sgi
  	  /* According to David Kaelbling <drk@bobo.hudson.sgi.com>,
  	     the SGI-specific section below is required to avoid core
***************
*** 1042,1047 ****
--- 1043,1049 ----
  	  || !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
  		      ".got")
  #endif
+ #endif
  	  || !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
  		      ".sdata1")
  	  || !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
***************
*** 1220,1228 ****
--- 1222,1232 ----
  			".lit4")
  	    || !strcmp ((old_section_names + NEW_SECTION_H (nn).sh_name),
  			".lit8")
+ #if 0
  #if __sgi
  	    || !strcmp ((old_section_names + NEW_SECTION_H (nn).sh_name),
  			".got")
+ #endif
  #endif
  	    || !strcmp ((old_section_names + NEW_SECTION_H (nn).sh_name),
  			".sdata1")

I did configure emacs as

# ./configure  --prefix=/software/emacs/21.2
# -exec-prefix=/software/emacs/21.2/IRIX-6 --with-pop
# --with-x-toolkit=athena

R'

Re: `print' does not print

[Eli Zaretskii]

On Mon, 25 Mar 2002, Ralf Fassel wrote:

> I then had a look what had actually changed in unexelf.c, and with the
> following diff applied to unexelf.c I can make it work again
> (i.e. disabling the SGI-specials introduced for the .got section):
> 
> *** unexelf.c.21.2	Mon Jan 28 17:33:22 2002
> --- unexelf.c	Mon Mar 25 14:40:55 2002
> ***************
> *** 1033,1038 ****
> --- 1033,1039 ----
>   		      ".lit4")
>   	  || !strcmp ((old_section_names + NEW_SECTION_H (n).sh_name),
>   		      ".lit8")
> + #if 0
>   #if __sgi
>   	  /* According to David Kaelbling <drk@bobo.hudson.sgi.com>,
>   	     the SGI-specific section below is required to avoid core

So it is possible that the change which does the damage is the one about 
.got sections, not the fact that file I/O is used instead of mmap.  Could 
you try unexelf.c from v21.2 with the .got sections and see if that makes 
Emacs 21.1 unable to print?

David, can you help us here and explain why those additions were 
necessary?  Perhaps the new unexelf.c in Emacs 21.2 makes them redundant?

To fill you in, this thread (which you can find on gnu.emacs.bug) was 
about "emacs -batch" being unable to print to stdout when compiled with 
GCC.  Ralf's debugging indicates that this happens because fwrite somehow 
fails to allocate the buffer for the FILE object (this is in part a 
speculation, since we don't have access to library sources).

Also, do you have any clue why does the problem happen with GCC, but not 
with the native compiler?

TIA

Re: `print' does not print

[David Kaelbling]

Eli Zaretskii wrote:
> 
> So it is possible that the change which does the damage is the one about
> .got sections, not the fact that file I/O is used instead of mmap.  Could
> you try unexelf.c from v21.2 with the .got sections and see if that makes
> Emacs 21.1 unable to print?
> 
> David, can you help us here and explain why those additions were
> necessary?  Perhaps the new unexelf.c in Emacs 21.2 makes them redundant?

I'm afraid I can't offer much useful input here.  When I first tried
emacs 21 wouldn't bootstrap because the dumped emacs died with a bus
error.  I compared unexelf.c with the one in emacs 20 and the one in
xemacs (both of which work flawlessly), and re-introduced some code that
had been removed.  Afterwards emacs 21 worked, although it is not quite
right: it gives dbx fits, and is subject to runaway memory growth and
sporadic crashes.

I can try to beg time from someone who actually understands the elf file
if that would help.  Maybe whoever removed that code from the previous
versions remembers why?

	David

-- 
David KAELBLING <drk@sgi.com>	    Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749	    781.839.2157, fax ...2357

Re: `print' does not print

[Eli Zaretskii]

> Date: Mon, 25 Mar 2002 09:49:03 -0500
> From: David Kaelbling <drk@sgi.com>
> > 
> > David, can you help us here and explain why those additions were
> > necessary?  Perhaps the new unexelf.c in Emacs 21.2 makes them redundant?
> 
> I'm afraid I can't offer much useful input here.  When I first tried
> emacs 21 wouldn't bootstrap because the dumped emacs died with a bus
> error.  I compared unexelf.c with the one in emacs 20 and the one in
> xemacs (both of which work flawlessly), and re-introduced some code that
> had been removed.

I cannot see anything in Emacs 20.6's unexelf.c that used .got
sections.  Can you tell more precisely what was removed in Emacs 21?
WIthout the additional info, I cannot figure out who removed that, and
so cannot ask that person for the reasons, nor look in the logs for
possible explanations.

> Afterwards emacs 21 worked, although it is not quite right: it gives
> dbx fits, and is subject to runaway memory growth and sporadic
> crashes.

That's very strange: I use stock Emacs 21.1 on SGI Irix 6.5 all the
time, and I have yet to see a single crash.  dbx seems to work on it
reasonably well, but I didn't debug Emacs on that machine enough to
have a firm opinion.

Did you link your Emacs with optional graphics libraries (XPM, TIFF,
etc.), and if so, are those dynamic libraries or static libraries?

Re: `print' does not print

[David Kaelbling]

Eli Zaretskii wrote:
> 
> I cannot see anything in Emacs 20.6's unexelf.c that used .got
> sections.  Can you tell more precisely what was removed in Emacs 21?

Sorry, I was mistaken.  The changes I used came from xemacs.


> > Afterwards emacs 21 worked, although it is not quite right: it gives
> > dbx fits, and is subject to runaway memory growth and sporadic
> > crashes.
> 
> That's very strange: I use stock Emacs 21.1 on SGI Irix 6.5 all the
> time, and I have yet to see a single crash.  dbx seems to work on it
> reasonably well, but I didn't debug Emacs on that machine enough to
> have a firm opinion.

Are you running on a pre-6.5.10 system without the compiler_eoe
patches?  That seems to be a factor.


> Did you link your Emacs with optional graphics libraries (XPM, TIFF,
> etc.), and if so, are those dynamic libraries or static libraries?

Yes, using shared libraries from http://freeware.sgi.com/.  Actually we
discussed this last November when I first submitted the patch. 
(Subject: unexelf.c failure on IRIX)

	David

-- 
David KAELBLING <drk@sgi.com>	    Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749	    781.839.2157, fax ...2357

Re: `print' does not print

[Eli Zaretskii]

On Mon, 25 Mar 2002, David Kaelbling wrote:

> > > Afterwards emacs 21 worked, although it is not quite right: it gives
> > > dbx fits, and is subject to runaway memory growth and sporadic
> > > crashes.
> > 
> > That's very strange: I use stock Emacs 21.1 on SGI Irix 6.5 all the
> > time, and I have yet to see a single crash.  dbx seems to work on it
> > reasonably well, but I didn't debug Emacs on that machine enough to
> > have a firm opinion.
> 
> Are you running on a pre-6.5.10 system without the compiler_eoe
> patches?  That seems to be a factor.

It sounds like I have version 6.5.14m of the OS here.  But if you tell me 
what to look for in the output of versions(1), I can give a more precise 
answer.

> > Did you link your Emacs with optional graphics libraries (XPM, TIFF,
> > etc.), and if so, are those dynamic libraries or static libraries?
> 
> Yes, using shared libraries from http://freeware.sgi.com/.  Actually we
> discussed this last November when I first submitted the patch. 
> (Subject: unexelf.c failure on IRIX)

Yes, but I forgot ;-).

Anyway, I don't know if this is a factor, but my libraries are all built 
from sources, and I linked them in statically.

Re: `print' does not print

[David Kaelbling]

Eli Zaretskii wrote:
> 
> It sounds like I have version 6.5.14m of the OS here.  But if you tell me
> what to look for in the output of versions(1), I can give a more precise
> answer.

Running "uname -R" will give you the micro-release number.  If it it
less than 6.5.10 then we need to do something with "versions" to tell
whether you have the MIPSpro 7.3 runtimes installed.


> Anyway, I don't know if this is a factor, but my libraries are all built
> from sources, and I linked them in statically.

Hmm.  I won't have time in the next two weeks, but I'll try building
with static libraries too.  Not as nice, but if it works that'll do.

	David

-- 
David KAELBLING <drk@sgi.com>	    Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749	    781.839.2157, fax ...2357

Re: `print' does not print

[Eli Zaretskii]

On Tue, 26 Mar 2002, David Kaelbling wrote:

> Eli Zaretskii wrote:
> > 
> > It sounds like I have version 6.5.14m of the OS here.  But if you tell me
> > what to look for in the output of versions(1), I can give a more precise
> > answer.
> 
> Running "uname -R" will give you the micro-release number.

Yes, it says 6.5.14m.  So that's probably the reason I never saw such 
problems.

> > Anyway, I don't know if this is a factor, but my libraries are all built
> > from sources, and I linked them in statically.
> 
> Hmm.  I won't have time in the next two weeks, but I'll try building
> with static libraries too.  Not as nice, but if it works that'll do.

It's not as nice, granted; but it makes my binary movable anywhere, so I 
don't need to depend on sysadmins' mercy... well, you know what I mean.

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| > > Anyway, I don't know if this is a factor, but my libraries are all built
| > > from sources, and I linked them in statically.
| > 
| > Hmm.  I won't have time in the next two weeks, but I'll try building
| > with static libraries too.  Not as nice, but if it works that'll do.

FWIW, I had some problems with two different versions of shared libz
on my system which broke emacs':

- the system comes with libz.so, version 1.0.4
- I had a self-compiled libz.so.1.0.4 in my LD_LIBRARY_PATH

Now the system lib was picked up by -lz at link time, and the custom
lib was picked up during runtime in LD_* This made emacs dump core on
exit, since the two obviously were not compatible (the custom lib had
additional symbols from gcc compilation which conflicted in some way
with the emacs image).  I resolved this by installing a static
libz.1.1.4 and adapting the Makefile to use the static libz.a instead
of -lz.

R'

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| So it is possible that the change which does the damage is the one about 
| .got sections, not the fact that file I/O is used instead of mmap.  Could 
| you try unexelf.c from v21.2 with the .got sections and see if that makes 
| Emacs 21.1 unable to print?

I barely dare to report what I've found by now...

FWIW, my compilation machine still runs IRIX 6.5.9, but another is
upgraded to IRIX 6.5.15.  Since the code mentions IRIX 6.5.14 in some
place, I thought it might be a good idea to try to compile on 6.5.15
(same gcc binary, NFS mounted from my 6.5.9 machine).

The results are:

- dumping (as compared to compiling/linking) an unmodified emacs 21.2
  on my IRIX 6.5.15 works (even when running the resulting binary on
  IRIX 6.5.9).  It makes no difference whether the compilation
  directory is NFS-mounted or local.

- dumping (as compared to compiling/linking) an unmodified emacs 21.2
  on my IRIX 6.5.9 does not work (even when running the resulting
  binary on 6.5.15).  It makes no difference whether the compilation
  directory is NFS-mounted or local.

So it seems the dump process (not the compilation or the linking of
`temacs') is the crucial step which requires the correct runtime
libraries of IRIX (?).  I ensured that the only shared libraries are
SGI libraries, everything else (libz, libpng and libtiff) is
statically linked (same versions on both machines).

Since the maintenance versions of IRIX are available free, I think it
would be a good idea to mention this in the PROBLEMS file.

R'

Re: `print' does not print

[David Kaelbling]

Before IRIX 6.5.10 the IRIX runtimes were based on the MIPSpro 7.2
compilers.  Since 6.5.10 they have been generated by the MIPSpro 7.3
compilers.  

If you want to experiment you could install the new runtime patches 
(3911 and maybe 4330 for C, 3742 for C++, and 3743 for fortran) from
http://www.sgi.com/support/patch_intro.html on your 6.5.9 system and see
if that changes anything.

	David

Ralf Fassel wrote:
> 
> - dumping (as compared to compiling/linking) an unmodified emacs 21.2
>   on my IRIX 6.5.15 works (even when running the resulting binary on
>   IRIX 6.5.9).  It makes no difference whether the compilation
>   directory is NFS-mounted or local.
> 
> - dumping (as compared to compiling/linking) an unmodified emacs 21.2
>   on my IRIX 6.5.9 does not work (even when running the resulting
>   binary on 6.5.15).  It makes no difference whether the compilation
>   directory is NFS-mounted or local.

-- 
David KAELBLING <drk@sgi.com>	    Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749	    781.839.2157, fax ...2357

Re: `print' does not print

[Eli Zaretskii]

> Date: Mon, 25 Mar 2002 18:41:34 +0100
> From: Ralf Fassel <ralf@akutech.de>
> 
> - dumping (as compared to compiling/linking) an unmodified emacs 21.2
>   on my IRIX 6.5.15 works (even when running the resulting binary on
>   IRIX 6.5.9).  It makes no difference whether the compilation
>   directory is NFS-mounted or local.
> 
> - dumping (as compared to compiling/linking) an unmodified emacs 21.2
>   on my IRIX 6.5.9 does not work (even when running the resulting
>   binary on 6.5.15).  It makes no difference whether the compilation
>   directory is NFS-mounted or local.

Does this mean that the `print' problem also goes away in the 6.5.15
build?

If not, what does ``dumping doesn't work'' mean, exactly?  Does the
dumped Emacs crash?

Finally, does Emacs 21.1 ``work'' (in the same sense) when built on
the machine with newer OS?

Btw, the NFS-related problems were not spotted on Irix.  Most of the
reports came from GNU/Linux machines (which also use unexelf).

> Since the maintenance versions of IRIX are available free, I think it
> would be a good idea to mention this in the PROBLEMS file.

Sure, as soon as I figure out what is it that we want to say ;-)

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| Does this mean that the `print' problem also goes away in the 6.5.15
| build?

`works' in my message was referring only to the printing problem.

The printing runtime problem goes away on 6.5.9 and 6.5.15 if I dump
on 6.5.15.  What is left to check is whether it also goes away if one
would apply the SGI patch for the runtime environment of 6.5.9 and
dump there.  But since the machine running 6.5.9 is critical for our
daily operation, I'll have to wait for the upcoming holidays to
patch/upgrade.  If time permits, I will check whether the patches
solve the problem too.

| If not, what does ``dumping doesn't work'' mean, exactly?  Does the
| dumped Emacs crash?

I don't get core dumps in any cases during build or dump.

| Finally, does Emacs 21.1 ``work'' (in the same sense) when built on
| the machine with newer OS?

emacs 21.1, using gcc 2.95.3:
- Compiled and dumped on 6.5.15: prints.
- compiled on 6.5.9, dumped on 6.5.15: prints.
- compiled on 6.5.15, dumped on 6.5.9: prints.
- Compiled and dumped on 6.5.9: prints.

R'

Re: `print' does not print

[Eli Zaretskii]

On Mon, 25 Mar 2002, Ralf Fassel wrote:

> The printing runtime problem goes away on 6.5.9 and 6.5.15 if I dump
> on 6.5.15.

Great, so it seems that the SGI-specific patch in unexelf.c is 
unnecessary and even dangerous, and should be taken out.  Thanks for your 
help in debugging this.

> What is left to check is whether it also goes away if one
> would apply the SGI patch for the runtime environment of 6.5.9 and
> dump there.  But since the machine running 6.5.9 is critical for our
> daily operation, I'll have to wait for the upcoming holidays to
> patch/upgrade.  If time permits, I will check whether the patches
> solve the problem too.

Thanks.  If the patches do work, please tell me what patches are needed, 
so I could list them in etc/MACHINES and etc/PROBLEMS.

Re: `print' does not print

[David Kaelbling]

Eli Zaretskii wrote:
> 
> On Mon, 25 Mar 2002, Ralf Fassel wrote:
> 
> > The printing runtime problem goes away on 6.5.9 and 6.5.15 if I dump
> > on 6.5.15.
> 
> Great, so it seems that the SGI-specific patch in unexelf.c is
> unnecessary and even dangerous, and should be taken out.  Thanks for your
> help in debugging this.

It wouldn't surprise me, but is that really what Ralf said?  I'm
probably confused, but I thought this was the state of things:

21.1
	Compiler:	archive libs	shared libs
	-----------	------------	-----------
	MIPSpro 7.2	
	MIPSpro 7.3			fails
	gcc w/7.2 libc	works
	gcc w/7.3 libc	works

21.2/21.1+patch

	Compiler:	archive libs	shared libs
	-----------	------------	-----------
	MIPSpro 7.2	
	MIPSpro 7.3			almost works (21.1+)
	gcc w/7.2 libc	fails
	gcc w/7.3 libc	works

David

-- 
David KAELBLING <drk@sgi.com>	    Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749	    781.839.2157, fax ...2357

Re: `print' does not print

[Ralf Fassel]

* David Kaelbling
| > Great, so it seems that the SGI-specific patch in unexelf.c is
| > unnecessary and even dangerous, and should be taken out.
| 
| It wouldn't surprise me, but is that really what Ralf said?

I wasn't quite sure about that statement either.  I could not
reproduce the problems the `.got' statements were meant to solve, but
I'm not sure that this means that they might go away.  They might help
in a different environment (which I obviously not have, since emacs
works at my site w/o those statements).

What I have found is that you need an upgraded IRIX version (at least
6.5.10 it seems) to make these `.got' statements work with gcc
compilation.

I also found that cc compilation seems to works in any case (21.1 and
21.2, contrary to the comments in 21.2 unexelf.c that require the
`.got' sections).

| I'm probably confused,

AOL :-)

Summary:
========
`prints' means:
       emacs -batch -no-site-file -eval '(print emacs-version)'
    prints the version number on both IRIX version.

`does not print' means:
    the above command line does not print the version number on no
    IRIX version.
    The problem seems to be that stdio output is broken, since none of
    the stdio functions produce any output.  The plain I/O system
    calls like write(2) do work, however.

There wasn't the situation that it printed on one OS and not on the
other.  Either it printed on both or on none.

compiled =~ gmake temacs, i.e. compile all objects and link temacs,
            then stop
dumped   =~ gmake emacs, i.e. temacs has been built previously, now
            produce the emacs executable

gcc version 2.95.3 20010315 (release)
cc MIPSpro Compilers: Version 7.30
OS IRIX 6.5.9f and 6.5.15m

Custom libraries:
- static libz    1.1.4
- static libtiff v3.4beta037
- static libpng  1.0.8


Configurations tested:
======================
Emacs version | compiled with | compiled on | dumped on | prints
----------------------------------------------------------------
    21.2          gcc -g          6.5.9f        6.5.9f      no
    21.2          gcc -g          6.5.15m       6.5.9f      no

    21.2          gcc -g          6.5.9f        6.5.15m     yes
    21.2          gcc -g          6.5.15m       6.5.15m     yes

    21.2          cc  -g           *               *        yes
----------------------------------------------------------------
    21.1          *   -g           *               *        yes
----------------------------------------------------------------

I had no core dumps during compilation/dumping in any configuration.

R'

Re: `print' does not print

[Eli Zaretskii]

On Tue, 26 Mar 2002, Ralf Fassel wrote:

> * David Kaelbling
> | > Great, so it seems that the SGI-specific patch in unexelf.c is
> | > unnecessary and even dangerous, and should be taken out.
> | 
> | It wouldn't surprise me, but is that really what Ralf said?
> 
> I wasn't quite sure about that statement either.  I could not
> reproduce the problems the `.got' statements were meant to solve, but
> I'm not sure that this means that they might go away.  They might help
> in a different environment (which I obviously not have, since emacs
> works at my site w/o those statements).

We need to try to identify the environment where the `.got' sections need 
the special treatment they now have in unexelf.c.  Curiously enough, 
David's report was about Irix 6.5.14f and version 7.3.1.3m of development 
tools, so versions of Irix before 6.5.10 and version 7.2 of the compiler 
and the libraries seem to not be an issue in that case.

> What I have found is that you need an upgraded IRIX version (at least
> 6.5.10 it seems) to make these `.got' statements work with gcc
> compilation.
> 
> I also found that cc compilation seems to works in any case (21.1 and
> 21.2, contrary to the comments in 21.2 unexelf.c that require the
> `.got' sections).

I was also under an impression that unexelf.c from Emacs 21.2 with the 
special .got sections treatment removed made `print' work, is that true?

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| We need to try to identify the environment where the `.got' sections need 
| the special treatment they now have in unexelf.c.  Curiously enough, 
| David's report was about Irix 6.5.14f and version 7.3.1.3m of development 
| tools, so versions of Irix before 6.5.10 and version 7.2 of the compiler 
| and the libraries seem to not be an issue in that case.

Note that I have cc 7.30 (not 7.2) with 6.5.9, but not (yet) the
patches (SGI patch #3911) which SGI has released for that
compiler/runtime combo.  Compiler versions 7.3.x (with x >= 1) seem to
have that patch included already.

| I was also under an impression that unexelf.c from Emacs 21.2 with
| the special .got sections treatment removed made `print' work, is
| that true?

Yes.
There are two occurences of `#if __sgi' in unexelf.c which are wrapping
.got special-code (#1036ff and #1223ff).  If I comment these out,
printing works with an otherwise unchanged emacs 21.2 and gcc.

As an aside, I had a quick glance at the output of `nm' on the temacs
binaries, but could not make any sense out of it.  If someone thinks
this might be of some help, I can send it.

R'

Re: `print' does not print

[Eli Zaretskii]

On Wed, 27 Mar 2002, Ralf Fassel wrote:

> As an aside, I had a quick glance at the output of `nm' on the temacs
> binaries, but could not make any sense out of it.  If someone thinks
> this might be of some help, I can send it.

I don't know enough about Irix binary formats, but I'd at least suggest 
to compare the output of nm for the two builds you did on the two 
different OS versions (the one that worked and the one that didn't): 
perhaps this comparison will tell something.

Re: `print' does not print

[Eli Zaretskii]

> Date: Wed, 27 Mar 2002 10:00:30 +0100
> From: Ralf Fassel <ralfixx@gmx.de>
> 
> * Eli Zaretskii
> | We need to try to identify the environment where the `.got' sections need 
> | the special treatment they now have in unexelf.c.  Curiously enough, 
> | David's report was about Irix 6.5.14f and version 7.3.1.3m of development 
> | tools, so versions of Irix before 6.5.10 and version 7.2 of the compiler 
> | and the libraries seem to not be an issue in that case.
> 
> Note that I have cc 7.30 (not 7.2) with 6.5.9, but not (yet) the
> patches (SGI patch #3911) which SGI has released for that
> compiler/runtime combo.  Compiler versions 7.3.x (with x >= 1) seem to
> have that patch included already.
> 
> | I was also under an impression that unexelf.c from Emacs 21.2 with
> | the special .got sections treatment removed made `print' work, is
> | that true?
> 
> Yes.
> There are two occurences of `#if __sgi' in unexelf.c which are wrapping
> .got special-code (#1036ff and #1223ff).  If I comment these out,
> printing works with an otherwise unchanged emacs 21.2 and gcc.

I would like to resolve this issue for the next bugfix release (which
means soon ;-).  It is my impression that removing the SGI-specific
treatment of the `.got' sections from unexelf.c is a good idea, but
I'm unsure whether it will have adverse effects on some (older?)
versions of the SGI development tools, and if so whether saying in
etc/MACHINES that users should upgrade to newer devo is good enough.

Ralf and David, could you please advise?  Thanks.

Re: `print' does not print

[Ralf Fassel]

* Eli Zaretskii
| It is my impression that removing the SGI-specific treatment of the
| `.got' sections from unexelf.c is a good idea, but I'm unsure
| whether it will have adverse effects on some (older?)  versions of
| the SGI development tools, and if so whether saying in etc/MACHINES
| that users should upgrade to newer devo is good enough.

Since we do not seem to be able to recreate the exact conditions to
check why these were necessary (David?), and since an OS upgrade (Good
Thing [TM] anyway) solves the issue I have brought up, I think adding
advice to etc/MACHINES is enough.

R'

Re: `print' does not print

[David Kaelbling]

Okay with me!  I'll try again with the new bugfix release and see if I
can come up with a more coherent explanation for any problems.

	Thanks,
	David

Ralf Fassel wrote:
> 
> * Eli Zaretskii
> | It is my impression that removing the SGI-specific treatment of the
> | `.got' sections from unexelf.c is a good idea, but I'm unsure
> | whether it will have adverse effects on some (older?)  versions of
> | the SGI development tools, and if so whether saying in etc/MACHINES
> | that users should upgrade to newer devo is good enough.
> 
> Since we do not seem to be able to recreate the exact conditions to
> check why these were necessary (David?), and since an OS upgrade (Good
> Thing [TM] anyway) solves the issue I have brought up, I think adding
> advice to etc/MACHINES is enough.
> 
> R'

-- 
David KAELBLING <drk@sgi.com>	    Silicon Graphics Computer Systems
1 Cabot Rd, suite 250; Hudson, MA 01749	    781.839.2157, fax ...2357

Re: `print' does not print

[Eli Zaretskii]

> Date: Fri, 12 Apr 2002 11:08:47 -0400
> From: David Kaelbling <drk@sgi.com>
> 
> Okay with me!  I'll try again with the new bugfix release and see if I
> can come up with a more coherent explanation for any problems.

Thanks for the feedback.  I've removed the special treatment of the
`.got' sections; let's see if someone complains.

Re: `print' does not print

[Eli Zaretskii]

> From: Ralf Fassel <ralf@akutech.de>
> Date: Fri, 12 Apr 2002 13:31:46 +0200
> 
> Since we do not seem to be able to recreate the exact conditions to
> check why these were necessary (David?), and since an OS upgrade (Good
> Thing [TM] anyway) solves the issue I have brought up, I think adding
> advice to etc/MACHINES is enough.

Okay, I've made the addition to MACHINES.

Thanks to you and David for your help in resolving this complicated
problem.

Re: `print' does not print

[Richard Stallman]

    I would like to resolve this issue for the next bugfix release (which
    means soon ;-).  It is my impression that removing the SGI-specific
    treatment of the `.got' sections from unexelf.c is a good idea, but
    I'm unsure whether it will have adverse effects on some (older?)
    versions of the SGI development tools, and if so whether saying in
    etc/MACHINES that users should upgrade to newer devo is good enough.

You could check the version number of these tools and conditionally
turn that off.

I don't know if that is worth doing.

Re: `print' does not print

[Richard Stallman]

If GCC doesn't compile, please send a GCC bug report.
I hope it will eventually get fixed.

Re: `print' does not print

[Richard Stallman]

      % cat foo
      (print 'foo)
      % emacs-21.2 -batch -q -no-site-file -l foo
      %

This problem does not seem to exist in the latest sources in CVS.
It must be only in the 21.2 branch.

Can someone debug it?


_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs