[PATCH][REQUEST] Could someone submit this CSR Kalimba definitions patch please?

Hello LLVMdev!!

Yesterday I posted a patch request to the llvm-commits list requesting that someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get any response so I wondered whether I should have posted to this list instead.

My story is as follows: we are trying to get lldb/llvm support for CSRs range of Kalimba DSPs. Eventually we are planning to hire someone to write an LLVM backend for the core, but currently we/I are making to do with porting lldb to debug Kalimba chips via a bespoke gdbserver implementation.

In order to get lldb to recognise Kalimba DSPs I have had to add definitions for kalimba as an architecture and CSR as a vendor to Triple.h and Triple.cpp. So I have produced a patch with these changes and I wondered if anyone would be able to submit the patch for me?

If I am requesting this patch application in the wrong way, could someone point out to me the correct patch request process?

Patch pasted on bottom of mail and file attached.

thank you
Matthew Gardiner

    Index: include/llvm/ADT/Triple.h

Triple.patch (5.63 KB)

Hello LLVMdev!!

Yesterday I posted a patch request to the llvm-commits list requesting that
someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get
any response so I wondered whether I should have posted to this list
instead.

My story is as follows: we are trying to get lldb/llvm support for CSRs
range of Kalimba DSPs. Eventually we are planning to hire someone to write
an LLVM backend for the core, but currently we/I are making to do with
porting lldb to debug Kalimba chips via a bespoke gdbserver implementation.

In order to get lldb to recognise Kalimba DSPs I have had to add definitions
for kalimba as an architecture and CSR as a vendor to Triple.h and
Triple.cpp. So I have produced a patch with these changes and I wondered if
anyone would be able to submit the patch for me?

If I am requesting this patch application in the wrong way, could someone
point out to me the correct patch request process?

You got it right the first time, it's just it can take a while for
someone with the right context/time to take a look and apply a patch.
Generally speaking if you don't get a response in a week, it's
acceptable to 'ping' a patch (just reply-all to the original email you
sent to the -commits list, usually with the word 'ping').
Unfortunately this may need to be done more than once (with a week
between each) if people are particularly busy or you have a
particularly esoteric patch.

- David

David Blaikie wrote:

Hello LLVMdev!!

Yesterday I posted a patch request to the llvm-commits list requesting that
someone could apply a patch to Triple.h and Triple.cpp for me. I didn't get
any response so I wondered whether I should have posted to this list
instead.

My story is as follows: we are trying to get lldb/llvm support for CSRs
range of Kalimba DSPs. Eventually we are planning to hire someone to write
an LLVM backend for the core, but currently we/I are making to do with
porting lldb to debug Kalimba chips via a bespoke gdbserver implementation.

In order to get lldb to recognise Kalimba DSPs I have had to add definitions
for kalimba as an architecture and CSR as a vendor to Triple.h and
Triple.cpp. So I have produced a patch with these changes and I wondered if
anyone would be able to submit the patch for me?

If I am requesting this patch application in the wrong way, could someone
point out to me the correct patch request process?

You got it right the first time, it's just it can take a while for
someone with the right context/time to take a look and apply a patch.
Generally speaking if you don't get a response in a week, it's
acceptable to 'ping' a patch (just reply-all to the original email you
sent to the -commits list, usually with the word 'ping').
Unfortunately this may need to be done more than once (with a week
between each) if people are particularly busy or you have a
particularly esoteric patch.

- David

Ok, thanks for your tip, David.

I shall bide my time, and check back on llvm-commits every week or so.

thanks again,
Matt

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Any reason why you deleted code that isn't related?

-eric

Eric, looks like a misleading diff... that SubArchType stuff was reverted recently in trunk.

Jon

I recall that patch going across. There's just no reason for it in the
diff from Matthew.

-eric

Eric Christopher wrote:

Any reason why you deleted code that isn't related?

-eric

Sorry, apologies, for that. My company use perforce for version control and I have been keeping my local llvm/lldb changes on this depot. I can only assume that one of the code branches associated with my diff-generating process was out-of-date. I should have checked my patch better before posting. I'll regenerate a diff against a fresh svn of the llvm tree and post it to the llvm-commits list.

Matt

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Eric Christopher wrote:

Any reason why you deleted code that isn't related?

-eric

- enum SubArchType {
- NoSubArch,
-
- ARMSubArch_v8,
- ARMSubArch_v7,
- ARMSubArch_v7em,
- ARMSubArch_v7m,
- ARMSubArch_v7s,
- ARMSubArch_v6,
- ARMSubArch_v6m,
- ARMSubArch_v6t2,
- ARMSubArch_v5,
- ARMSubArch_v5te,
- ARMSubArch_v4t,
- ARMSubArch_v4
- };

Eric, looks like a misleading diff... that SubArchType stuff was reverted
recently in trunk.

I recall that patch going across. There's just no reason for it in the
diff from Matthew.

-eric

  To report this email as spam click https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== .

Hi people,

I apologise for the earlier bad diff. Here's one I've just generated against the latest svn. The TOT sources build fine with these additions. Is there any reason now why this patch cannot be submitted on my behalf? My concern is that I cannot submit further work for our chips to lldb until I have these definitions in llvm::Triple.

I'll also repost this patch to llvm-commits.

Thanks for your time and patience,
Matt

  Index: include/llvm/ADT/Triple.h

Triple.patch (2.28 KB)

There was a problem with the patch, you forgot to update
Triple::get64BitArchVariant and Triple::get32BitArchVariant and I've
added it as similar to 32-bit chips with no 64-bit variant. If this is
incorrect, please let me know.

Otherwise committed thusly:

M include/llvm/ADT/Triple.h
M lib/Support/Triple.cpp
Committed r212745

Thanks!

-eric

Eric Christopher wrote:

There was a problem with the patch, you forgot to update
Triple::get64BitArchVariant and Triple::get32BitArchVariant and I've
added it as similar to 32-bit chips with no 64-bit variant. If this is
incorrect, please let me know.

Otherwise committed thusly:

M include/llvm/ADT/Triple.h
M lib/Support/Triple.cpp
Committed r212745

Thanks!

-eric

Awesome! Thank you very much for doing this. I've just svn up'd and had
a look - the submission seems fine. As the day progresses I'll let you
know if I spot any issue with it. Now I'll be able to upstream my recent
kalimba lldb stuff and plough on with more dev.

thanks again
Matt

Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.