Displaying 20 results from an estimated 20000 matches similar to: "[LLVMdev] How to carry a command line option down to the Object Writer"
2010 Nov 18
3
[LLVMdev] MC ELFObjectWriter backend refactoring
I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a
2012 Mar 23
0
[LLVMdev] Sorting relocation entries
Hi Jim,
Thanks for reviewing the patch.
I couldn't get rid of STLExtras.h, but other than that, I followed all
the suggestions in your email.
Please let me know if you notice anything else that needs fixing.
On Thu, Mar 22, 2012 at 4:42 PM, Jim Grosbach <grosbach at apple.com> wrote:
> Hi Akira,
>
> This is looking good. Some specific comments on the details below.
>
>
2012 Mar 23
1
[LLVMdev] Sorting relocation entries
Hi Akira,
Just two very minor things that I missed the first time around.
1. The 'fixup" member of ELFRelocation entry should be "Fixup" instead.
2. Since we're always passing in a non-NULL fixup, that should probably be a reference, not a pointer.
Good for commit with those tweaks.
Thanks!
-Jim
On Mar 23, 2012, at 1:07 PM, Akira Hatanaka wrote:
> Hi Jim,
>
2012 Mar 22
2
[LLVMdev] Sorting relocation entries
Hi Akira,
This is looking good. Some specific comments on the details below.
Thanks!
Jim
> diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h
> index 6e9f5d8..220ecd0 100644
> --- a/include/llvm/MC/MCELFObjectWriter.h
> +++ b/include/llvm/MC/MCELFObjectWriter.h
> @@ -13,6 +13,7 @@
> #include "llvm/MC/MCObjectWriter.h"
>
2012 Nov 27
0
[LLVMdev] [cfe-dev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
> Are there other names that are poor choices and are lingering in our
> codebases? I'm willing to sign up to do more renames while I'm at
> this, so this is a chance to get someone else to do the heavy lifting.
> =]
Class names too, not just file/directory names?
I've been trolling through the integrated assembler lately, and had a
real "can't tell the players
2011 Nov 15
2
[LLVMdev] MCELFStreamer subclassing
On Tue, Nov 15, 2011 at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote:
>
> On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote:
>
>> Jim,
>>
>> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data.
>>
>> The issue I was having was
2011 Nov 15
0
[LLVMdev] MCELFStreamer subclassing
Hi Jack,
I'm not 100% up on how MIPS represents jump tables, so take with a grain of salt and all that.
Normally how this stuff works is that the streamer will create Fixups (MCDataFragment::addFixup()) for anything that might require a relocation. That may come from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for
2011 Nov 15
0
[LLVMdev] MCELFStreamer subclassing
On Nov 15, 2011, at 10:36 AM, Carter, Jack wrote:
> Jim,
>
> Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data.
>
> The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer
2011 Nov 15
2
[LLVMdev] MCELFStreamer subclassing
Jim,
Ok, you are where I am in the understanding. This is exactly what I do for relocations applied to code. Now I want to apply fixup information to relocations applied to data.
The issue I was having was the difficulty of subclassing MCELFStreamer. Or are you saying that I should be messing with the base MCELFStreamer for a specific fixup.
One of the issues I hit initially with llvm is that
2011 Jul 07
1
[LLVMdev] Sefault in llvm-mc when emitting an object file
Hello,
I'm trying to use MC to assemble some code into a memory buffer.
Whilst trying this, I ran into a segfault that I was able to reproduce
using the llvm-mc tool (which makes me think it's not just me using
the library incorrectly.)
The bug looks like this (the binary is from a clean build of the 2.8 release):
$ cat test/asm1.s
movl %ebx, %eax
$ ~/root/bin/llvm-mc --filetype=obj
2012 Mar 22
0
[LLVMdev] Sorting relocation entries
Here is the patch.
On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote:
> Hi Jim,
>
> Yes, the relocation entries have to be reordered so that the
> got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation
> table. As a result, relocations can appear in a different order than
> the instructions that they're for.
>
> For
2012 Mar 22
2
[LLVMdev] Sorting relocation entries
Hi Jim,
Yes, the relocation entries have to be reordered so that the
got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation
table. As a result, relocations can appear in a different order than
the instructions that they're for.
For example, in this code, the post-RA scheduler inserts an
instruction with relocation %got(body_ok) between %got(scope_top) and
%lo(scope_top).
$ cat
2010 Jul 21
0
[LLVMdev] MC-JIT
On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant
<meurant.olivier at gmail.com> wrote:
> New patch taking Eli's comments into account.
Comments inline. If you have commit access, I'd fire away. If not, I can.
diff --git include/llvm/MC/MCAssembler.h include/llvm/MC/MCAssembler.h
index 07ca070..afff96e 100644
--- include/llvm/MC/MCAssembler.h
+++ include/llvm/MC/MCAssembler.h
2010 Nov 12
0
[LLVMdev] [llvm-commits][PATCH] elfobjectwriter patch (ARM/MC/ELF)
+llvmdev
On Fri, Nov 12, 2010 at 7:57 AM, Jim Grosbach <grosbach at apple.com> wrote:
>
> On Nov 10, 2010, at 9:57 AM, Jason Kim wrote:
>
>> Refactoring the x86 dependent code from ELFObjectWriter class has
>> repercussions among several (conflicting) axes of consideration,
>>
>> 1. namespace pollution - minimize pollution of the llvm: namespace
>> 2.
2010 Jul 21
1
[LLVMdev] MC-JIT
New patch. Thanks for all of your comments !
> Comments inline. If you have commit access, I'd fire away. If not, I can.
I don't have commit access, if you find it ok, please commit it. :)
Olivier.
On Wed, Jul 21, 2010 at 6:56 AM, Reid Kleckner <reid.kleckner at gmail.com> wrote:
> On Tue, Jul 20, 2010 at 3:41 PM, Olivier Meurant
> <meurant.olivier at gmail.com>
2010 Jul 20
0
[LLVMdev] MC-JIT
On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant
<meurant.olivier at gmail.com> wrote:
>> Seems reasonable, but I haven't looked at the code yet. I would
>> suggest trying to split your work up into separate patches which
>> implement incremental pieces of functionality, then submitting them to
>> llvm-commits for review. That is much easier for us to deal with
2010 Jul 20
2
[LLVMdev] MC-JIT
New patch taking Eli's comments into account.
Olivier.
On Tue, Jul 20, 2010 at 11:09 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Tue, Jul 20, 2010 at 1:36 PM, Olivier Meurant
> <meurant.olivier at gmail.com> wrote:
>>> Seems reasonable, but I haven't looked at the code yet. I would
>>> suggest trying to split your work up into separate
2004 Sep 10
0
command-line: AIFF writer advice
On Tue, Jul 30, 2002 at 09:04:38PM -0500, Brady Patterson wrote:
> The patch I submitted only reads AIFF files. I'm about to start the patch to
> write AIFF files.
>
> To do so, we need a command-line option to specify AIFF. My inclination is to
> add an option:
>
> -ff { raw | wav | aif }
>
> In some sense, "-ff" is silly since it probably stands
2004 Sep 10
0
command-line: AIFF writer advice
On Tue, 30 Jul 2002, Josh Coalson wrote:
(Matt wrote):
> > A more flexible approach might be to use libaudiofile or a similar facility,
> > so that multiple input formats can be automatically recognized, and future
> > formats supported in a generalized way.
Agree completely. I did this because I wanted to get something working with as
small a change as possible.
> Brady, I
2004 Sep 10
2
command-line: AIFF writer advice
How about the opposite?
What I would like to see is FLAC support in libaudiofile, so
applications written with libaudiofile could transparently take
advantage on FLAC's compression. Ironically I guess it would still make
sense to use libaudiofile in FLAC for getting input. Mmmm, cyclic
dependancies...
Or is that just a stupid idea?
Dave
On Wed, 2002-07-31 at 13:10, Matt Zimmerman wrote:
>