Line number information (and other metadata)

I'd like my compiler to emit proper line number information. The docs
talk about Instruction::setDebugLoc(), but that method doesn't actually
have to be in my 2.7 LLVM Debian package. What's the correct way of
doing this?

In addition, can anyone point me at an example of how to emit a comment
attached to an instruction (or function)?

I'd like my compiler to emit proper line number information. The docs
talk about Instruction::setDebugLoc(), but that method doesn't actually
have to be in my 2.7 LLVM Debian package. What's the correct way of
doing this?

Grr stupid typo.

The docs
talk about Instruction::setDebugLoc(), but that method doesn't
actually appear to be in my 2.7 LLVM Debian package.

Sorry for the noise but the sentence wasn't actually intelligible
without the correction.

I suggest you getting the SVN code, since quite a lot has changed
since last freeze.

Vigourously seconded. It's very true in general, but with regards to debug information in particular, "quite a lot has changed since 2.7" is an understatement. It's an area of extremely active development (and improvement!).

-Jim

[...]

I suggest you getting the SVN code, since quite a lot has changed
since last freeze.

Vigourously seconded. It's very true in general, but with regards to debug information in particular, "quite a lot has changed since 2.7" is an understatement. It's an area of extremely active development (and improvement!).

I really don't want to build from SVN --- developing against a moving
target is never fun, and apart from anything else, it makes it much
harder for anyone else to use my code.

I gather 2.8 is coming along soon; is there an ETA yet? And until then
is there a snapshot of the 2.7 documentation anywhere online?

(PS. Please don't cc me on replies. I'm on the list, I don't need two
copies.)

The schedule is on the right side of the http://llvm.org/ web page.

-Chris

I'd like my compiler to emit proper line number information. The docs
talk about Instruction::setDebugLoc(), but that method doesn't actually
have to be in my 2.7 LLVM Debian package. What's the correct way of
doing this?

Which docs are you referring here ?

I really don't want to build from SVN --- developing against a moving
target is never fun, and apart from anything else, it makes it much
harder for anyone else to use my code.

Actually, unless you're planning to release your code in less than 2
months, developing in the SVN makes much more sense than 2.7.

I gather 2.8 is coming along soon; is there an ETA yet? And until then
is there a snapshot of the 2.7 documentation anywhere online?

From the homepage, If you go on docs, there's a red message pointing

you to here:

http://llvm.org/releases/

Which contains downloads, release notes and the docs for every release.

(PS. Please don't cc me on replies. I'm on the list, I don't need two
copies.)

Your mail client should know better... Mine does. :wink: You're not being
CC'd, the list is...

[...]

Which contains downloads, release notes and the docs for every release.

Unfortunately the doxygen API documentation link at
http://llvm.org/releases/2.7/docs/index.html actually link to the main
doxygen pages, which appear to be based on head-of-SVN. In fact, the
doxygen links for *all* releases point there!

Is this intention, or a linkage failure?

(I find the doxygen docs really useful as an index to let me find which
headers actually contain the classes.)

[...]

(PS. Please don't cc me on replies. I'm on the list, I don't need two
copies.)

Your mail client should know better... Mine does. :wink: You're not being
CC'd, the list is...

Yeah, sorry, that was the wrong piece of boilerplate.

I suppose I should really add a new boilerplate for 'Please don't send
list messages directly to me as that way they don't have the List-Id
header, which means that even though procmail is correctly filtering the
messages my MUA doesn't know they belong to a mailing list, and
therefore doesn't show a 'Reply To List' option, thus forcing me to
either manually edit the sender list every time I want to reply to one
of these messages, or else have to write procmail rules to manually
reinsert the List-Id header for messages that are cc'd to the list but
haven't arrived via the mailing list server, and forcing me to have to
read the procmailrc man page is just *evil*', but that's a bit long...

(Plus it's antisocial for anyone who reads the mailing list via GMANE
NNTP, message digests, etc.)