The relative order of multiple executable sections inside the executable
segment (distinct from nonexecutable read-only segment) is not important
to NaCl.
> For x86 Hurd, GCC has been specifying »-dynamic-linker /lib/ld.so« in
> LINK_SPEC since forever (1995, or earlier), and Debian glibc has had the
> following since forever (2002, or earlier):
>
> ifeq ($(DEB_HOST_GNU_SYSTEM),gnu)
> # Why doesn't the glibc makefile install this?
>
I've read through the MPX spec once, but most of it is still not very
clear to me. So please correct any misconceptions. (HJ, if you answer
any or all of these questions in your usual style with just, "It's not a
problem," I will find you and I will kill you. Explain!)
Will an MPX-using binary
As to the general case, I think float.h is probably the best choice
and stdarg.h probably just as good. It's been a very long time since
anything but GCC itself installed headers by those names.
For libc, I think always using $CC -E is fine. You don't need to bother
with the MSG_CHECKING and CAC
On Mon, Apr 30, 2012 at 9:02 AM, Richard Earnshaw wrote:
> It very much depends on your processor.
I suppose we are probably concerned primarily with recentish OMAP and
Tegra2 sorts of processors, but we are looking for generic good performance
solutions for ARMv7-A class processors.
> MOVW/MOVT
> Currently we use weak undefined symbol, foo, to do
>
> if (&foo != 0)
> foo is defined.
> else
> foo isn't defined.
>
> We want is to define foo as a secondary symbol so that
> we can always use foo without checking. If there is a primary
> one in a .o file and .so file, we will get the prim
Please provide an example that illustrates why you think you need this.
Thanks,
Roland
The change seems fine. But I think the log entry should have an explicit
pointer to the POSIX interpretation citation by way of rationale.
Thanks,
Roland
> Want me to prepare a s/-fno-inline-functions/-fno-inline/ patch?
My reading was that actually we would want both of those switches (the
first to avoid inlining as an implicit optimization, the second to avoid
inlining of functions declared inline). But whatever the exact detail,
yes, please sen
>From Richard's response it sounds like there is an easy fix that's
compatible with both old and new GCC (-fno-inline). I think we can do that
right away without trouble, and get it onto release branches too.
On the libc side more generally, I've become skeptical that the generic C
version of ini
> I'm wondering if we should define a section header flag (sh_flags)
> and/or an ELF header flag (e_flags) for x32 for the people unhappy about
> keying it to the ELF class...
I don't see what's wrong with paying attention to the class. IMHO sh_flags
only makes sense if you might ever mix x32 and
> I'd say we should switch to version 4 only when we need the new fields
> (i.e. if ia64 or other VLIW starts using the new VLIW .debug_line features,
> let it use version 4, but for other targets 3 would be good enough).
> Similarly for .debug_frame.
I agree that makes sense. The .debug_info v4
Are there any plans to make GCC and/or GAS emit the version 4 variants of
the .debug_line and/or .debug_frame formats?
The .debug_line version 4 format only adds the "maximum operations per
instruction" header field and associated logic, which is only meaningful
for VLIW machines (i.e. ia64--are t
> > Feel free to send some gcc patches. I see no point in this.
> > We have -Wl.
>
> I deal with a lot of host systems where shell scripts aren't a viable
> option for ld. Why make everyone write the wrapper script? Makes
> sense to me to have gcc decide.
Like I said, I don't object to any new
> why not make this more explicit by adding an option --ld which is
> directly understood by the gcc driver?
Feel free to send some gcc patches. I see no point in this.
We have -Wl.
> Mainly because an alternative is to install them in subdirectories
> with the name ld. Then gcc can run them directly using a -B option.
> I don't know which approach is best.
I think it keeps things simplest for humans to understand if the actual
binaries are available as ld.bfd and ld.gold.
> I'm still not entirely convinced that this is the way to go. It seems
> to me that ideally one wants to be able to select the linker at
> runtime. I don't see how this patch supports that. What am I
> missing?
It covers the first step by letting you run "ld.bfd" or "ld.gold" to
choose. Havin
I can't really tell how that's different from the patch I posted.
It looks fine to me.
Thanks,
Roland
--with is wrong for this. It's not about the ambient system built against.
It's a feature selection for how you build binutils, which means --enable.
GCC's unwinder doesn't distinguish undefined from same_value, because it
doesn't matter for EH unwinding purposes. Both mean "nothing to be done
for this register". The distinction only matters to informative unwinding
purposes like debugging. I'm not sure why libgcc's unwinder really ought
to c
> * If GCC 4.1.0 does not support the new ABI, but GCC 4.1.1 does support
> that, would it be possible to activate the support on the GLIBC 2.4 branch?
This is not an option. When glibc 2.4 is released, the GLIBC_2.4 version
set will never change again. Each platform will either change by the fi
I hope I can clarify the situation. Planning and communication surely
could have been much better, and as the person who coordinated the efforts
that were made, I can be blamed for what we did and when we did it. glibc
has lacked the manpower to be as organized as we would like to be, and
given w
initfini.c needs -fno-unit-at-a-time. It's not a normal compilation, but a
special hack for generating assembly fragments. The development libc uses
the flag for that file.
23 matches
Mail list logo
