Question about setjmp on Itanium HPUX.

[Peter Smithson]

Hi,

I've read this page -

http://devrsrc1.external.hp.com/STK/impacts/i634.html

but don't understand it. Here's the text -

"Non-standard usage of setjmp() and longjmp() could result in
compatibility problems. The contents of the jmp_buf buffer are specific
to the architecture and compilation environment. For example, this
includes using jmp_buf in a user-defined structure and passing jmp_buf
structures across relocatable objects. Objects built using these
functions may not be supported for future architectures, such as IPF."

What does it mean about passing jmp_buf across a relocatable object?
We've got a library with several source modules in it. We compile with
position independent options as we sometimes make a shared library from
this library.

We're getting core dumps when we do a setjmp on a jmp_buf who's address
is returned in another module. Seems to work OK if we malloc each
buffer individually in the other module (rather than using them out of a
structure). I can see that it's saying this won't work on the web page
- it doesn't want us to have a jmp_buf in a user defined structure (for
some reason).

But I'm not sure about this "across relocatable objects" - what does
that mean? We can't re-create it in a simple test program. (Two
source modules compiled together).

Any ideas?

Thanks.

Peter
--
http://www.beluga.freeserve.co.uk

[Keith Thompson]

dh*****@convex. hp.com (Dennis Handly) writes:

Keith Thompson (ks***@mib.org) wrote:
: Then the implementation needs to define jmp_buf so that any declared
: object of that type will be aligned properly, even if it's a member of
: a struct. It's free to use compiler magic if necessary (such as an
: alignment #pragma).

Unfortunately there is no such magic. pack overrides. :-(

I'm not sure what you mean by "pack", but I'm guessing you're
referring to an implementation-defined #pragma that causes struct
members to be packed more tightly than they normally would be. For
example, given something like

struct foo { char c; double d; };
#pragma pack struct foo /* or whatever the syntax is */
struct foo obj;

I would expect the compiler to do whatever it needs to to make obj.d
accessible as a double. If obj.d is byte-aligned because of the
pragma, but the hardware requires stricter alignment, the compiler
probably needs to do something like the equivalent of a memcpy() to a
properly aligned chunk of memory to access the value. Perhaps it
handles this except in the special case of type jmp_buf, which
apparently requires 16-byte alignment.

But as it turns out this doesn't necessarily mean the compiler is
broken. C99 6.10.6p1 says:

A preprocessing directive of the form

# pragma pp-tokensopt new-line

where the preprocessing token STDC does not immediately follow
pragma in the directive (prior to any macro replacement) causes
the implementation to behave in an implementation-defined
manner. The behavior might cause translation to fail or cause the
translator or the resulting program to behave in a non-conforming
manner. Any such pragma that is not recognized by the
implementation is ignored.

If that's not what you meant by "pack", please clarify.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

Peter Smithson <pg************ **********@yaho o.co.uk> wrote:

#include <stdio.h>
#include <setjmp.h>
#include <malloc.h>
No such header in ISO C. Use <stdlib.h> instead.
struct mystruct {
char abc;
jmp_buf s_jbuf;
};

#define ALLIGN 8

int main()
{
struct mystruct s_x;
This is correct.
struct mystruct *p_x = (void *)
((char *)malloc(sizeof (struct mystruct)+ALLIG N)+ALLIGN);
*Kablooie!* Yes, that was the sound of the alignment of your struct
being blown to bits. You do not know that a jmp_buf needs to be aligned
on 8 bytes or a whole fraction of 8 bytes. You do know that the pointer
returned from malloc() is correctly aligned for all types, including
jmp_buf and your struct. Therefore, you do not know that (that pointer+8
bytes) is correctly aligned for either. And _that_ means that...
printf("Doing setjmp 2...\n");
setjmp(p_x->s_jbuf);

....passing this quite probably incorrectly aligned pointer to setjmp()
causes undefined behaviour.

You can solve this by either not adding anything to malloc()'s return
value, or adding a number of bytes which you know will preserve correct
alignment.
In the first case, you write just

struct mystruct *p_x = malloc(sizeof *p_x + ALLIGN);

and use the last ALLIGN (btw, the correct spelling is ALIGN) bytes for
whatever extra data you need instead of the first ones. However, do note
that if you use them for anything but chars, you end up with the same
potential alignment problems as you have now.

In the second case, you need to find out a safe value for the addition.
The one value which you are guaranteed is safe for struct mystruct is
sizeof(struct mystruct); this _must_ be good enough, since in an array,
each element is sizeof(struct mystruct) beyond the previous. So in this
case, you write

#define ALIGN sizeof(struct mystruct)
struct mystruct *p_x=
(void *)((char *)malloc(sizeof *p_x+ALIGN) + ALIGN);

or even, more simply,

struct mystruct *p_x=malloc(2*s izeof *p_x)+1;

since you're now in effect dealing with an array of two struct elements.
Note that in this case, as in your original code, you need to remember
to subtract the extra amount of memory when you free() it.

This problem is not specific to either setjmp() or your implementation,
btw. Your code is simply not conforming; it would cause problems for any
type with a strict enough alignment, on any implementation that cares
about alignment.

Richard

[Peter Smithson]

In article <41************ ***@news.indivi dual.net>, rlb@hoekstra-
uitgeverij.nl says...

struct mystruct *p_x = (void *)
((char *)malloc(sizeof (struct mystruct)+ALLIG N)+ALLIGN);
*Kablooie!* Yes, that was the sound of the alignment of your struct
being blown to bits. You do not know that a jmp_buf needs to be aligned

<snip>

Yes I know. As I said, it's obvious when I write it like that but in the
real app there was a structure set-up in some other module which called
another function which called another etc. etc. Even when we fixed our
own memory allocation routine to allocate to 16 bytes, there was a bit
of code elsewhere where we allocated the memory, then put two structures
in there. The first structure used up a multiple of 8 bytes, the 2nd
one had the jmp buffer in it. (lucky that the 1st structure was that
size - we could have had this problem on a machine requiring 8 byte
alignment!)

This has been fixed by using the same little bit of code used in the
memory allocation routine to ensure alignment in this area too. (similar
to what you posted)

It was a small example program based on an application consisting of
100's of source modules developed by about 10 or 20 developers over 10
years. It's quite hard to track it down and be sure your example
program matches the code - by then you've cracked it so there's not much
point in talking about the example code.
(btw, the correct spelling is ALIGN)
Thanks - I thought it was me! I couldn't find the code on an initial
search as I looked for ALIGN and then found it spelt ALLIGN!
#define ALIGN sizeof(struct mystruct)

That works only if your memory allocation routine is used just for the
one structure.

What would be nice is a way of figuring out what we should define ALIGN
as. We must have found 8 to be enough before but now we need 16.

How could we define it such that it works for any platform/OS? The code
run's on virtualy any current (and not so current) UNIX system and
Windows NT/2000/XP.

I'm sure the proper answer is to re-write the allocation routine so that
it calls malloc for every allocation and generaly re-write it so that it
can keep track of memory the same way it does now. But that's not
really practical.

Cheers

Peter
--
http://www.beluga.freeserve.co.uk

[Chris Torek]

In article <news:MP******* *************** **@News.Individ ual.NET>
Peter Smithson <pg************ **********@yaho o.co.uk> wrote:

... What would be nice is a way of figuring out what we should define ALIGN
as. We must have found 8 to be enough before but now we need 16.

How could we define it such that it works for any platform/OS?
You cannot.

I consider this a flaw in the C standards -- they do not provide
enough information to the implementation' s user to allow him (or
her, or it) to write "malloc-like" routines.

One workaround is to rely on something "above and beyond" the C
standard, such as "POSIX" or "Unix" or "Linux" (are there any actual
Linux standards yet?) or "defines we supply ourselves every time
we port our code to another machine". The last of these gives you
the most control, but requires the most work.
The code run's on virtualy any current (and not so current) UNIX system and
Windows NT/2000/XP.

Note that x86 boxes now sometimes require 16-byte alignment too
(for SSE instructions). There may be systems that require 32-byte
alignment, or even larger, either now, or in the future. (Powers
of two seem likely to remain popular for the next century at least
though. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Stephen Sprunk]

"Dennis Handly" <dh*****@convex .hp.com> wrote in message
news:41******** @usenet01.boi.h p.com...

Peter Smithson (pg************ **********@yaho o.co.uk) wrote:
: I've read this page -
: http://devrsrc1.external.hp.com/STK/impacts/i634.html
: but don't understand it.

: "Non-standard usage of setjmp() and longjmp() could result in
: compatibility problems. The contents of the jmp_buf buffer are specific
: to the architecture and compilation environment. For example, this
: includes using jmp_buf in a user-defined structure and passing jmp_buf
: structures across relocatable objects. Objects built using these
: functions may not be supported for future architectures, such as IPF."
: What does it mean about passing jmp_buf across a relocatable object?

I don't remember quite what we were trying to say wasn't portable.
Or why relocatable objects are mentioned?

It's possible the compiler folks knew their implementation had problems, and
they were able to work around them somehow in static objects and within a
single relocatable object, but not across different relocatable objects.

Exactly what kind of implementation glitch this might be, particularly when
it's specific to a single compiler on a single platform, is beyond me. But
it'd be interesting to hear from the HP-UX compiler guys lurking here what
it is...

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Peter Smithson]

In article <cn*********@ne ws4.newsguy.com >, no****@torek.ne t says...

Note that x86 boxes now sometimes require 16-byte alignment too
(for SSE instructions). There may be systems that require 32-byte
alignment, or even larger, either now, or in the future. (Powers
of two seem likely to remain popular for the next century at least
though. :-) )

I didn't know that - interesting.

I had an idea for the alignment question though it isn't a #define -

struct mystruct
{
char firstbyte;
jmp_buf jmpbuf;
};
int GetAlignment()
{
struct mystruct a;

return &a.jmpbuf - &a.firstbyte ;
}

I've not compiled that so there might be a mistake but you get the idea.
It assumes that a jump buffer requires the most alignment.

--
http://www.beluga.freeserve.co.uk

[Richard Bos]

Peter Smithson <pg************ **********@yaho o.co.uk> wrote:

In article <41************ ***@news.indivi dual.net>, rlb@hoekstra-
uitgeverij.nl says...

#define ALIGN sizeof(struct mystruct)
That works only if your memory allocation routine is used just for the
one structure.

You mean there could be different structs following your 8 byte header?
That's dreadful. It's a miracle it didn't break earlier.
What would be nice is a way of figuring out what we should define ALIGN
as. We must have found 8 to be enough before but now we need 16.

How could we define it such that it works for any platform/OS?

The only way I can think of is to take all possible structs that you
could put in that bit of memory, compute the LCM of all their sizes, and
use that. Best done at run-time, so you won't get caught when one of the
structs changes size due to a new compiler or something like that. It's
still hardly recommendable.

Richard

[Peter Smithson]

In article <41************ ****@news.indiv idual.net>, rlb@hoekstra-
uitgeverij.nl says...

Peter Smithson <pg************ **********@yaho o.co.uk> wrote:

In article <41************ ***@news.indivi dual.net>, rlb@hoekstra-
uitgeverij.nl says...

#define ALIGN sizeof(struct mystruct)

That works only if your memory allocation routine is used just for the
one structure.

You mean there could be different structs following your 8 byte header?
That's dreadful. It's a miracle it didn't break earlier.

Well the routine is general. One example had a structure at the start
with a size divisible by 8 which was very lucky that it was a nice size.
We've not had to align to more than 8 bytes so far. I agree though -
pretty dreadful. If someone had added a 4 byte integer to that
structure then it would have broken the code as we needed 8 byte
alignment for some other platform (who knows which one now!).

Other places the allocation routine is called, there is no header
structure and the structure will arbritrary. This is more normal. I
think the programmer of the other code was just trying to avoid two
calls to the allocation code out of laziness (possibly - I've not looked
at the code but it's been dealt with).

Thanks for your replies.

Peter

--
http://www.beluga.freeserve.co.uk

[Dennis Handly]

Keith Thompson (ks***@mib.org) wrote:
: I'm not sure what you mean by "pack", but I'm guessing you're
: referring to an implementation-defined #pragma that causes struct
: members to be packed more tightly than they normally would be.

Exactly

: I would expect the compiler to do whatever it needs to to make obj.d
: accessible as a double.

Yes for the compiled code that sees that pragma.
But not for libc, which doesn't know about the pragma.
Though a warning would be nice.

: But as it turns out this doesn't necessarily mean the compiler is broken.

Right, the user code is broken. ;-)