- User Since
- Nov 23 2012, 10:16 AM (316 w, 14 h)
Tue, Dec 11
This header is used on systems without glibc. So please don't argue about behavior based only on that. Granted, most other libc implementation are less annoying when it comes to free and malloc, but still.
Mon, Dec 10
Sun, Dec 9
I don't see why this interceptor needs to know about the internals of struct cdbr or struct cdbw at all. They are fully opaque. All memory accessed by users is explicitly sized as argument to the functions or returned with the size.
Mon, Dec 3
I'd recomment another pass to reduce the now fully redundant () pairs around % string substitutions, but in principle LGTM.
Sun, Dec 2
Can you split off the pure modernisation changes like new exception or print ? Those are completely non-contentious changes after all. I generally do not like the range and list related changes as many instances are clear regressions for the 2.x case. filter to list comprehension should IMO be a separate change as well, but those are much less problematic and often an improvement in terms of both performance and readability.
Mon, Nov 19
I'm sorry, but it still sounds to me like you want to address badly written build rules by making the driver more complicated. I don't see that is a reasonable goal forward.
Sat, Nov 17
I don't understand the point here. Why would you want to include pre-processing-only commands in the compilation database?
Fri, Nov 16
Well, I do like the general idea. I would go with a sorted static array and a binary search though. This is not really time critical, but the array version would be smaller in terms of code without involving run-time allocations.
Nov 13 2018
I would actually rule out subshells as well. I see no reason why a test case should have to use them, i.e. compared to just change the working directory back afterwards. As I said, I want to be able to repeat a problematic command manually and interactively as easy as possible. Using non-portable shell features is a problem for that. Depending on state between commands is also annoying. Let's really try to keep it minimal and where necessary, adjust test case guidelines and test cases to simplify things.
As I said: because it makes it harder to rerun parts of the test interactively. Which is a good enough reason to forbid cd - as well as any directory stack operations, IMO.
Nov 12 2018
Personally, I would strongly prefer if the test cases are as explicit as possible. That makes debugging based on the llvm-lit output a lot easier. Ignoring anything else, this feature would make it a lot more tricky to figure out what exactly is going on.
Nov 11 2018
I'm quite against this. "cd -" is a non-portable extension to shell and should never be used in first place.
Nov 9 2018
I think I would enumerate the BSDs here (and Apple) explicitly and not depend on BSD.
Nov 5 2018
Nothing changed. I don't see how catering to the broken libstdc++ self-configuration helps. So no, I still object to this change.
Nov 4 2018
Oct 30 2018
__m68k__ and __ia64__ too, just for completeness.
Oct 24 2018
To summarize the discussion on IRC, from my perspective this change is wrong. PPC as architecture is strongly geared towards PIC code. We used to create quite bad position dependent code and I generally don't see the advantage. I can understand wanting to default to PIE (i.e. position independent code with main binary assumption as far as interception is considered). In other words, the middle end generally tended to create better results for position independent codegen. The default behavior of GCC is ephemeral here, IMO.
Oct 19 2018
Excuse me for bring this up so late, but why do we want to make any such promises? As in: fundamentally, LLVM IR doesn't have any order property on the module level. I have yet so seen reasonable code where the order of functions matters for anything but performance. I've seen a few things that required -funit-at-a-time, most noticable GCC's CRT implementation. But those are all major hacks. So under what premise is it useful to have to even pretend to honor source code order?
Oct 1 2018
Sep 30 2018
Yeah, I would restrict it to just mention that it depends on the target, link time editor and runtime linker. Even the concrete feature set on Linux changes with glibc versions.
I think this is still too optimistic. Full support for ifunc seems to be generally limited to x86. Most other architectures lack even definitions for anonymous ifunc relocations or support proper relaxation only in limited forms. That's especially annoying when looking at static linking.
Sep 16 2018
I find this warning confusing. I find a4 to be perfectly expected. IMO this warning should be applied only, if the effective value of the expression is not the same as in the modulo-n arithmetic. This means that if (-x) is explicitly or implicitly cast to a less wide unsigned type, it should not warn. It would consider a warning for the case of using (-x) if integer promotion rules makes it negative though. The question is, how to best patch around the warning though. What options does MSVC have for that? I.e. what equivalent expressions do not trigger this warning?
Sep 6 2018
Correct. The protected name is double underscore as both suffix and prefix.
Sep 5 2018
Sep 4 2018
Please check the history of the file for some of the problems with the redefinition. I'm quite against this change.
Aug 31 2018
Every system call has a public and internal variant. The former might be replaced by libpthread etc for thread cancellation support, but that's a different topic.
Aug 29 2018
Yes, it is optional, but on most architectures, the builtin variant is much cheaper. That said, I'm not sure what the situation is on SPARC with the necessary register window flush.
I don't understand why most of this symbols don't reference the plain system call directly, i.e. _sys_read etc.
There is one user of builtin_setjmp/builtin_longjmp that should be kept in mind: Ruby.
Aug 20 2018
Is there a reason for defining them? As in: does anything outside libunwind use them? I haven't seen such software yet.
Why do we need to allocate memory in this case at all? I.e. why can't this just be:
if (S.empty()) return StringRef("", 0); ...
Aug 16 2018
If a build against compiler-rt works, that's ok. It wasn't clear from the diff.
Aug 15 2018
I don't understand the desire for this logic. Why can't wasm override the rest of the types if it wants to have something special?
This hard-coding seems to be counter-productive, it could be compiler-rt just as well.
Aug 1 2018
There are two different considerations here:
(1) Create less target code
(2) Create less IR
Jul 24 2018
Depends a bit on the platform, __cxa_atexit on most modern ELF systems, fallback to atexit. If the global dtor is run too late, it smells like a missing library dependency. They are executed in topological order after all.
Can this ever end up in a shared library? If yes, please use the normal logic for creating a global destructor. atexit is not very friendly to dlopen...
Jul 18 2018
Both needs a test case :)
It seems to miss most of the interesting checks, i.e. crt files. Compare with any of the entries on netbsd.c for example.
This is absolutely not how the clang driver is supposed to work. No conditional compilation.
Jul 17 2018
Jul 15 2018
Jul 12 2018
Jul 9 2018
Looking further, at least on NetBSD libgcc seems to always include both the "normal" and the .rem/.urem routines. While we currently don't replace __umodsi3 and friends, that looks more like an oversight on our part.
I asked the Sparc folks and they can't remember any special reason for why .urem should be used. I.e. it follows the normal Sparc ABI.
As such, I'm mostly ambivalent on this change and the rest of the block.
Jul 5 2018
Not what I mean. Certain platforms like Sparc and SH link a copy of certain routines into every DSO. This is the so-called milli code. They sometimes use special calling conventions as well. That's different from the "normal" helper routines in libgcc, which are shared by all libraries.
Jul 4 2018
That would be the milli code version, wouldn't it?
Jun 18 2018
Jun 5 2018
After a careful review of newer GCC / libgcc and the assembler annotations from LLVM, I have come to the following conclusions:
May 22 2018
This still needs a test case?
May 9 2018
This looks sensible, but I don't know what PoisonShadow will do for the rest of the memory block.
May 8 2018
"-z textrel" can also be used in build instructions if some platforms will need it, even if not all of them do.
Apr 27 2018
Yes, if that option is enabled explicitly or implicitly in the frontend, the expectation is that all compiler-generated functions have uwtable as well.
Given that .eh_frame sections can be used to create backtraces i.e. from signal handlers, this seems to be undesirable in the generality. Shouldn't this attribute be conditional on whether functions are normally supposed to have unwind data?
Apr 24 2018
I'm back to the point where I can't reproduce the problem :( Can we start providing an actual failing test case? It's annoying to debug a problem when you can't reproduce it.
Apr 23 2018
Things are different for a libgcc-based toolchain and a compiler-rt based toolchain.
Apr 6 2018
Can you make sure that we handle the older ARM versions correctly as well, i.e. v4, v5 and v6? I take it we still have test cases for the arm <-> thumb transition? That's the one part of the triple logic that is really non-trivial.
Mar 30 2018
The "struct object" is an implementation detail of the unwind implementation. You are guaranteed historically to get at least 8 longs / 8 pointers for internal use statically allocated in each object. What is stored inside is up to the unwind implementation.
Mar 28 2018
GCC supports -mbss-plt to get the legacy behavior. Not sure if anyone actually uses it though.
Mar 27 2018
Given that some people like to post-process assembler files, using the section symbol directly is a bad idea. Adding the local symbols is fine.
Mar 26 2018
Oh, we certainly should never be hitting an assertion on front-end flags. As such, there is a problem to fix here. I still maintain that the combination of flags is non-sense, so the question is:
Mar 23 2018
It should be kept in mind that secure PLT is desirable for certain cases with non-position independent code as well. Even in static binaries it can be desirable... But that is for a follow-up patch.
IMO we should explicitly error out. That combination is nonsense to me. Creating useless JSON database fragments is not an improvement.
Mar 5 2018
The difference is that modsi3 etc are all paired instructions. A backend should not be lowering to one of them if a real division instruction exists and it should be consistent in the lowering.
Feb 21 2018
ARM and x86 implement different chars, don't they?
Feb 19 2018
We tried to keep the condition simple. I.e. does the compiler on any of those platforms ever use the libcall? If not, it is IMO not worth the complexity.
Feb 12 2018
Please stop adding complexity to doctor around the symptoms. There are two real fixes here and this change doesn't help with either:
(1) Emit cross-section pointers as indirect. This increases the binary size, but otherwise ensures that any linker can create read-only .eh_frame on MIPS.
(2) Teach lld on MIPS to properly reassemble the DWARF instructions, similar to what GNU ld can do. The latter is a bit stupid and needs a good kick to work properly, but this is the correct approach forward.
This is not acceptable. If anything, the encoding should be switched to indirect, but that should already be the case.
I really don't like ignoring options that are supposed to provide actual functionality. Most of the other options are for pointless fine tuning and workarounds for broken gcc behavior in ancient versions.
Feb 8 2018
Feb 5 2018
I really, really dislike this patch. It is using very blunt force to workaround a GCC bug. The comment is too verbose as well. Please try the following change from NetBSD instead:
Jan 19 2018
Good enough for me.
Jan 18 2018
Do you see the comment just following the code? The patch completely violates that basic design principle. It would be perfectly sensible to hard-code a list of dumb terminals and explicitly default to no colors for them. The reverse (hard-coding a list and assuming it is fine for everything else) is not.
That's no excuse for making the situation even worse.
I completely disagree with this approach. A lot of GNU tools (including GCC) are completely broken. We shouldn't follow them. There are a lot more terminals around than just "dumb", "xterm" and "linux". It is completely non-acceptable to just assume ANSI escape sequences work. If Android doesn't ship a usable terminfo implementation, I consider that an Android bug. Wouldn't be the first portability nightmare with Android.