glibc 2.2.94 - hppa - min kernel and unwind-find-fde]

pa,

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

c.

----- Forwarded message from Roland McGrath <[email protected]> -----

Envelope-to: carlos@localhost
Delivery-date: Tue, 01 Oct 2002 15:51:34 -0400
From: Roland McGrath <[email protected]>
To: "Carlos O'Donell" <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: [PATCH] glibc 2.2.94 - hppa - min kernel and unwind-find-fde
X-Windows: ignorance is our most important resource.

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.

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

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

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.

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                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

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.

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

                                    ^^^^

c.

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

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                [email protected]

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

Hello, I am using Quantum 9GB HDD 7200 SCSI on my K210/819 without problems it's using old SCSI cable 50pins.

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

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.

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

*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.

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

Revolutions do not require corporate support.

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

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

James S

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                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)