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

[Richard Bos]

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. 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.
Neither of these restrictions are valid in ISO C. There's nothing in the
Standard that I can find that forbids using a jmp_buf as a member of a
struct, and "across relocatable objects" doesn't even make sense in an
ISO C context.
Objects built using these
functions may not be supported for future architectures, such as IPF."

If the implementation doesn't support putting a jmp_buf member in a
struct, it is not a compliant ISO C implementation.

Richard

[Chris Torek]

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

http://devrsrc1.external.hp.com/STK/impacts/i634.html [snippage - that page says, in part:] "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.

In article <41************ ****@news.indiv idual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:Neither of these restrictions are valid in ISO C. There's nothing in the
Standard that I can find that forbids using a jmp_buf as a member of a
struct, and "across relocatable objects" doesn't even make sense in an
ISO C context.
Reading the original page (and then "reading between the lines" as
the saying goes), what they really mean is that compiling to .o files
using *different compiler flags*, then trying to link those .o files
together, may not work right:

% cc -do_setjmp_one_w ay -c foo.c
% cc -do_setjmp_anoth er_way -c bar.c
% cc -o broken foo.o bar.o

could produce an executable that does not function correctly. But
note that this is no different in principle from, e.g.:

% foocorp_cc -c foo.c
% barcorp_cc -c bar.c
% bazlink -o broken foo.o bar.o

where the compilers from FooCorp and BarCorp are not compatible with
each other, so that no matter how clever the BazCorp linker is, the
final executable remains broken.
If the implementation doesn't support putting a jmp_buf member in a
struct, it is not a compliant ISO C implementation.

Indeed -- but again, the "between the lines" reading suggests that
different compiler flags cause the size of the data structure to
change:

% cat foo.c
#include <setjmp.h>
#include <stddef.h>
#include <stdio.h>

struct S { jmp_buf jb; int x; };
void bar(void);

int main(void) {
printf("offset of x in foo.c: %lu\n",
(unsigned long)offsetof(s truct S, x));
bar();
return 0;
}
% cat bar.c
#include <setjmp.h>
#include <stddef.h>
#include <stdio.h>

struct S { jmp_buf jb; int x; };

void bar(void) {
printf("offset of x in bar.c: %lu\n",
(unsigned long)offsetof(s truct S, x));
}
%

Compile these two files to "relocatabl e format" (.o files) using
various compiler flags, then link and run them, and the output will
be something like (total guesses at the offsets here):

% ./a.out
offset of x in foo.c: 24
offset of y in bar.c: 32

In other words, the contents of <setjmp.h> *change* depending on
how the compiler is invoked. Each set of compilation-flags (or
some sub-groups of compilation flags) thus amount to separate
implementations -- and you have to use one single implementation,
not several different ones, to compile all your source code.

What this really implies is a versioning nightmare, in which
apparently-compatible object files are not in fact compatible after
all -- and there is no way to tell simply by inspecting the .o
files. (What is needed is a compiler directive -- a #pragma or
equivalent -- that drops version information into the object files,
so that various tools can tell you that foo.o uses "setjmp version
A" while bar.o uses "longjmp version B", for instance. Of course,
the .o-file format needs to have room for such information as well,
and then the tools need to look for it and diagnose mismatches.)
--
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.

[Dennis Handly]

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 could be referring to the fact that the user-defined struct must be
allocated on a larger alignment on IPF. And jmp_buf must be larger.
And you can't use the pack pragma on the struct.

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

PIC code is the default on IPF.

: We're getting core dumps when we do a setjmp on a jmp_buf who's address
: is returned in another module.

Abort on the setjmp? Or the longjmp? What's the signal?

If you have an abort on setjmp, you probably aren't allocating the
right size or alignment for jmp_buf. jmp_buf must be 16 byte aligned.

: 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

It doesn't want you to misalign it. malloc aligns on 16 bytes.

: But I'm not sure about this "across relocatable objects" - what does
: that mean?
: Peter

This concern may be obsolete. Possibly a concern before the IPF
implementation was finalized?

From: rl*@hoekstra-uitgeverij.nl (Richard Bos)
Neither of these restrictions are valid in ISO C. There's nothing in the
Standard that I can find that forbids using a jmp_buf as a member of a
struct, and "across relocatable objects" doesn't even make sense in an
ISO C context.
True. I think it was more in terms of compatibility and a porting issue.
If the implementation doesn't support putting a jmp_buf member in a
struct, it is not a compliant ISO C implementation. Richard

But Peter's program doesn't work. So he is violating something, probably
with some evil cast or ignored warning.
From: Chris Torek <no****@torek.n et>
Reading the original page (and then "reading between the lines" as
the saying goes), what they really mean is that compiling to .o files
using *different compiler flags*, then trying to link those .o files
together, may not work right:
Probably something like that. Using the pack pragma will mess things up
too.
be something like (total guesses at the offsets here):
Try: typedef __float80 jmp_buf[320/4];
(What is needed is a compiler directive -- a #pragma or
equivalent -- that drops version information into the object files,

Yes.

[Richard Bos]

Chris Torek <no****@torek.n et> wrote:

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

http://devrsrc1.external.hp.com/STK/impacts/i634.html [snippage - that page says, in part:] "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.
In article <41************ ****@news.indiv idual.net>,
Richard Bos <rl*@hoekstra-uitgeverij.nl> wrote:

Neither of these restrictions are valid in ISO C. There's nothing in the
Standard that I can find that forbids using a jmp_buf as a member of a
struct, and "across relocatable objects" doesn't even make sense in an
ISO C context.
Reading the original page (and then "reading between the lines" as
the saying goes), what they really mean is that compiling to .o files
using *different compiler flags*, then trying to link those .o files
together, may not work right:

% cc -do_setjmp_one_w ay -c foo.c
% cc -do_setjmp_anoth er_way -c bar.c
% cc -o broken foo.o bar.o

could produce an executable that does not function correctly.

Oh, good grief... "No shit, Sherlock." They could've said that, then.
But note that this is no different in principle from, e.g.:

% foocorp_cc -c foo.c
% barcorp_cc -c bar.c
% bazlink -o broken foo.o bar.o
Nor is setjmp() any different from many other Standard functions, or
indeed your own. Try creating a struct in an function compiled with
#pragma packed, and then filling it in a function compiled without...
great way to smash the stack.
If the implementation doesn't support putting a jmp_buf member in a
struct, it is not a compliant ISO C implementation.

Indeed -- but again, the "between the lines" reading suggests that
different compiler flags cause the size of the data structure to
change:

Again, no kidding. They really could've phrased that a bit more clearly.
And again, in what way is jmp_buf different from, say, FILE?
What this really implies is a versioning nightmare, in which
apparently-compatible object files are not in fact compatible after
all -- and there is no way to tell simply by inspecting the .o
files. (What is needed is a compiler directive

Or proper project management. Granted, in the case where you can be
called upon to use someone else's .os, that may imply a bit of
paperwork, but really...

Richard

[Peter Smithson]

In article <41********@use net01.boi.hp.co m>, dh*****@convex. hp.com
says...

Thanks for that reply and all the others.

I think the executive summary is that we are fine as long as we align on
16 byte boundaries.

So we must be doing something silly. The guy who looked at this in more
detail says he changed our allocation code to align to 16 bytes but I
wonder if he made a mistake.

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

[Peter Smithson]

In article <MP************ ************@Ne ws.Individual.N ET>,
pg************* *********@yahoo .co.uk says...

In article <41********@use net01.boi.hp.co m>, dh*****@convex. hp.com
says...

Thanks for that reply and all the others.

I think the executive summary is that we are fine as long as we align on
16 byte boundaries.

So we must be doing something silly. The guy who looked at this in more
detail says he changed our allocation code to align to 16 bytes but I
wonder if he made a mistake.

Yep, I just changed our #define ALLIGN 8 to read #define ALLIGN 16 and
it all worked fine. (something used in our memory allocation code).

Still, it's good to know that we're not going to come across some other
problem due to the thing about relocatable objects which we didn't
understand.

Thanks again.

Peter

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

[Keith Thompson]

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

Peter Smithson (pg************ **********@yaho o.co.uk) wrote: [...] : 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

It doesn't want you to misalign it. malloc aligns on 16 bytes.

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

From: rl*@hoekstra-uitgeverij.nl (Richard Bos) [...]If the implementation doesn't support putting a jmp_buf member in a
struct, it is not a compliant ISO C implementation.

Richard

But Peter's program doesn't work. So he is violating something, probably
with some evil cast or ignored warning.

Either Peter's program is violating something, or the implementation
is buggy.

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

[Peter Smithson]

In article <ln************ @nuthaus.mib.or g>, ks***@mib.org says...

It doesn't want you to misalign it. malloc aligns on 16 bytes.

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

It seems to do that for us. Now that I've looked at the application in
detail it's embarissingly obvious when you write a test program to
demonstrate. The first setjmp below works, the 2nd one doesn't - we
don't always use malloc directly and our allocation code was using 8
bytes to align to.

#include <stdio.h>
#include <setjmp.h>
#include <malloc.h>

struct mystruct {
char abc;
jmp_buf s_jbuf;
};

#define ALLIGN 8

int main()
{
struct mystruct s_x;
struct mystruct *p_x = (void *)
((char *)malloc(sizeof (struct mystruct)+ALLIG N)+ALLIGN);

printf("Doing setjmp 1...\n");
setjmp(s_x.s_jb uf);
printf("Doing setjmp 2...\n");
setjmp(p_x->s_jbuf);
}
--
http://www.beluga.freeserve.co.uk

[Dennis Handly]

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. :-(