-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
__ehInit is added to each and every object #8
Comments
There is at least one failed case due to this difference: http://trac.netlabs.org/odin32/ticket/109. |
will try look at this today |
odin built fine with my local build of gcc 4.7.3 |
Please see the comment in there. And also, can you confirm that your local build also produces |
What's the best way to check if local objects include that symbol? Cheers, Paul
|
The simplest way is to search for |
[U:\DEV\odin32\trunk\out\os2.x86\release\obj\pe]cat -v pe.o | grep -o [U:\DEV\odin32\trunk\out\os2.x86\release\obj\pe] On Mon, Jun 9, 2014 at 7:53 PM, Dmitriy Kuminov
|
FWIW, I also get no references to ehInit with 4.7.2. Poking about, it appears that this symbol and ___eh_frame are somehow related to DWARF2 debug data based on what I see in dwarf2out.c. |
Well, this means that something's wrong with the RPM build... AFAIR |
Paul, is there any update on this topic? WRT 4.9.0, for instance. |
As I recall, I couldn't reproduce locally, hence nothing from me. Cheers, Paul
|
using -fno-asynchronous-unwind-tables produces a object file without unwinding table (so without eh_frame and _ehInit). |
So, in short, we need to find out why |
I got the %sil error too. I fixed it with:
|
@ydario reports that configuring gcc with @psmedley can you confirm that your own builds of gcc use Why Also, I found that our |
Above changeset is wrong because target_os == os2-emx The difference is made by --enable-frame-pointer, which restores Even without unwinding tables C++ exceptions are still working, Paul confirmed this with some KO c++ source tested. |
BTW even setting the correct target os, the OS/2 build is still adding frame pointers to code. Only adding -fomit-frame-pointer effectively removes them. |
And for the bad news stream, I have to say that the newly build stdcpp6.dll does not catch exceptions thrown by code built with gcc 4.7.3, current AOO binaries shows this issue. And it is not related to above flags, since happens with all kind of builds of 4.9.2 sources. Stack trace shows that stdcpp6.dll it is unable to unwind the stack... Function | Part | Source | Module |
@ydario okay about the wrong platform spec, but sorry I don't understand you so far as some of your statements contradict each other. My question: does only adding |
What about the name for |
interaction between these flags is handled in gcc/config/i386/i386.c #3771, see x_flag_asynchronous_unwind_tables. initially set to 2, it became !USE_IX86_FRAME_POINTER at #3775 (result 1). but maybe something else is triggered, I'm not sure everything is here. |
for stdcpp6, we changed name for 4.7.3 because 473 build was not compatible with older 442 dll (stdcpp.dll). So I think we got again the same issue saw in the past. |
You still didn't answer my question regarding Next, regarding Regarding the version. I couldn't quickly find where they set the version suffix in 4.4.x, but in 4.7.x they switched to libtool's version-info and according to that the major suffix is not changed between 4.7 and 4.9. Which means that officially the DLL must be binary compatible. What exactly makes it incompatible in our case? |
ok, I got the stdcpp issue: my new stdcpp6.dll was linked against gcc492.dll; since my bot was still holding the static lib, I used dllar to produce stdcpp6.dll with current runtime, e.g. linked with gcc473.dll: AOO starts correctly now! I got the idea after looking __cxxabiv1::__cxa_throw() code in src\libstdc++-v3\libsupc++\eh_throw.cc; the call to __cxa_begin_catch (&header->exc.unwindHeader); goes to the gcc runtime dll. I remember during OOo development that exception handling must be driven by a single dll, otherwise exceptions were not able to cross DLLs. At that time I wrote the first stdc432.dll code to get exceptions working. |
Yes, it's known that gcc.dlll takes care of unwinding. Regarding ABI, this proves that what I wrote above is correct (JFYI): https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html. |
Now we have a problem: how to get the unwinding code in the same dll... a program built with two different runtimes cannot correctly handle exceptions... I think it does not handle exceptions at all... |
According to the GCC ABI reference mentioned above, libgcc is meant to be binary compatible among all gcc 3.x and gcc 4.x releases. This suggests us that we should name it gcc1.dll (to follow the common ABI and naming rules) and not change this name until compatibility officially breaks upstream. Once we have However, to make work old code that we already built with gcc473 (which uses In order to create the wrapper we should take the approach which Knut uses for libc. But I think this wrapper should be built at RPM level (i.e. patches + .spec) rather than placed within the GCC code base — it has nothing to do with gcc itself (it should always produce gcc1.dll, as on other platforms), it's about our house keeping. And since we create ZIPs for every RPM, this forwarding wrapper will be also available as ZIP for anyone not using RPM. |
Yuri, about As for
to
|
--enable-frame-pointer is not set by default, adding it changes completely gcc code generation. |
Please look here https://github.com/psmedley/gcc/blob/gcc-4_9-branch-os2/gcc/configure#L11494:
Given that |
Hi guys, On 22/01/15 21:30, Dmitriy Kuminov wrote:
Unfortunately I can't recall. I can say though that this change was made Obviously I was trying to fix something, but right now I don't recall |
I'm sure all default gcc builds are not using enable-frame-pointer, the code generation always wrote unwind tables. I know the above snippet is wrong, but this did not enable the frame pointer, probably this option does something else. I built gcc 4.9.0 and 4.9.2 many times, all added unwind tables until I used --enable-frame-pointer in configure script. |
We are now moving to gcc1 naming scheme, as per gcc specs. RPM is building forwarders to gcc1 for gcc446.dll and gcc473.dll; since ABI is compatible for all gcc 3.x and 4.x builds, I think we could gather all def files for existing runtimes and transform them as forwarders. This will allow us to get rid of different runtimes floating around and build them in a single place. Unfortunately, since gccXXX has been always built using ordinals exports only, we need the .def file to prepare the forwarder. The def file can be created from libgcc_so_d.a too, converting it first to .lib, then .imp and finally .def |
Yuri, the only thing Re |
I did the unwind fix in 4712cb7. This is to make sure we don't use unwind tables even if |
Finally, I found out why The thing is that if you forget to use With this, I consider this issue as resolved. |
For some reason, GCC 4.7.3 adds a reference to
__ehInit
(defined ingcc/config/i386/emx-eh.c
) to each and every generated C and C++ source file. There is no need to refer to it in regular object files. This is part of CRT startup code (whose job is to initialize exception handling and such).The previous GCC versions (e.g. 4.4.6) don't put this symbol into object files.
This looks like a 4.7.3 regression then.
The text was updated successfully, but these errors were encountered: