[LLVMdev] unsubscribe
Brandon Ward
bward at sigovs.com
Tue Nov 19 16:37:31 PST 2013
unsubscribe
----- Original Message -----
From: llvmdev-request at cs.uiuc.edu
To: llvmdev at cs.uiuc.edu
Sent: Tuesday, November 19, 2013 5:08:13 PM
Subject: LLVMdev Digest, Vol 113, Issue 74
Send LLVMdev mailing list submissions to
llvmdev at cs.uiuc.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
or, via email, send a message with subject or body 'help' to
llvmdev-request at cs.uiuc.edu
You can reach the person managing the list at
llvmdev-owner at cs.uiuc.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of LLVMdev digest..."
Today's Topics:
1. Re: struct alignment question (Reid Kleckner)
2. Re: bit code file incompatibility due to debug info changes
(Bob Wilson)
3. Re: bit code file incompatibility due to debug info changes
(Eric Christopher)
4. Re: bit code file incompatibility due to debug info changes
(Bob Wilson)
5. Re: Null pointers with a non-0 representation (Micah Villmow)
6. Re: Adding line table debug information to LLVM on Windows
(Timur Iskhodzhanov)
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Nov 2013 12:52:55 -0800
From: Reid Kleckner <rnk at google.com>
To: edA-qa mort-ora-y <eda-qa at disemia.com>
Cc: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] struct alignment question
Message-ID:
<CACs=ty+vasJ-ErT1bLaBqEmLvNQ+HqEUbNqPgx4MwO05xvzwuQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Maybe. Usually people who want this do something like:
Y = { c, d, e }
X = { a, b, Y }
On Tue, Nov 19, 2013 at 12:04 PM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote:
> On 19/11/13 08:03, Caldarale, Charles R wrote:
> >> X = { a, b, c, d, e }
> >> Y = { c, d, e }
>
> > In general, no. If a, b, and c were char, and d was an int, using
> > typical C alignments, there would be one slack byte between c and d
> > in X, whereas there would be three in Y. You could probably force
> > what you want with packed structures or by playing with the data
> > layout setting.
>
> Yes, I forgot about the simple scenario. If I force the alignment on "c"
> should I be okay? That is, if I force it to the maximum alignment for
> the platform will { c, d, e } always have the same layout?
>
>
>
> --
> edA-qa mort-ora-y
> Leaf Creator
>
> Leaf - the language we always wanted
> http://leaflang.org/
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131119/f88e0abd/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 19 Nov 2013 13:28:34 -0800
From: Bob Wilson <bob.wilson at apple.com>
To: Chandler Carruth <chandlerc at google.com>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] bit code file incompatibility due to debug info
changes
Message-ID: <2681F271-BB87-49F2-9CC8-08B129D70349 at apple.com>
Content-Type: text/plain; charset="us-ascii"
On Nov 19, 2013, at 11:01 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>
> On Nov 19, 2013, at 10:58 AM, Chandler Carruth <chandlerc at google.com> wrote:
>
>>
>> On Tue, Nov 19, 2013 at 10:48 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>> I don't have a strong opinion on how we fix it, but I think it's really important to do something and get it done for the 3.4 release.
>>
>> I agree with everything here being a reasonable step for the 3.4 release except:
>>
>> - implement Quentin's previous proposal for back-end diagnostics (and add a diagnostic handler to Apple's linker), so that we can warn about out-of-date debug info
>>
>> I don't think this is important for the release. I don't think open source people have any expectation of stability here, and while it is a nice-to-have, it doesn't seem necessary, and seems clearly like a significant extension that shouldn't be cherry-picked late into the release.
>
> OK, that's fair. As long as we can get it on trunk soon, we can cherry-pick it to an internal release branch.
>
Two questions:
1) Can we reopen the bugzilla PR that I filed and use that to cover the additional of a version number and code to ignore the debug info when the version number does not match? Eric has already closed it twice, so I'm asking this time instead of just reopening it.
2) Who is going to do this work?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131119/74246757/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 19 Nov 2013 13:31:54 -0800
From: Eric Christopher <echristo at gmail.com>
To: Bob Wilson <bob.wilson at apple.com>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] bit code file incompatibility due to debug info
changes
Message-ID:
<CALehDX6ppUuDvvzVZROxJpoyP_Zh+PydQdCS8Q+KWM-kTS45Xw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
> Two questions:
>
> 1) Can we reopen the bugzilla PR that I filed and use that to cover the
> additional of a version number and code to ignore the debug info when the
> version number does not match? Eric has already closed it twice, so I'm
> asking this time instead of just reopening it.
I'm not really sure the bug is needed, but if you want to open a bug
then that's fine. I think there are some holes in what's going to
specified where, but that can be discussed when someone starts working
on it.
>
> 2) Who is going to do this work?
No idea.
-eric
------------------------------
Message: 4
Date: Tue, 19 Nov 2013 13:35:25 -0800
From: Bob Wilson <bob.wilson at apple.com>
To: Eric Christopher <echristo at gmail.com>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] bit code file incompatibility due to debug info
changes
Message-ID: <E49F63C4-F360-4F5D-843D-74EA54A271D8 at apple.com>
Content-Type: text/plain; CHARSET=US-ASCII
On Nov 19, 2013, at 1:31 PM, Eric Christopher <echristo at gmail.com> wrote:
>> Two questions:
>>
>> 1) Can we reopen the bugzilla PR that I filed and use that to cover the
>> additional of a version number and code to ignore the debug info when the
>> version number does not match? Eric has already closed it twice, so I'm
>> asking this time instead of just reopening it.
>
> I'm not really sure the bug is needed, but if you want to open a bug
> then that's fine. I think there are some holes in what's going to
> specified where, but that can be discussed when someone starts working
> on it.
OK. I have reopened pr17982 to cover this issue. I don't intend to specify much in bugzilla, but we should have something to track the overall problem.
>
>>
>> 2) Who is going to do this work?
>
> No idea.
>
> -eric
------------------------------
Message: 5
Date: Tue, 19 Nov 2013 21:44:23 +0000
From: Micah Villmow <micah.villmow at smachines.com>
To: Clark Smith Cox III <clark.cox at apple.com>
Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] Null pointers with a non-0 representation
Message-ID:
<3947CD34E13C4F4AB2D94AD35AE3FE60074E2445 at smi-exchange1.smi.local>
Content-Type: text/plain; charset="us-ascii"
Ahh yeah duh, your right. I misread that.
That doesn't solve this problem however, which is a different example of what I was trying to show but failed.
kernel void test(local int* a) {
local int*ptr = NULL;
if (a != ptr) *a = 0;
}
from host code:
test(0);
Micah
From: Clark Smith Cox III [mailto:clark.cox at apple.com]
Sent: Tuesday, November 19, 2013 12:40 PM
To: Micah Villmow
Cc: Michael LIAO; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Null pointers with a non-0 representation
On Nov 19, 2013, at 10:52, Micah Villmow <micah.villmow at smachines.com<mailto:micah.villmow at smachines.com>> wrote:
+llvm-dev
Yes. The question then becomes, does LLVM handle the case where the cast of the value 0 to a non-void* pointer?
Think of this case:
int *ptr = (int*)0;
based on a strict reading of the spec, ptr itself technically is not the null pointer constant.
Not true, the literal zero *is* a null pointer constant, which is then converted to a null pointer.
If ptr points to an object in the local address space in OpenCL, or any address space where 0 is a valid address and memory exists, does LLVM handle this correctly?
I don't believe that it does, but I can't say for certain.
Micah
From: Michael LIAO [mailto:michael.hliao at gmail.com]
Sent: Sunday, November 17, 2013 10:46 PM
To: Micah Villmow
Subject: Re: [LLVMdev] Null pointers with a non-0 representation
Hi Micah & Michael
By C standard, section 6.3.2.2, "An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function." As LLVM IR is modelled after C, I assume null pointer in LLVM IR is equivalent to 0 as well. The folding from 0 to null pointer in LLVM follows that behaviour very similar.
- michael
On Sun, Nov 17, 2013 at 1:00 PM, Micah Villmow <micah.villmow at smachines.com<mailto:micah.villmow at smachines.com>> wrote:
The reason why I suggested looking there is because the same questions came up as address 0 in some of the OpenCL address spaces are legal addresses. So in order to solve this problem, they would have to find answers to your questions, mainly your 'c)' question.
I took a look at LangRef and it does look like there is a 'null' representation of the null pointer constant, which wasn't part of LLVM back when I worked on this problem. So maybe you are just running into an issue where the code hasn't been updated yet because it works on everyones platform but yours.
Micah
From: Kuperstein, Michael M [mailto:michael.m.kuperstein at intel.com<mailto:michael.m.kuperstein at intel.com>]
Sent: Sunday, November 17, 2013 3:28 AM
To: Micah Villmow; LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>
Subject: RE: Null pointers with a non-0 representation
Hi Micah,
Thanks a lot for the reference.
Unfortunately, it looks like the discussion there is dealing with a somewhat different issue - modeling OpenCL address spaces. It's true that the null pointer issue may arise in a similar context (e.g. null pointers in different address spaces may have different internal representations), but it's not entirely related. Or have I missed something in the thread?
Thanks,
Michael
From: Micah Villmow [mailto:micah.villmow at smachines.com]
Sent: Sunday, November 17, 2013 11:42
To: Kuperstein, Michael M; LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>
Subject: RE: Null pointers with a non-0 representation
I ran into the same problem in OpenCL with Local/Private address spaces and I believe it was discussed here in the past. So I would suggest looking through the archives as I believe some of your questions are answered there.
This post might be a good starting point:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044101.html
Also the SPIR provisional spec as of last November deals with this issue if I remember correctly, so maybe you can discuss with Boaz Ouriel if he is still at Intel Israel about how they went about handling this problem, or look at the SPIR related posts from last year.
Hope this helps,
Micah
From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kuperstein, Michael M
Sent: Sunday, November 17, 2013 1:15 AM
To: LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>
Subject: [LLVMdev] Null pointers with a non-0 representation
I feel a bit silly asking this, but here goes.
The C spec does not require the null pointer to be implemented as an integer with the 0 bit-pattern. The implementation may arbitrarily choose any other (integer, but not necessarily) representation, as long as it's distinct from any legal pointer. The only requirement is that casting an integer 0 to a pointer type results in a null pointer.
LLVM IR appears to have similar the casting behavior. That is, if I try to create a pointer with integer value 0 (e.g. by constructing an inttoptr constant expression with a i32 0 argument), it gets immediately folded into a null pointer constant. Furthermore, a PtrToInt from a null pointer results in 0 (which is even "stricter" than the C spec.)
So, that raises a few question:
a) Are those the desired semantics? I guess if clang generates this kind of IntToPtr instructions (as opposed to directly resolving the cast to a null pointer) this is unavoidable. But otherwise, why does LLVM treat null pointers and pointers with the integer value 0 as equivalent?
It's completely natural for most platforms, but isn't necessarily the right thing to do.
b) Assuming this is really desirable, should the fact that casting an integer 0 to a pointer type results in a null pointer be documented in the langref (as part of the inttoptr/ptrtoint documentation)? Or is it too "low-level"?
c) Let's say I want to create a pointer with the numeric value 0, distinct from the null pointer, because 0 really does represent a valid pointer on my platform. Should this possible at the IR level? If it should be, then how?
Anyone has any inputs, except laughing me out of the (virtual) room? :-)
Thanks,
Michael
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu<http://llvm.cs.uiuc.edu/>
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131119/dc193b01/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 18 Nov 2013 21:14:17 +0400
From: Timur Iskhodzhanov <timurrrr at google.com>
To: Jo?o Matos <ripzonetriton at gmail.com>, David Blaikie
<dblaikie at gmail.com>, Eric Christopher <echristo at gmail.com>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] Adding line table debug information to LLVM on
Windows
Message-ID:
<CAH38oYiu7oLYH494zNo7yUH+BH8XWFJLBoQi5BedaUDpLUSm8w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I wrote some more lit tests for my patch and realized I was generating
some redundant info. This is fixed now. Attached is a new version
of the prototype patch with some more tests.
2013/11/15 Jo?o Matos <ripzonetriton at gmail.com>:
> Hi Timur,
>
> There's also a pending patch adding CodeView support in Phab:
> http://llvm-reviews.chandlerc.com/D165
I haven't looked at your patch yet, but based on the very low phab
review number, I'm pretty sure there are good reasons this wasn't
committed.
> Does your patch provide just a subset of the CodeView debug info provided in
> the other patch?
Yes. I prefer small incremental changes.
Also, the file:line debug info is much much more important for me atm
than the other types of debug info.
> Looking at the patch, I think the approach the other patch took of
> abstracting the emission of debug information is a bit cleaner and it will
> probably make life easier when adding more debug formats in the future.
Why wasn't the "abstract the emission of DI" part of that patch
reviewed/committed separately?
> On Fri, Nov 15, 2013 at 4:39 PM, Timur Iskhodzhanov <timurrrr at google.com>
> wrote:
>>
>> 2013/11/14 Timur Iskhodzhanov <timurrrr at google.com>:
>> > Hi David, Eric, LLVM devs,
>> >
>> > You've probably heard about AddressSanitizer (ASan) and other
>> > sanitizers based on LLVM. One of the things that makes ASan
>> > not as awesome on Windows as it is on Linux
>> > is the symbolization of the stacks.
>> >
>> > Currently, ASan runtime on Windows uses
>> > CaptureStackBackTrace/SymFromAddr/SymGetLineFromAddr64
>> > to unwind and symbolize stacks. This works like a charm
>> > in-process for stack frames built with CL, but yields
>> > "function+0x0ff537" for frames built with Clang.
>> >
>> > I came up with a prototype which emits "old-style debug info" COFF
>> > sections that are sufficient to get function name / filename /
>> > linenumber information. That's pretty much everything that's required
>> > for ASan to work beautifully in terms of the completeness of error
>> > reports.
>> >
>> > Attached is a prototype patch which I've tried on some simple tests,
>> > including some more complex ones with weird #line constructions.
>> > It also works just great on ASan/Win tests without any link/run-time
>> > warnings (I had a bunch of those during development, so I can tell it
>> > works rather than fails silently).
>> >
>> > I didn't have time to work on threading the command-line flags into
>> > the AsmPrinter yet, so currently it just replaces DWARF entirely.
>> > Of course, this should be fixed before this lands into trunk.
>> > Currently, one can try this patch by using "clang-cl -Xclang -g ...".
>> > Eventually we should have some dedicated flag for clang-cl.
>> >
>> > Can you please take a look at the patch and suggest a good path forward?
>> >
>> > I'm very unfamiliar with LLVM CodeGen/MC, so I'm pretty sure I made a
>> > few weird things in the code... I've also put a few TODOs with
>> > questions and suggestions.
>> >
>> > Some general questions:
>> > 1) Threading flags from the driver down to CodeGen.
>> > How do we do that? Should we support all 4 combinations
>> > of no-info/DWARF/CVLT/both?
>> > How about "-Zmlt" as the clang-cl flag name? ("minimal line tables")
>> >
>> > 2) Am I right that DWARF is pretty much the only debug info format
>> > supported by LLVM/AsmPrinter right now? Do we want to take
>> > an effort to come up with a generic debuginfogenerator interface
>> > to share between DwarfDebug and WinCodeViewLineTables?
>> > Then AsmPrinter should just hold a SmallVector<DebugInfoEmitter*>
>> > rather than a pair of DD/DE pointers.
>> >
>> > 3) How would you suggest to write WinCodeViewLineTables tests
>> > given that dumpbin is not available everywhere except Windows?
>> > // Yeah, I should have looked at the DwarfDebug LIT tests and
>> > // written some; but the prototype development went faster
>> > // than I expected...
>>
>> I found the MCAsmStreamer being used by llc which gives a decent text
>> format.
>> I wrote a simple x86+x86_64 .ll test and FileCheck expectations for
>> the llc asm output.
>> Is this the right approach to write tests?
>> If so, I'll convert my remaining C program test cases into such an
>> .ll+llc tests.
>>
>> > Can you suggest ways to split this patch so it's easier
>> > to review part-by-part before this hits trunk?
>>
>> Attached is an updated patch with a new test and a few minor things
>> improved.
>> I also removed the "TODO: test on X64" as I did try it on x64 and no
>> changes were required.
>>
>> Looking forward to your feedback!
>>
>> > Thanks!
>> > --
>> > Timur Iskhodzhanov,
>> > Google
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
>
> --
> Jo?o Matos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: codeview_linetables.patch
Type: application/octet-stream
Size: 87059 bytes
Desc: not available
URL: <http://lists.cs.uiuc.edu/pipermail/llvmdev/attachments/20131118/671abbc1/attachment.obj>
------------------------------
_______________________________________________
LLVMdev mailing list
LLVMdev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
End of LLVMdev Digest, Vol 113, Issue 74
****************************************
--
Brandon Ward
SIGOVS
W: (321)752-1796
C: (813)789-7787
More information about the llvm-dev
mailing list