https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
Bug ID: 100446
Summary: GDB has problems reading GCC's debugging info level
-g3
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #3 from R. Diez ---
Regarding "shifting the blame", no worries, I am grateful for any help.
I suspect that there is more than 1 issue here. Could you take a look at the
following aspect mentioned in the GDB bug?
8<8<
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #5 from R. Diez ---
In a nutshell: "objdump --syms" does not show that symbol, probably because the
routine was inlined, but "readelf --debug-dump" does show it.
Thanks for your help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77488
R. Diez changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42579
--- Comment #12 from R. Diez ---
*** Bug 77488 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68605
--- Comment #4 from R. Diez ---
That is certainly a way to fix the crt0 nuisance. But it requires some specs
file black magic, so yet another thing to learn. And then you have to keep up
with GCC in case something changes around the specs files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #11 from R. Diez ---
> Has a solution been found for embedded systems with very limited resources?
> In this case for example, C++ exceptions can be disabled and this
> emergency pool not needed.
Contrary to popular belief, C++ exce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68606
--- Comment #13 from R. Diez ---
It is hard to automatically tell whether nobody else is using such a
statically-allocated emergency buffer. In my case, I am using C++ exceptions,
so the linker will probably always include the buffer.
My patch m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104299
Bug ID: 104299
Summary: Doc: stdio is not the only option in
--enable-cstdio=XXX
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104301
Bug ID: 104301
Summary: --enable-cstdio=stdio_pure not passed down to
libstdc++-v3
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98324
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #7 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
Bug ID: 107500
Summary: Useless atexit entry for ~constant_init in
eh_globals.cc
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #4 from R. Diez ---
The 'constant_init' wrapper with the 'union' inside is a contrived hack, isn't
it? We may as well use a different hack then.
How about a combination of '__attribute__ constructor' and 'placement new' like
this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #5 from R. Diez ---
I know very little about GCC, but it is a very smart compiler, so I am having a
hard time understanding how GCC could miss so many optimisations. After all,
even when compiling with little optimisation, GCC seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #8 from R. Diez ---
Why does this 'eh_globals' object have to use a constexpr constructor?
How does the current code avoid the "static initialization order fiasco"? If
the user defines his/her own static C++ objects, how is it guara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #9 from R. Diez ---
> [...]
> not just "turn on -Os and all the code gets removed".
I am sure that the solution is not as trivial as "turn on -Os". But, as an
outsider, it is hard to believe that it "takes non-trivial analysis of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
R. Diez changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #13 from R. Diez ---
>From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #16 from R. Diez ---
I am slowly arriving at a different conclusion.
"struct __cxa_eh_globals" has neither a constructor nor a destructor. Its
members are pointers or integers, so GCC will not have automatically generated
any constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #20 from R. Diez ---
I had to modify the patch slightly. I guess that union member "unsigned char
unused;" was removed after GCC 12.2 was released.
But otherwise, the patch does work, at least in my bare-metal scenario. The
atexit e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #23 from R. Diez ---
Many thanks for the fix.
If you backport it to GCC 12.x, I won't be able to complain so much. ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107500
--- Comment #24 from R. Diez ---
In case somebody else wants to patch their GCC 12.2, here is the
slightly-modified patch for convenience:
https://github.com/rdiez/DebugDue/blob/master/Toolchain/Patches/Gcc12EhGlobalsAtexit.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98992
R. Diez changed:
What|Removed |Added
CC||rdiezmail-gcc at yahoo dot de
--- Comment #1 f
25 matches
Mail list logo
