On 10/20/10 19:17, "C. Bergström" wrote:
Ali Bahrami wrote:
On 10/20/10 09:42, "C. Bergström" wrote:
Hi
Does anyone have time to take a look at this test case..
# Example
g++ -m64 -o test test.s
~$ ./test
terminate called after throwing an instance of 'int'
Abort
There's some problem with the unwind tables, but I can't spot it.. Something is
different between sol and linux that's causing this..
Thanks
./C
Original code
------------------------------
cat test.cpp
int main() {
try {
throw (int)10;
}
catch(int i) {
return i;
}
return 0;
}
_______________________________________________
tools-compilers mailing list
[email protected]
I presume that you're hitting this:
% g++ -m64 -o test test.s
ld: fatal: file /var/tmp//ccsAaORD.o: section [8].eh_frame: section type is
SHT_PROGBITS: expected SHT_AMD64_UNWIND
collect2: ld returned 1 exit status
That error is the result of the fix I did for
6931044 ld should not allow SHT_PROGBITS .eh_frame sections on amd64
in snv_137. I can get your code to compile by changing line 171 from
.section .eh_frame, "a",@progbits
to
.section .eh_frame, "a",@unwind
giving
% g++ -m64 -o test test.s
% ./test
%
g++ on solaris does not use progbits for that, so I'm puzzled as to how
this piece of assembler was created. Was it created under Linux, where
they seem to accept PROGBITS as a valid section type for unwind sections
on amd64?
I'm beginning to think the fix for 6931044 needs to be changed from rejecting
progbits unwind sections, to quietly accepting them and treating them as
amd64_unwind. Anything you can tell me about how this code came into
being would be helpful. Thanks...
Hi Ali,
This is awesome information and helped me get to the bottom of my problem..
When you can't step into unwind *at all* and dbx dumps core on a trivial
example it makes things pretty difficult to debug. (gdb simply wouldn't step
into the throw and I didn't try mdb)
Test server was snv_111b
If there's no standard to dictate correct behavior then issue a warning or
reject it.. The old behavior isn't good, but can't change that now and there's
no need imho to mirror Linux just for the sake of mirroring linux..
Thanks
./C
Great news --- I'm glad you're up and running again.
If you built this on snv_111b, then I'm going to guess that your
original build failed because it had 2 .eh_frame sections, one of
type SHT_PROGBITS, and the other of type SHT_AMD64_UNWIND. That's
very broken, and was the issue that led to CR 6931044. You can use
'elfdump -c' to verify that.
If that's it, then the problem is that the exception frames found in
the progbits section are being ignored by the runtime, because they
are not found within the .eh_frame_hdr section.
This usage happens, I think, because on non-amd64 platforms, the GNU
tools use the same .eh_frame/.eh_frame_hdr mechanism, but as there is
no special section type, they use SHT_PROGBITS. A person, writing
assembly code, might not think about this, and use progbits rather
than amd64_unwind. Apparently the GNU ld accepts this usage and makes
it work, and perhaps we should also.
So, was this code written by hand? I ask, because previous to this, the
only other times I've seen this issue, it was related to some hand written
assembly code that's delivered with gcc itself. As far as we know, the code
generated by gcc (and g++) use the unwind section type for Solaris, as
they should. If the compilers are emitting this progbits usage, then I
can expect to see more of this issue... :-)
Thanks for the information...
- Ali
_______________________________________________
tools-compilers mailing list
[email protected]
