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

[Eli Friedman]

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?

Sorry, I'm not really familiar enough with the asmparser to help out here.

More generally, though, even if you don't think your patch is right,
it's still better to submit one patch per thread, with testcases.
Separate threads means independent discussion won't get mixed up, and
are more likely to attract the attention of the right people.
Testcases are generally helpful for discussion and review; among other
things, they clearly indicate the intent of the patch.

-Eli