On the SPU, mmap is indeed not available. Before that change, it was still
possible to build libgfortran for SPU ...
Is the intent to now require mmap on every system that supports libgfortran,
or should use of mmap in libbacktrace be optional in some form?
The idea is that libbacktrace
FX Coudert wrote:
The idea is that libbacktrace should be able to build on all targets, at
least in a minimally-functional form:
https://gcc.gnu.org/ml/gcc/2015-08/msg00038.html
libgfortran should continue to build on all targets, even those that
don't have an mmap().
I see that there is
FX Coudert wrote:
PR libfortran/54572
* Makefile.def: Make libgfortran depend on libbacktrace.
* Makefile.in: Regenerate.
This causes GCC build to fail on SPU with the error:
/home/uweigand/dailybuild/spu-tc-2015-08-23/gcc-head/src/libbacktrace/mmapio.c:
In function
I guess we can always just hard-code that SPU does not have mmap, similar
to how Solaris is hard-coded to not have dl_iterate_phdr.
Would something like the below be OK (if it passes testing)?
Looks good to me, though I cannot approve it.
FX
On 08/24/2015 06:55 AM, Ulrich Weigand wrote:
FX Coudert wrote:
The idea is that libbacktrace should be able to build on all targets, at
least in a minimally-functional form:
https://gcc.gnu.org/ml/gcc/2015-08/msg00038.html
libgfortran should continue to build on all targets, even those that
Jeff Law wrote:
On 08/24/2015 06:55 AM, Ulrich Weigand wrote:
I guess we can always just hard-code that SPU does not have mmap, similar
to how Solaris is hard-coded to not have dl_iterate_phdr.
Would something like the below be OK (if it passes testing)?
Yes.
I've checked this in now.
On Fri, Aug 14, 2015 at 5:18 PM, FX fxcoud...@gmail.com wrote:
Use libbacktrace (instead of our own unwind-based code) to display
backtraces from libgfortran
upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer
approval)
Awesome! Looks good. I only have one small bikeshed request: Can you
make the output format match the existing code?
Problem with that is that ad the new backtrace uses full path for file names,
the one-line format easily wraps in 80 column and make the output harder to
read (in my opinion).
Ah, I didn't realize that. I guess you're right, it's better to split
the filename:linenumber to a separate line. But still, I think it's
clearer if you keep the in and at like the current code gdb
does. Thus, something like
#framenumber 0xADDRESS in funcname
at filename:linenumber
On Sun, Aug 23, 2015 at 11:14 PM, FX fxcoud...@gmail.com wrote:
Awesome! Looks good. I only have one small bikeshed request: Can you
make the output format match the existing code?
Problem with that is that ad the new backtrace uses full path for file names,
the one-line format easily wraps
Hello!
Use libbacktrace (instead of our own unwind-based code) to display backtraces
from libgfortran
upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer
approval)
2. In gcc/fortran/config-lang.in, add libbacktrace
On Fri, Aug 14, 2015 at 1:32 AM, FX fxcoud...@gmail.com wrote:
Use libbacktrace (instead of our own unwind-based code) to display backtraces
from libgfortran upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer approval)
Use libbacktrace (instead of our own unwind-based code) to display backtraces
from libgfortran upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer approval)
2. In gcc/fortran/config-lang.in, add libbacktrace to target_libs
Use libbacktrace (instead of our own unwind-based code) to display
backtraces from libgfortran
upon error or user request.
1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs
global reviewer
approval)
2. In gcc/fortran/config-lang.in, add libbacktrace to
14 matches
Mail list logo
