关于Itanium HPUX上setjmp的问题。 [英] Question about setjmp on Itanium HPUX.
问题描述
我读过这个页面 -
http://devrsrc1.external.hp.com/STK/impacts/i634.html
但不明白。这是文本 -
非标准使用setjmp（）和longjmp（）可能导致
兼容性问题。 jmp_buf缓冲区的内容对于体系结构和编译环境是特定的
。例如，这个
包括在用户定义的结构中使用jmp_buf并在可重定位目标文件中传递jmp_buf
结构。使用这些
函数构建的对象可能不支持未来的体系结构，例如IPF。
在可重定位目标文件中传递jmp_buf意味着什么？
我们有一个包含多个源模块的库。我们使用
位置独立选项进行编译，因为我们有时会从这个库中创建一个共享库。
我们得到了当我们在jmp_buf上对一个地址执行setjmp核心转储
在另一个模块中返回。如果我们在另一个模块中单独malloc每个
缓冲区（而不是使用它们来自
结构），似乎工作正常。我可以看到它说这不会在网页上工作
- 它不希望我们在用户定义的结构中有一个jmp_buf（用于
某种原因）。
但我不确定这个跨越可重定位的对象 -
是什么意思？我们不能在一个简单的测试程序中重新创建它。 （两个
源模块一起编译）。
有什么想法吗？
谢谢。
彼得
-
http://www.beluga.freeserve.co.uk
推荐答案
Peter Smithson< pg ***** *****************@yahoo.co.uk>写道：
Peter Smithson <pg**********************@yahoo.co.uk> wrote:
我读过这个页面 -
http://devrsrc1.external.hp.com/STK/impacts/i634.html
但不要'不明白。这是文本 -
非标准使用setjmp（）和longjmp（）可能会导致兼容性问题。 jmp_buf缓冲区的内容对于体系结构和编译环境是特定的。例如，这包括在用户定义的结构中使用jmp_buf并在可重定位目标文件中传递jmp_buf
结构。
这些限制都没有在ISO C中有效。
标准中没有任何内容我可以找到禁止使用jmp_buf作为成员一个
结构，以及跨越可重定位目标的对象在
ISO C上下文中甚至没有意义。
未来的体系结构（如IPF）可能不支持使用这些功能构建的对象。
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."
如果实现不支持将jmp_buf成员放在
结构中，则它不是兼容的ISO C实现。
Richard
If the implementation doesn''t support putting a jmp_buf member in a
struct, it is not a compliant ISO C implementation.
Richard
> Peter Smithson< pg ************** ********@yahoo.co.uk>写道：
>Peter Smithson <pg**********************@yahoo.co.uk> wrote:
http://devrsrc1.external.hp.com/STK/impacts/i634.html
[snippage - 该页面部分说明：]" setjmp的非标准用法（）和longjmp（）可能导致兼容性问题。 jmp_buf缓冲区的内容对于体系结构和编译环境是特定的。例如，这包括在用户定义的结构中使用jmp_buf并在可重定位目标文件中传递jmp_buf
结构。
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.
文章< 41 **** ************@news.individual.net>，
Richard Bos< rl*@hoekstra-uitgeverij.nl>写道：这些限制都没有在ISO C中有效。我可以发现，
标准中没有任何内容禁止使用jmp_buf作为
结构的成员，并且跨越可重定位的对象 ;在ISO C环境中甚至没有意义。
阅读原始页面（然后在行之间阅读，因为
俗话说），他们真正的意思是编译为.o文件
使用*不同的编译器标志*，然后尝试将这些.o文件
链接在一起，可能无法正常工作：
％cc -do_setjmp_one_way -c foo.c
％cc -do_setjmp_another_way -c bar.c
％cc -o broken foo.o bar.o
可能会产生无法正常运行的可执行文件。但
请注意，这与原则上没有区别，例如：
％foocorp_cc -c foo.c
％barcorp_cc -c bar.c
％bazlink -o broken foo.o bar.o
其中FooCorp和BarCorp的编译器与
彼此，所以无论BazCorp链接器多么聪明，
最终可执行文件仍然存在。
如果实现不支持put在
结构中的jmp_buf成员，它不是兼容的ISO C实现。
In article <41****************@news.individual.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_way -c foo.c
% cc -do_setjmp_another_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.
确实 - 但同样，在行之间阅读建议
不同的编译器标志会导致数据结构的大小变化：
％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（" x of offset in foo.c：％lu \ n"，
（unsigned long）offsetof（struct S，x））;
bar（）;
返回0;
}
％cat bar.c
#include< setjmp.h>
#include< stddef.h>
#include< stdio.h>
struct S {jmp_buf jb; int x; };
void bar（void）{
printf（" bar.c中x的偏移量：％lu \ n"，
（无符号长）offsetof（struct S，x））;
}
％
编译这些两个文件为可重定位格式 （.o文件）使用
各种编译器标志，然后链接并运行它们，输出将是/ b $ b是类似的（这里的偏移总猜测）：
％。/ a.out
foo.c中x的偏移量：24
偏离y的bar.c：32
换句话说，< setjmp.h>的内容*更改*取决于
如何调用编译器。每组编译标志（或者一些子组的编译标志）因此相当于单独的实现 - 并且你必须使用一个单独的实现，
不是几个不同的，来编译你的所有源代码。
这真正暗示的是一个版本化的噩梦，其中
显然
all之后，兼容的目标文件实际上并不兼容 - 并且无法通过检查.o
文件来判断。 （需要的是编译器指令 - #pragma或
等价物 - 将版本信息丢弃到目标文件中，
以便各种工具可以告诉你例如，foo.o使用setjmp version
A而bar.o使用longjmp版本B。当然，
.o文件格式需要有空间获取这些信息，
然后工具需要查找并诊断不匹配。）
-
现实生活中：风河系统Chris Torek
美国犹他州盐湖城（40°39.22''N，111°50.29''W）+1 801 277 2603
电子邮件：忘了它 http：//web.torek。 net / torek / index.html
由于垃圾邮件发送者，阅读电子邮件就像在垃圾中搜索食物一样。
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(struct 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(struct S, x));
}
%
Compile these two files to "relocatable 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) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Peter史密森（pg**********************@yahoo.co.uk）写道：
：我读过这个页面 -
： http：/ /devrsrc1.external.hp.com/STK/impacts/i634.html
：但不明白。
： setjmp（）和longjmp（）的非标准用法可能会导致
：兼容性问题。 jmp_buf缓冲区的内容是特定的
：到架构和编译环境。例如，这个
：包括在用户定义的结构中使用jmp_buf并在可重定位目标文件中传递jmp_buf
：结构。使用这些
：函数构建的对象可能不支持未来的体系结构，例如IPF。
：在可重定位目标文件中传递jmp_buf意味着什么？
我不记得我们试图说的是不可移动的。
或者为什么提到可重定位的物体？
这可能是指用户定义的结构必须是在IPF上的更大对齐上分配的
这一事实。并且jmp_buf必须更大。
你不能在结构上使用pack pragma。
：我们有一个带有几个库的库其中的源模块。我们使用
编译：位置无关的选项，因为我们有时会从
创建一个共享库：这个库。
PIC代码是IPF上的默认值。
：当我们在jmp_buf上执行setjmp时，我们正在获取核心转储地址
：返回另一个模块。
在setjmp上中止？还是longjmp？什么是信号？
如果你在setjmp上中止，你可能没有为jmp_buf分配
正确的大小或对齐。 jmp_buf必须是16字节对齐。
：似乎工作正常如果我们在另一个模块中单独malloc每个
：缓冲区（而不是使用它们a
：结构）。我可以看到它说这不会在网页上工作
： - 它不希望我们在用户定义的结构中有一个jmp_buf
它不希望你错位。 malloc对齐16个字节。
：但我不确定这个跨越可重定位的对象 - 什么
：这是什么意思？
：Peter
这个问题可能已经过时了。在IPF
实施最终确定之前可能是一个问题？
Peter Smithson (pg**********************@yahoo.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?
来自： rl *@hoekstra-uitgeverij.nl （Richard Bos）
这些限制都没有在ISO C中有效。
标准中没有任何内容我可以发现禁止使用jmp_buf作为
结构的成员，以及跨越可重定位的对象在ISO C环境中甚至没有意义。
是的。我认为在兼容性和移植问题方面更多。
如果实现不支持将jmp_buf成员放在
结构中，则它不是兼容的ISO C实现。
Richard
但彼得的计划不起作用。因此他违反了某些内容，可能是因为某些邪恶的演员或被忽略的警告所致的b $ b。
来自：Chris Torek< no **** @ torek.net>
阅读原始页面（然后在行之间阅读，俗话说），他们真正的意思是编译成.o文件
使用*不同的编译器标志*，然后尝试将这些.o文件链接在一起，可能无法正常工作：
可能就是这样的。使用pack pragma会搞砸了
。
就像（在这里的偏移量总猜测）：
尝试：typedef __float80 jmp_buf [320/4];
（需要的是编译器指令 - #pragma或
等效 - 将版本信息丢弃到目标文件中，
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.net>
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.
这篇关于关于Itanium HPUX上setjmp的问题。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
