similar to: [DebugInfo] [DWARFv5] .debug_abbrev contents for different implicit_const values

Hello folks, I was interested in the support we have for the attribute form DW_FORM_implicit_const (DWARFv5 feature) in clang/LLVM. And I had some doubts wrt this. I noticed that support for this was put in here in 2017: https://rev.ng/gitlab/revng-bar-2019/llvm/commit/d9df13befcbc702e239b650dd1f55778d72b8571 >From what I could make out, the support for generating DW_FORM_implicit_const

Sorry, this is the attachment. 2014-02-19 15:08 GMT+08:00 杨勇勇 <triple.yang at gmail.com>: > Thank you. > > Here is an example and the attchment contains extra files including object > file and executable file. > I want to print for example the value of "a", but lldb command "frame > variable a" displays "0" and so does "b", and

All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for. Greg Clayton On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote: > Hi, all > > I

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Hi, all I ported llvm backend and lldb recently. Both tools can basically work. lldb is able to debug programs in asm style and frame unwinding is OK. But "frame variable XX" does not work because lldb is not able to determine the address of XX from debug info. Can someone give any clue? Thanks in advance. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

Thank you, Clayton. This is very helpful. We use the LLDB specific GDB remote extensions, and our debugger server supports "qRegisterInfo" package. "reg 0x3c" is the frame pointer. In the example mentioned above, we have SP = FP - 40 for current call frame. And variable "a" is stored at address (FP + -24) from asm instruction [FP + -24] = R3;; Thus we can conclude

Hi, Sorry for the late reply, I was OOO last week. > On Mar 29, 2018, at 3:59 PM, David Blaikie <dblaikie at gmail.com> wrote: > > +Eric Christopher +Adrian Prantl +Jonas Devlieghere (seems Jonas is doing a bunch of debug info work - guessing he's working with you, Adrian?) Yup, I joined Adrian’s team last August. > I'm guessing Eric's the most likely to have

> > I'm guessing Eric's the most likely to have contacts over in GCC land to > maybe bridge the gap when talking about assembly syntax across the two. > Eric - any ideas how best to negotiate this pseudo-standard? (there's > another feature or two I'd like to propose too - at least to standardize > what the syntax /should/ be, even if gas doesn't support it

+Eric Christopher <echristo at gmail.com> +Adrian Prantl <aprantl at apple.com> +Jonas Devlieghere <jdevlieghere at apple.com> (seems Jonas is doing a bunch of debug info work - guessing he's working with you, Adrian?) I'm guessing Eric's the most likely to have contacts over in GCC land to maybe bridge the gap when talking about assembly syntax across the two. Eric

Hello all, I am implementing support for .debug_names section (which is introduced in DWARFv5 standard as replacement for .debug_pubnames and .debug_pubtypes). The question is: should usage of DWARF version 5 force generation of .debug_names instead of .debug_pubnames or we can make it just default behavior and provide user with the interface (cmd switch) to use other DWARFv5 features but

Yep, Wolfgang picked up on the one thing I saw too. This is why I like having people review my stuff. I think it's a bit of a pity that str_offsets_base can point into the middle of a str_offsets contribution in some ways Actually I changed my mind after saying that in the review, and in this writeup I concluded that it cannot do that. str_offsets_base points to the element immediately

>> To pass the MD5 checksum to the assembler, I added a new optional >> clause to the .file directive: >> md5 "checksum" >> where checksum is the 16-byte checksum in hex.  It's quoted because >> the assembler doesn't have a way to parse a 16-byte integer. > > I'd guess, long-term, that's probably not a great motivation for > choosing

On 5/21/20, Adrian Prantl <aprantl at apple.com> wrote: > I think the example looks like it would be really useful for many categories > of testcases! > Will it still be possible to manually specify the .debug_abbrev section when > this is desired after you are done? Yes, I think it works. There are two ways to edit the .debug_abbrev section. i) Edit the "Attr:" and

On Thu, Mar 29, 2018 at 8:27 AM <paul.robinson at sony.com> wrote: > To pass the MD5 checksum to the assembler, I added a new optional clause > to the .file directive: > > md5 "checksum" > > where checksum is the 16-byte checksum in hex. It's quoted because the > assembler doesn't have a way to parse a 16-byte integer. > I'd guess, long-term,

Hi folks, I am going to implement DWARF support for yaml2obj. I really appreciate it that many of you have given me a lot of useful comments and suggestions in the previous thread [1]. I've had some offline discussions with James and done some updates to the previous proposal. This proposal addresses the issue of properly describing the DWARF sections in YAML both at a high level and at a

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Pieb, > Wolfgang via llvm-dev > Sent: Wednesday, July 05, 2017 6:14 PM > To: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] [DWARFv5] Reading the .debug_str_offsets section > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at

TL;DR: If I'm trying to define new assembler directive syntax to support DWARF v5, it seems like a good idea for all the various assemblers out there in the world to support the same syntax. How would I go about negotiating that syntax with other assembler providers? Is GNU as the only really relevant one? Long version: DWARF v5 introduces a couple of new features in the .debug_line section

There was some discussion about this in D34765, and I had a follow-up chat with Wolfgang separately, plus spent a fair amount of time in reading and thinking today. I thought I would write my understanding all down here so we can reach a common understanding of how it ought to work, and therefore what our code should do. For any non-DWARF-experts who might be interested, in principle this

To pass the MD5 checksum to the assembler, I added a new optional clause to the .file directive: md5 "checksum" where checksum is the 16-byte checksum in hex. It's quoted because the assembler doesn't have a way to parse a 16-byte integer. Also this is the same syntax Reid invented for the CodeView equivalent. To convey the root source filename, I allow the file number on the