https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #12 from Ian Lance Taylor ---
Thanks, that part should now be fixed also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #11 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:181f877b6c0e365c940b117c306e7309e19ffd89
commit r11-3064-g181f877b6c0e365c940b117c306e7309e19ffd89
Author: Ian Lance Taylor
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #10 from Francois-Xavier Coudert ---
Hi Ian,
There is still the issue in comment #1: none of the mechanisms for finding the
executable path are currently working on darwin (at least in the circumstances
I am testing in).
- state->fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
Ian Lance Taylor changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #8 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:488e9e6dea3262a11307592e9aad87a97c8d
commit r11-3055-g488e9e6dea3262a11307592e9aad87a97c8d
Author: Ian Lance Taylor
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #7 from Francois-Xavier Coudert ---
Actually we're not using the other members. So how about simply:
diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..7f093f309fb 100644
--- a/libbacktrace/macho.c
+++ b/libb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #6 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #4)
from fat.h
FAT headers are always written bigendian
* at least there's no statement revoking that in the section on FAT64
* it doesn't seem that the FA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #4 from Francois-Xavier Coudert ---
I've identified the issue and found a fix. The problem is in the calculation of
the offset when !is_64. The current code is take the uint32_t offset value,
casting it into a uint64_t, then calling b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #3 from Francois-Xavier Coudert ---
In macho_add_fat(), the code correctly identifies 2 archs, with the right types
(first i386, then x86_64). It's then calling macho_add() for the x86_64 arch,
with an foffset of 0xb000, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #2 from Francois-Xavier Coudert ---
I've gone a bit further with this, using the patch in comment #1 to fix the
executable path issue. I am now trying to make the backtrace work within
libgfortran, on a case with a known runtime error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96973
--- Comment #1 from Francois-Xavier Coudert ---
Continuing to debug, I've added a darwin-specific implementation of
getexecname() with this patch:
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index cc1011e8b5d..3e4161e47c6 1006
12 matches
Mail list logo
