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
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
do
> 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
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 the
> 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 libbacktrac
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 '
> 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:lin
On Sun, Aug 23, 2015 at 11:14 PM, FX 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 in 80 colum
> 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)
On Fri, Aug 14, 2015 at 5:18 PM, FX 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 libbackt
On Fri, Aug 14, 2015 at 1:32 AM, FX 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)
This change (an
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 libback
13 matches
Mail list logo
