@abidh @ki.stfu Do you have any feedback? We would like to check this in and I want to get more sign off then just me.

closed with http://reviews.llvm.org/rL265858

Ok, thanks.

@zturner I successfully submitted my test commit from an svn working copy. My former workflow was to use the read only git mirror, generate a diff, and submit it through this tool. Is there a better way to use differential so that I can submit directly via an approved code review?

@zturner I have been granted commit after approval from Chris. How do I commit from here?

I requested it, thanks for the heads up!

Can you check this in for me?

Thanks! Can you or somebody with commit access check this in for me?

Thank you.

Thank you.

Can somebody please check this in?

Merge the new disassembly test into the original

Added test for escaped characters in disassembly comments

I do need the --waitfor option. I am now skipping these tests on Linux.

I removed the requirement for -file-exec-and-symbols to be called before -target-attach. I was able to fix the tests for -target-attach <pid> and -target-attach -n <name>. I was able to get -target-attach -n <name> --waitfor to work in practice, but not through the python test without first issuing a -file-exec-and-symbols. Any help would be appreciated.

Respond to Ilia K's feedback.

Could somebody please check this in for me?

Thank you for the information.

That would be perfect, thanks.

Do I need more sign off to get this checked in?

What do you mean? It is printed:

Can somebody check this in for me now that it has been approved?

moved test

All lld-mi tests passing.

added test

In D8430#143454, @ki.stfu wrote:

I agree with @abidh, that we should add tests for this. Could you do it?

removed extraneous fix. Can somebody please check this in on my behalf?

I fixed the comments based on feedback from Ilia K. Can somebody please check this in on my behalf?

I am now using the PRIx64 macro in all locations. I checked and made sure that every type being used is either an MIUint64 or and lldb::addr_t, both of with are uint64s. I also noticed that IDS_CMD_ERR_LLDB_ERR_READ_MEM_BYTES was being initialized twice, and switched the second initialization to the correct IDS_CMD_ERR_LLDB_ERR_NOT_WRITE_WHOLEBLK

Fixed all the places I could find.

In D8210#140012, @abidh wrote:

In D8210#139990, @ChuckR wrote:

I am still new to this and I cannot commit directly. Should I submit a new patch with these minor changes, or will somebody with commit access make them and submit on my behalf?

I will commit it for you after making those few changes.

I am still new to this and I cannot commit directly. Should I submit a new patch with these minor changes, or will somebody with commit access make them and submit on my behalf?

Added comment on FileExecAndSymbols to see MIExtensions.txt. Fixed capitalization in comments.

Updated based on code review feedback. We confirmed that the interpret-exec command does not suit our needs, and have documented the flags that we have added to file-exec-and-symbols.

These are the files that have the string '%08' in them, should I fix all of them up as part of this patch?

In D8210#138718, @ki.stfu wrote:

In D8210#138716, @abidh wrote:

In D8210#138699, @ki.stfu wrote:

In D8210#138690, @abidh wrote:

I personally don't like using "-interpreter-exec" when there are proper MI commands available to do the job. But if start adding option/commands in lldb-mi for every options available in lldb proper then it will also get a little messy. Would it work for you to use "-interpreter-exec" as Ilia suggested above?

I don't insist on it if these options are well-known. As I said I don't see them in description of -file-exec-and-symbols command.

These options are not standard MI options. ChuckR is probably trying to add in lldb-mi what he see in "Target Create" command in lldb.

Then I dislike this patch. I'm not sure that we should add custom options. Is there another way to do it?