This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Huge .eh_frame section with C++ exceptions, --gc-sections discards too much

Hallo Alan:

> Thes hacks I added in 2005 to keep .gcc_except_table were superceded
> when Richard Sandiford added support for marking .gcc_except_table
> from kept .eh_frame FDEs 2007-12-15.? This should result in
> --gc-sections removing unused .gcc_except_table sections (and in used
> ones being kept, hence my remark about not needing KEEP in a linker
> script).
> Is the linker emitting any warnings?? Can you provide a testcase for
> us to look at?

I'm afraid this is a proprietary app integrated in a complex build system and with a custom operating system, so it would take a long time to extract a short demo project. I'll keep it in mind, maybe when I'm more familiar with PowerPC cross-compilers and so on I'll try to provide a test case from scratch. For the time being, I'm just refraining from using C++ exceptions.

But this is something that no doubt other people with more experience can confirm, may the same eCos developer that was involved back then?

I am getting no linker warnings whatsoever. In case it helps, I have also observed this behaviour with an older GCC 4.5.3 / binutils 2.21. As long as I am aware, GCC/binutils can use 2 types of exception information, a newer one with "--eh-frame-hdr" (which I am not using), and the older type I am using (which sorts the exception tables on first touch, when the first exception is thrown).

? R. Diez

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]