[lldb-dev] [CFP] LLVM toolchain devroom CFP at FOSDEM 2019
*CALL FOR PAPERS / PARTICIPATION* At FOSDEM 2019, LLVM will again participate with a dedicated devroom, on February 3rd, in Brussels. As possibly the largest European Open Source Conference, FOSDEM attracts more than 600 lectures and over 8000 hackers - many core contributors of the worlds leading open source projects. Complementing the LLVM developer meetings, the devroom at FOSDEM provides a great opportunity for LLVM developers and the wider open source community to get together, connect and discuss. We invite academic, industrial and hobbyist speakers to present their work on developing or using LLVM, Clang, LLDB, Polly, Compiler-rt, etc. We are looking for: - Keynote speakers. - Technical presentations (30 minutes plus questions and discussion) related to development of LLVM, Clang etc. - Presentations about the use of LLVM, Clang in commercial, academic, hobbyist and other projects. - Tutorials. - Lightning talks (5 minutes). - Demos. The deadline for receiving proposals is Sunday November 25th, 2018. Speakers will be notified of acceptance or rejection by December 11th. Please find some advice on what constitutes a good proposal at the end of this CFP. To submit a proposal, please create an account on the FOSDEM interface (https://penta.fosdem.org/user/new_account). If you already have an account from previous years, please reuse that. Submit your proposal following https://penta.fosdem.org/submission/FOSDEM19, “Create Event”. Please make sure you select "LLVM devroom" as the "Track”. Presentations will be recorded and streamed. Sending your proposal implies giving permission to be recorded. However, exceptions can be made for exceptional circumstances. *Registration* FOSDEM does not require any registration and is free of charge. *Organization* The mailing list llvm-devroom at lists.fosdem.org can be used to discuss issues of general interest related to the conference organization. Please, do not reply to this email, as it is cross posted to many lists. *Financial support* There may be a possibility of limited funding to help presenting students or presenting contributors who could not otherwise attend the conference. If you need funding to be able to present at the meeting, or can help sponsor, please tell us on llvm-devroom at lists.fosdem.org. *Guidance on writing a proposal for the LLVM Dev Room* This is a guide to help you submit a good proposal and increase your chances of your proposal being accepted. If you have never presented at an LLVM meeting, then do not fear this process. We are actively looking for new speakers who are excited about LLVM and helping grow the community through these educational talks! You do not need to be a long time developer to submit a proposal. General Guidelines: - It should be clear from your abstract what your topic is, who your targeted audience is, and what are the takeaways for attendees. The program committee does not have time to read 10 page papers for each submission. - Talks about a use of LLVM (etc) should include details about how LLVM is used and not only be about the resulting application. - Tutorials on “how to use X” in LLVM (or other subproject) are greatly desired and beneficial to many developers. Entry level topics are encouraged as well. - Typically a few paragraphs are sufficient. Best regards, LLVM @ FOSDEM organisers ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
> On Oct 11, 2018, at 3:55 PM, Davide Italiano wrote: > > On Thu, Oct 11, 2018 at 1:38 PM Greg Clayton wrote: >> >> I am happy to look at any DWARF expressions you have and help figure out >> where the change needs to go or how the expression need to be fixed. >> > > Thank you for your help, it's greatly appreciated. hopefully we'll > have a more precise debugger after this effort :) Now that we have a more precise specification in DWARF5, we can. Before that, it was all up to interpretation of each compiler engineer as to what made sense for the location expressions... Thanks for working on this. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev > wrote: > > DWARF5 finally added the ability to track what each value means on the > expression stack. Prior to DWARF 5, we had no idea what each entry on the > expression value stack was (file address, load address > (Value::eValueTypeLoadAddress), plain value (Value::eValueTypeScalar). We > have tracked this info for a while now, but the DWARF5 spec is much more > specific on how things should be treated. Greg, I'd like to summarize my own understanding of how this works — could you take a look and correct me where I'm wrong? - The only way to push a file address onto the DWARF stack is a DW_OP_addr. The decision of whether a value pushed onto the DWARF stack is a scalar or a load address depends on the location kind (cf. DWARF 5, section 2.6 "Location Descriptions"): - A register location description (DW_OP_reg.*) reads the register contents and pushes a scalar. - An implicit location description (.* (DW_OP_implicit_.*|DW_OP_stack_value) yields a scalar after evaluating the expression. - A memory location description (anything else, such as DW_OP_breg) yields a load address. (- composite locations, like DW_OP_piece are handled according to these rules for each piece) Practically speaking, I think this means that a DW_OP_(f)breg always turns into a load address (as it can only appear in an implicit or a memory location), and a DW_OP_reg always. turns into a scalar. Is that what LLDB is doing, and if not, could that explain at least some of the failures that Davide is seeing? -- adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
> On Oct 12, 2018, at 9:53 AM, Adrian Prantl via lldb-dev > wrote: > > > >> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev >> wrote: >> >> DWARF5 finally added the ability to track what each value means on the >> expression stack. Prior to DWARF 5, we had no idea what each entry on the >> expression value stack was (file address, load address >> (Value::eValueTypeLoadAddress), plain value (Value::eValueTypeScalar). We >> have tracked this info for a while now, but the DWARF5 spec is much more >> specific on how things should be treated. > > Greg, > > I'd like to summarize my own understanding of how this works — could you take > a look and correct me where I'm wrong? > > - The only way to push a file address onto the DWARF stack is a DW_OP_addr. > > The decision of whether a value pushed onto the DWARF stack is a scalar or a > load address depends on the location kind (cf. DWARF 5, section 2.6 "Location > Descriptions"): > - A register location description (DW_OP_reg.*) reads the register contents > and pushes a scalar. > - An implicit location description (.* (DW_OP_implicit_.*|DW_OP_stack_value) > yields a scalar after evaluating the expression. > - A memory location description (anything else, such as DW_OP_breg) yields a > load address. > (- composite locations, like DW_OP_piece are handled according to these rules > for each piece) > > Practically speaking, I think this means that a DW_OP_(f)breg always turns > into a load address (as it can only appear in an implicit or a memory > location), and a DW_OP_reg always. turns into a scalar. > > > Is that what LLDB is doing, and if not, could that explain at least some of > the failures that Davide is seeing? To answer my own question: I think that the patch to set the address type to scalar after interpreting a DW_OP_deref is just wrong, because of the above :-) -- adrian ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
Follow up. This turned out to be a bug in the swift specific support,
so I don't think the DWARF parser code is wrong here.
Thanks!
--
Davide
On Thu, Oct 11, 2018 at 10:52 AM Davide Italiano wrote:
>
> Hi Greg,
> I have this issue that I suspect is a bug in lldb’s handling of DW_OP_deref.
> I wasn’t able to craft an easy C++ testcase, so I’ll start from my
> motivating (swift) example.
>
> Given the following code:
>
> func use(_ t : T) {}
> func single(_ t : T) {
> let x = t
> use(x)
> }
> let s = "hello"
> single(s)
>
> The IR emitted for the local binding `x` in `single` is an alloca
> containing the address of `x`. Hence, the DWARF, correctly contains a
> DW_OP_deref expression, i.e.:
>
> 0x00da: TAG_variable [9]
> AT_location( fbreg -16, deref )
> AT_name( "x" )
> AT_decl_file(
> "/Users/dcci/work/swift/build/Ninja-RelWithDebInfoAssert+stdlib-RelWithDebInfo/swift-macosx-x86_64/bin/pat.swift"
> )
> AT_decl_line( 4 )
> AT_type( {0x0204} ( $sxD ) )
>
> When I debug this with lldb, I expect lldb to print the value that’s
> pointed by %rbp - 16,
> i.e.
> (lldb) register read $rbp
> rbp = 0x7ffeefbff860
>
> (lldb) mem read 0x7ffeefbff850
> 0x7ffeefbff850: 10 f8 bf ef fe 7f 00 00 b8 32 4d 00 01 00 00 00
> ....?2M.
> 0x7ffeefbff860: c0 f8 bf ef fe 7f 00 00 64 09 00 00 01 00 00 00
> ?...d...
>
> So, the value that I expected to be printed is 0x7ffeefbff810.
>
> What I instead see in the debugger is:
> (T) x =
>
> The value `0xe500` happens to be the value that’s pointed
> by the address 0x7ffeefbff810, that is:
>
> (lldb) mem read 0x7ffeefbff810
> 0x7ffeefbff810: 00 00 00 00 00 00 00 e5 68 65 6c 6c 6f 00 00 00
> ...?hello...
> 0x7ffeefbff820: 05 00 00 00 00 00 00 00 40 32 4d 00 01 00 00 00
> @2M.
>
> Is this an expected behavior? I did expect DW_OP_deref to just do a
> single dereference and not two. It looks like when we call
> `UpdateValue()` in lldb we do have the correct value in `m_value`, but
> GetPointerValue() ends up printing the value that’s *pointed by*
> what’s in `m_value`, i.e.
>
> m_integer = {
> U = {
> VAL = 0x7ffeefbff810
> pVal = 0x7ffeefbff810
> }
>
> as this is a LoadAddress. Greg, as you wrote this code (and touched it
> last), what do you expect to be the correct semantic here?
>
> Removing a dereference from DW_OP_deref in the DWARFASTParser works
> around the issue, but I’m fairly sure it’s the incorrect fix. Are we
> maybe setting the value type incorrectly?
>
>
> Best,
>
>
> —
>
> Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] DW_OP_deref handling
> On Oct 12, 2018, at 9:53 AM, Adrian Prantl wrote: > > > >> On Oct 11, 2018, at 11:16 AM, Greg Clayton via lldb-dev >> wrote: >> >> DWARF5 finally added the ability to track what each value means on the >> expression stack. Prior to DWARF 5, we had no idea what each entry on the >> expression value stack was (file address, load address >> (Value::eValueTypeLoadAddress), plain value (Value::eValueTypeScalar). We >> have tracked this info for a while now, but the DWARF5 spec is much more >> specific on how things should be treated. > > Greg, > > I'd like to summarize my own understanding of how this works — could you take > a look and correct me where I'm wrong? > > - The only way to push a file address onto the DWARF stack is a DW_OP_addr. > > The decision of whether a value pushed onto the DWARF stack is a scalar or a > load address depends on the location kind (cf. DWARF 5, section 2.6 "Location > Descriptions"): > - A register location description (DW_OP_reg.*) reads the register contents > and pushes a scalar. > - An implicit location description (.* (DW_OP_implicit_.*|DW_OP_stack_value) > yields a scalar after evaluating the expression. > - A memory location description (anything else, such as DW_OP_breg) yields a > load address. > (- composite locations, like DW_OP_piece are handled according to these rules > for each piece) > > Practically speaking, I think this means that a DW_OP_(f)breg always turns > into a load address (as it can only appear in an implicit or a memory > location), and a DW_OP_reg always. turns into a scalar. > > > Is that what LLDB is doing, and if not, could that explain at least some of > the failures that Davide is seeing? Correct! Summarizing: - DW_OP_addr == file address - DW_OP_(f)breg == load address - DW_OP_reg == scalar - DW_OP_deref(x) == needs to be fixed to change to scalar, currently leaves it as load addr - DW_OP_const == scalar (unless DW_OP_piece is used) The failure Davide is seeing is there is a load address on the stack, and after the deref, it gets pushed the correct value but leaves it as a load addr. When any expression is done being evaluated, we look at the type of that value that is left at the top of the stack. If it is a load addr, then we read from memory if it is a scalar, it is the value itself Issue Davide is running into is the value is correct, but the type is still load addr incorrectly. Greg ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
