What is the status of `dbg.addr`?

IR & Optimizations
1

I’ve been looking through the various bits of debug info machinery in LLVM today, and I’m a bit unsure of the current status of @llvm.dbg.addr.

From what I could find, dbg.addr was added in 2017 after an RFC as a way of tracking locations of variables in memory which move rather than staying fixed (where dbg.declare can be used). Debug info docs currently describe dbg.declare as deprecated, with dbg.addr as its intended replacement.

At the moment though, it does not seem like Clang or the optimisation passes add dbg.addr intrinsics by default. There are also a few open issues which suggest dbg.addr doesn’t quite work correctly at the moment.

Is there a plan to fix issues in this area and make dbg.addr the default? Perhaps @rnk may know, since they added it originally.

My apologies if I’ve missed something obvious here! :sweat_smile:

2

Currently, we only produce dbg.addr intrinsics if the use-dbg-addr flag is passed, and this path has errors that haven’t been fixed for some time (as you’ve noted). The most recent word from Reid - who wrote the RFC and added dbg.addr - was that “we should remove dbg.addr since it sounds like dbg.value+DW_OP_deref is the preferred representation of the same thing”.

On the other hand there has been some recent work to improve support for the intrinsic, most notably @gottesmm has submitted a number of patches[1][2][3][4] to improve support for it, particularly in relation to coroutines, so there is at least some investment. In my personal opinion though, I would favour removing dbg.addr and using dbg.value (or even better where appropriate, dbg.assign) instead.

3

Yes, dbg.addr should be removed. We have new and better mechanisms to express the same ideas.

4

[scrambles to remove dbg.addr from his frontend…]

Are there any examples of IR showing the equivalent dbg.value and DW_OP_deref for a given dbg.addr? Perhaps a Compiler Explorer link…?

5

Literally doing:

@llvm.dbg.value(metadata ptr %foo, metadata <local var metadata>, metadata !DIExpression(DW_OP_deref))

seems to work equivalently to

@llvm.dbg.addr(metadata ptr %foo, metadata <local var metadata>, metadata !DIExpression())

So I guess that’s all there is to it. Whew!

6

Thanks for everyone’s replies on this topic a few months back. :slightly_smiling_face:

There seems to be clear enough agreement that dbg.addr should go away. I’m happy to take on the work of removing it, as I think it will make things easier to follow for the next person who investigates LLVM’s debug info support.

Perhpas I should wait for @OCHyams’s Assignment Tracking patch stack to be merged first though…? I expect I would need to update many of the same files.

7

I’m so sorry @jryans I completely forgot to come back and reply to this. There’s still work to be done with assignment tracking, but all the main / disruptive patches have landed now. It’s been a while but I thought it would still be worth mentioning in case this is something you’re still considering picking up.

8

Ah, no worries about delayed reply @OCHyams. :slightly_smiling_face:

Thanks for the update! I hope to make an attempt at this in the next few weeks then.

I wonder what level of IR compatibility is required here, given that has dbg.addr always required various experimental flags… Could we just drop / ignore any uses of dbg.addr, or do we need to make some attempt to “upgrade” uses of it in old IR into the remaining supported intrinsics?

9

@dmlloyd reports what looks like a pretty straightforward replacement, above. That’s probably the safest thing to do.

1 Like
10

I’ve started working on the removal patch stack here.

I’ve got the automatic upgrade into dbg.value with DW_OP_deref in place. Now I just need to comb through the various uses of dbg.addr and remove them.

At the moment, this is background project for me, so it will likely be a bit slow to progress. In any case, I’ll post another update here once there are patches to review. :slightly_smiling_face:

1 Like
11

In the SourceLevelDebugging doc, there is some text that makes llvm.dbg.addr seem like a preferred approach, and mentions that there is a “plan to deprecate [llvm.dbg.declare] in future LLVM releases” where it is implied (by my reading) that llvm.dbg.addr would be a likely equivalent. So that doc probably should be updated ASAP, I would think, if there is agreement (?) that llvm.dbg.addr is to be removed.

12

Indeed, I will definitely update that doc. :slightly_smiling_face:

That text (and the confusion about current status that ensues) is a major reason I want to do this clean up. Once I’ve updated those docs, I hope it will make things easier to follow for future readers.

1 Like
13

The patch stack to remove dbg.addr is now up for review!

Please take a look when you get a chance. :slightly_smiling_face:

1 Like