[llvm-commits] new patches for compiling linux with integrated-as

[Chandler Carruth]

On Sun, Nov 4, 2012 at 12:36 PM, PaX Team <pageexec at freemail.hu> wrote:
> On 4 Nov 2012 at 12:04, Eli Friedman wrote:
>
>> On Sun, Nov 4, 2012 at 8:57 AM, PaX Team <pageexec at freemail.hu> wrote:
>> > hello folks,
>> >
>> > here's the latest batch of patches that are needed for compiling linux (the kernel).
>> >
>> > - .octa support: this is a GNU as keyword used by some crypto code in linux.
>> >   nothing changed since the last submission last spring, would be nice if someone
>> >   looked at it finally ;). as i said back then, this is a minimal implementation,
>> >   full 128 bit expression support would require way too many changes (APInt would
>> >   have to be used throughout in MCExpr).
>> >
>> > - more .cfi* support: linux makes use of 3 CFI directives not yet (fully) supported
>> >   by llvm.
>> >
>> >   .cfi_startproc simple: i added the 'simple' keyword recognition but a review is needed.
>> >
>> >   .cfi_undefined: new directive, it's only recognized, someone else will have to provide
>> >   a proper implementation in MCStreamer::EmitCFIUndefined.
>> >
>> >   .cfi_register: new directive, i think MCStreamer::EmitCFIRegister does what it
>> >   should do, but review (and help with fixing it up :) is needed.
>> >
>> > - more macro args changes: most of the macro default arg handling stuff is now in
>> >   llvm, these are the remaining bits in my tree that allow nesting and fix up whitespace
>> >   separated parameter handling and add some comments. right now one of the macro tests
>> >   fails, but i didn't figure out yet what i managed to overlook, help is appreciated :).
>> >
>> > - x86 signed reloc handling: as i said last time, llvm generates wrong code in linux
>> >   and short of someone figuring out how to properly recognize the affected insns, this
>> >   is a minimal fix.
>> >
>> > cheers,
>> >   PaX Team
>>
>> Please send one patch per email.  Please include testcases in each patch.
>
> i didn't mean to submit these patches for inclusion, but more like a request for
> comments/help on the approach in each. can you/anyone help me out there?

While I agree with Eli (especially about starting off with test
cases), I also want to clarify something:

There is *definite* interest in this. And if you're trying to choose
which to send first, I would vote for the macro args one. We recently
hit this as well, and would be interested in working with you to get
support implemented. CC-ing Nick who has been looking at these issues,
he would likely be a good reviewer candidate.