[parisc-linux] [roland@redhat.com: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde]

[parisc-linux] [roland@redhat.com: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde]

[Carlos O'Donell]

pa,

Do we actaully have such a thing as old C++ binaries? :)
Thoughs or comments appreciated.

c.

----- Forwarded message from Roland McGrath <roland@redhat.com> -----

Envelope-to: carlos@localhost
Delivery-date: Tue, 01 Oct 2002 15:51:34 -0400
From: Roland McGrath <roland@redhat.com>
To: "Carlos O'Donell" <carlos@baldric.uwo.ca>
Cc: libc-alpha@sources.redhat.com, debian-glibc@lists.debian.org
Subject: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde
X-Windows: ignorance is our most important resource.

> The following patch bumps up the minimum kernel required for hppa,
> and adds libc_cv_gcc_unwind_find_fde (I'm curious if this last bit 
> is still needed?). 

Please figure it out and be sure.  You need it only if there are existing
old C++ binaries that have references to _Unwind_Find_FDE.  If there are no
C++ binaries you want to be compatible with that predate a certain GCC
version (not sure which off hand), then you don't need it.  But I don't
think it hurts to have it.

> 2002-10-01  Matthew Wilcox  <willy@debian.org>
> 
> 	* sysdeps/unix/sysv/linux/configure: 
> 	Make 2.4.18 minimum linux kernel for hppa, and add 
> 	libc_cv_gcc_unwind_find_fde=yes.

This log entry is for a generated file, and there is no log entry for the
actual source file.

----- End forwarded message -----

Re: [parisc-linux] [roland@redhat.com: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde]

[John David Anglin]

> Please figure it out and be sure.  You need it only if there are existing
> old C++ binaries that have references to _Unwind_Find_FDE.  If there are no
> C++ binaries you want to be compatible with that predate a certain GCC
> version (not sure which off hand), then you don't need it.  But I don't
> think it hurts to have it.

I believe that this is needed for dw2 exception support.  This doesn't
work with gcc 3.0.4, so I don't think you need to worry much about old
binaries.

> > 2002-10-01  Matthew Wilcox  <willy@debian.org>
> > 
> > 	* sysdeps/unix/sysv/linux/configure: 
> > 	Make 2.4.18 minimum linux kernel for hppa, and add 
> > 	libc_cv_gcc_unwind_find_fde=yes.
> 
> This log entry is for a generated file, and there is no log entry for the
> actual source file.

I noticed this when I was fixing the gcc dw2 exception support.  Changing
it didn't seem to have any affect on the v3 or g++ testsuite results, but
it seems the correct thing to do.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] [roland@redhat.com: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde]

[Carlos O'Donell]

> > Please figure it out and be sure.  You need it only if there are existing
> > old C++ binaries that have references to _Unwind_Find_FDE.  If there are no
> > C++ binaries you want to be compatible with that predate a certain GCC
> > version (not sure which off hand), then you don't need it.  But I don't
> > think it hurts to have it.
> 
> I believe that this is needed for dw2 exception support.  This doesn't
> work with gcc 3.0.4, so I don't think you need to worry much about old
> binaries.

So the rationale is:
It never worked, so removing it still leaves non-working old C++ binaries.

I assume I would be able to test this by looking at all the C++ binaries 
in the hppa archive and looking for ref's to _Unwind_Find_FDE.
 
> > > 2002-10-01  Matthew Wilcox  <willy@debian.org>
> > > 
> > > 	* sysdeps/unix/sysv/linux/configure: 
> > > 	Make 2.4.18 minimum linux kernel for hppa, and add 
> > > 	libc_cv_gcc_unwind_find_fde=yes.
> > 
> > This log entry is for a generated file, and there is no log entry for the
> > actual source file.
> 
> I noticed this when I was fixing the gcc dw2 exception support.  Changing
> it didn't seem to have any affect on the v3 or g++ testsuite results, but
> it seems the correct thing to do.
> 

Setting "libc_cv_gcc_unwind_find_fde=no" seems the correct thing to do?
                                    ^^^^
c.

[parisc-linux] Non-HP disks?

[Derek Engelhaupt]

Anyone using them?  I have a bunch of IBM DCHS-04F Ultrastar 2XP 4.3GB
(got info from IBM's website about jumpers and tried them all) drives
that I'm trying to get them to work but all they do is SCSI bus reset
when Debian trys to load.  They are factory refurbed 50-pin SE disks
and I have activated Autostart on them and active termination (tried it
without too).  Anyway, they perform this way under HP-UX too.  Tried a
2GB HP drive and it works fine so the system SCSI bus is fine.  So,
bottom line is anyone using NON-HP disks in thier systems?  Tried them
in my E55, 712/60, and 712/100.  Have tried 2 different drives with the
same result also.....

derek

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: [parisc-linux] Non-HP disks?

[E Frank Ball]

On Tue, Oct 01, 2002 at 08:40:59PM -0700, Derek Engelhaupt wrote:
} Anyone using them?  I have a bunch of IBM DCHS-04F Ultrastar 2XP 4.3GB
} (got info from IBM's website about jumpers and tried them all) drives
} that I'm trying to get them to work but all they do is SCSI bus reset
} when Debian trys to load.  They are factory refurbed 50-pin SE disks
} and I have activated Autostart on them and active termination (tried it
} without too).  Anyway, they perform this way under HP-UX too.  Tried a
} 2GB HP drive and it works fine so the system SCSI bus is fine.  So,
} bottom line is anyone using NON-HP disks in thier systems?  Tried them
} in my E55, 712/60, and 712/100.  Have tried 2 different drives with the
} same result also.....

Most non-HP drives should work fine.  We use lots of Seagate Medalist
ST34520N drives in all the 700s.  We used to use some Quatums, and we've
used IBMs too, but I don't know the nubmers.

-- 

   E Frank Ball                frankb@efball.com

Re: [parisc-linux] Non-HP disks?

[Christian Suder]

I have been using non-HP firmware Seagate, Quantum, Toshiba and IBM drives (older 1GB though) in 712, 735 and C class. 

IIRC correctly I couldn't get a newer 4.3 GB IBM drive to work in a SS20, the drive is Ultra-SCSI and that somehow doesn't work with old controllers. May be the same problem in HPs,

	Christian 


On Tue, 1 Oct 2002 20:40:59 -0700 (PDT)
"Derek Engelhaupt" <derekengelhaupt@rocketmail.com> wrote:

> Anyone using them?  I have a bunch of IBM DCHS-04F Ultrastar 2XP 4.3GB
> (got info from IBM's website about jumpers and tried them all) drives
> that I'm trying to get them to work but all they do is SCSI bus reset
> when Debian trys to load.  They are factory refurbed 50-pin SE disks
> and I have activated Autostart on them and active termination (tried it
> without too).  Anyway, they perform this way under HP-UX too.  Tried a
> 2GB HP drive and it works fine so the system SCSI bus is fine.  So,
> bottom line is anyone using NON-HP disks in thier systems?  Tried them
> in my E55, 712/60, and 712/100.  Have tried 2 different drives with the
> same result also.....
> 
> derek
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Non-HP disks?

[Stephan Trajkoff]

Derek Engelhaupt wrote:

>Anyone using them?  I have a bunch of IBM DCHS-04F Ultrastar 2XP 4.3GB
>(got info from IBM's website about jumpers and tried them all) drives
>that I'm trying to get them to work but all they do is SCSI bus reset
>when Debian trys to load.  They are factory refurbed 50-pin SE disks
>and I have activated Autostart on them and active termination (tried it
>without too).  Anyway, they perform this way under HP-UX too.  Tried a
>2GB HP drive and it works fine so the system SCSI bus is fine.  So,
>bottom line is anyone using NON-HP disks in thier systems?  Tried them
>in my E55, 712/60, and 712/100.  Have tried 2 different drives with the
>same result also.....
>
>derek
>
>__________________________________________________
>Do you Yahoo!?
>New DSL Internet Access from SBC & Yahoo!
>http://sbc.yahoo.com
>_______________________________________________
>parisc-linux mailing list
>parisc-linux@lists.parisc-linux.org
>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
>  
>
Hello, I am using Quantum 9GB HDD 7200 SCSI on my K210/819 without problems
it's using old SCSI cable 50pins.

[parisc-linux] gcc and ++

[phi]

Hi,

Working on an endian neutral file reader, I bumped into sometihng strange with
gcc.

basically I got to read a 32 unsigned int from a file that is mmap'ed, I have
a unsigned char * that is supposed to be at the unsigned int addr but possibly
unaligned.

I have a macro defined like this, then allowing the unsigned int getter from
file to expression.

#define get_4(p) ( ((uint32)(*p++)<<24)| \
                   ((uint32)(*p++)<<16)| \
                   ((uint32)(*p++)<<8 )| \
                   ((uint32)(*p++)) )

It assume the given p is
unsigned char *p;
then produce an uint32 expression.

Now using this macro on hpux/hpc linux/i386 linux/hppa gives 3 different
result with the linux/hppa particularly wrong IMHO. I wonder if this funny
could endup in kernel bugs?

==============================================================
Here is my test prog, get2_4 is a workaround attempt...

typedef unsigned char uint8;
typedef unsigned int  uint32;

#define get_4(p) ( ((uint32)(*p++)<<24)| \
                   ((uint32)(*p++)<<16)| \
                   ((uint32)(*p++)<<8 )| \
                   ((uint32)(*p++)) )

#define get2_4(p) ( p+=4, ((uint32)(p[-4])<<24)| \
                          ((uint32)(p[-3])<<16)| \
                          ((uint32)(p[-2])<<8 )| \
                          ((uint32)(p[-1])) )
main()
{ uint32 i;
  uint8 *p;
  p="abcd"; printf("p=%#x ",p);
  i=get_4(p);
  printf("i=%#x p=%#x\n",i,p);
  p="abcd"; printf("p=%#x ",p);
  i=get2_4(p);
  printf("i=%#x p=%#x\n",i,p);
}

==============================================================
Results:

HPUX/HPC:
---------
$ ./c
p=0x40001028 i=0x61626364 p=0x4000102c
p=0x40001048 i=0x61626364 p=0x4000104c

In both case i is loaded with the integer "abcd" (as expected I would say) and
after the expression p is bumped by 4 that is for sure expected.
Note the bad const re-use, hpc use 2 different "abcd" one at 0x40001028 the
other at 0x40001048 (but that's not a problem, +Osomething would eventually
get it right)

LINUX/i386:
---------- 
(red-hat 6.2 then very old compiler, may be someone can try on a very last
gcc?)

$ ./c
p=0x8048500 i=0x61616161 p=0x8048504
p=0x8048500 i=0x61626364 p=0x8048504

Here get_4(p) don't compute the expression corectly IMHO, but yet purist will
claim that KnR sez that side effect expression can't rely on order of
evaluation (bad practice programing), yet I wonder how the parse tree look
like here.
So i is semi wrong/right and p is bumped by 4 after the expression that is
expected.

get2_4(p), got i computed correctly and p bumped by 4, this is the workaround
I would use for the time being.

LINUX/hppa:
-----------
GNU C version 3.0.2 (Debian)
hpfrcw12:/tmp# ./c
p=0x10734 i=0x61616161 p=0x10735
p=0x10734 i=0x61626364 p=0x10738

Here get_4(p) is plain dead, i isn't computed correctly but as before one can
argue it is ok, but the pointer bump is completly wrong, there are 4 ++, and
no matter how we order the expression, p must be bumped by 4 it is bumped by
1!!!

So beside the scholastic discusion about when ++ should occur, I fear a bug in
the compiler that may have ramification in our kernel?

What do you think?

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

Challenge.

If someone can come with a better definition for get_4(p) i.e can force the ++
at correct place, I would grab, right now I use get2_4() that seems to be
portable.

Cheers,
Phi

Re: [parisc-linux] gcc and ++

[Matthew Wilcox]

On Wed, Oct 02, 2002 at 09:30:03AM +0200, phi wrote:
> #define get_4(p) ( ((uint32)(*p++)<<24)| \
>                    ((uint32)(*p++)<<16)| \
>                    ((uint32)(*p++)<<8 )| \
>                    ((uint32)(*p++)) )

Undefined behaviour.  `|' is not a sequence point and you modify p more than
once.  How would this look?

#define get_4(p)	p += 4, (((uint32)p[-4] << 24) | \
			 ((uint32)p[-3] << 16) | \
			 ((uint32)p[-2] <<  8) | \
			 ((unit32)p[-1]))

comma _is_ a sequence point, so this is well-defined.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] gcc and ++

[phi]

Matthew Wilcox wrote:
> 
> 
> Undefined behaviour.  `|' is not a sequence point and you modify p more than
> once.  

Wouldn't be 'natural' to declare ++ a sequence point as well as comma is since
it has side effects, beside it would remove the sequence-point jazz in the
warning emits.

Right now the macro look like this for flawed/featured gcc.

#define get3_4(p) ({register uint32
t=(*p++)<<24;t+=(*p++)<<16,t+=(*p++)<<8,t+(*p++);})

Phi

Re: [parisc-linux] gcc and ++

[Matthew Wilcox]

On Wed, Oct 02, 2002 at 03:01:32PM +0200, phi wrote:
> Wouldn't be 'natural' to declare ++ a sequence point as well as comma is since
> it has side effects, beside it would remove the sequence-point jazz in the
> warning emits.

*boggle*.  i suggest you get hold of a copy of the C spec or a good
book on the C programming language.  What you are doing is _explictly_
undefined by the specification.  The compiler is free to emit
whatever code it likes.  GCC doesn't warn for the fun of it, you know.
http://www.eskimo.com/~scs/C-faq/q3.1.html gives some more detail.

> Right now the macro look like this for flawed/featured gcc.
> 
> #define get3_4(p) ({register uint32
> t=(*p++)<<24;t+=(*p++)<<16,t+=(*p++)<<8,t+(*p++);})

i thought you were trying to write portable code; the ({ ... }) is a
gcc extension.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] Non-HP disks?

[Derek Engelhaupt]

--- Derek Engelhaupt <derekengelhaupt@rocketmail.com> wrote:
> Anyone using them?  I have a bunch of IBM DCHS-04F Ultrastar 2XP
> 4.3GB
> (got info from IBM's website about jumpers and tried them all) drives
> that I'm trying to get them to work but all they do is SCSI bus reset
> when Debian trys to load.  They are factory refurbed 50-pin SE disks
> and I have activated Autostart on them and active termination (tried
> it
> without too).  Anyway, they perform this way under HP-UX too.  Tried
> a
> 2GB HP drive and it works fine so the system SCSI bus is fine.  So,
> bottom line is anyone using NON-HP disks in thier systems?  Tried
> them
> in my E55, 712/60, and 712/100.  Have tried 2 different drives with
> the
> same result also.....
> 
> derek
> 
> 

Well, after screwing with it for another hour I finally got it to work.
 Appearantly I had to enable some "option block" on the drive to get it
to work as well as the Term Pwr on the drive.  My HP is the proud new
owner of a bunch of 4.3GB drives.  Now if I can only get the 9Gigers to
work now.... ;) Thanks for all the responses.

derek

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

Re: [parisc-linux] Non-HP disks?

[James Smith]

i had a very similar problem - i'd like to know how to use em too

James S



On Tue, 2002-10-01 at 22:40, Derek Engelhaupt wrote:
> Anyone using them?  I have a bunch of IBM DCHS-04F Ultrastar 2XP 4.3GB
> (got info from IBM's website about jumpers and tried them all) drives
> that I'm trying to get them to work but all they do is SCSI bus reset
> when Debian trys to load.  They are factory refurbed 50-pin SE disks
> and I have activated Autostart on them and active termination (tried it
> without too).  Anyway, they perform this way under HP-UX too.  Tried a
> 2GB HP drive and it works fine so the system SCSI bus is fine.  So,
> bottom line is anyone using NON-HP disks in thier systems?  Tried them
> in my E55, 712/60, and 712/100.  Have tried 2 different drives with the
> same result also.....
> 
> derek
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] [roland@redhat.com: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde]

[John David Anglin]

> > > > 2002-10-01  Matthew Wilcox  <willy@debian.org>
> > > > 
> > > > 	* sysdeps/unix/sysv/linux/configure: 
> > > > 	Make 2.4.18 minimum linux kernel for hppa, and add 
> > > > 	libc_cv_gcc_unwind_find_fde=yes.
> > > 
> > > This log entry is for a generated file, and there is no log entry for the
> > > actual source file.
> > 
> > I noticed this when I was fixing the gcc dw2 exception support.  Changing
> > it didn't seem to have any affect on the v3 or g++ testsuite results, but
> > it seems the correct thing to do.
> > 
> 
> Setting "libc_cv_gcc_unwind_find_fde=no" seems the correct thing to do?

That seems reasonable for gcc 3.0.4.  However, it may not matter.  With
gcc 3.3 and a slightly hacked glibc-2.2.5-14, I see the following in my
build log:

checking for DWARF2 unwind info support... (cached) no

This should be yes.  I haven't investigated why this is so.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)