similar to: Handy file storage for LLD/ELF --reproduce

If we can, I would like to increase the bugzilla attachment size limit anyway. Users attempting to attach preprocessed source run into this limit all the time and have to use google drive or something. On Wed, Jul 13, 2016 at 7:19 AM, James Y Knight via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This sounds like a bad idea. Let's just increase the limit in bugzilla >

Tanya, could you increase the max attachment size limit on LLVM's bugzilla? -- Sean Silva On Wed, Jul 13, 2016 at 7:19 AM, James Y Knight <jyknight at google.com> wrote: > This sounds like a bad idea. Let's just increase the limit in bugzilla > instead? The limit is just a configuration option... > > On Jul 13, 2016 3:56 AM, "Sean Silva via llvm-dev" <

On Thu, Jul 14, 2016 at 4:49 PM, Tanya Lattner <tanyalattner at llvm.org> wrote: > What were you thinking? I increased it to 5MB.. but it sounds like you > have 26MB attachments? > Is 50MB doable? -- Sean Silva > > -Tanya > > On Jul 13, 2016, at 2:46 PM, Sean Silva <chisophugis at gmail.com> wrote: > > Tanya, could you increase the max attachment size

I can't send the exact objects, but I'll try to reproduce. Thanks A On 11/16/20, 9:48 AM, "Fāng-ruì Sòng" <maskray at google.com> wrote: NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Mon, Nov 16, 2020 at 9:05 AM Moshtaghi, Alireza

I'm having a curious issue with LLD/x86_64 linux/elf (Ubuntu 14.04); Where the l_addr of the link_map is invalid when linked with lld, but is fine with gnu ld. I'm using the libgc (boehm) code which when initializing reads the DYNAMIC/DEBUG link_map data, and crashes because the l_addr field has value out of readable memory. The strange this is that it happens only on some linux

This is a common pitfall: people think that .text is the first section of the traditional concept "text segment" (which does not apply with LLD layout and GNU ld's -z separate-code layout) You need to use --image-base=0 https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html#breaking-changes On Mon, Nov 16, 2020 at 10:31 AM Moshtaghi, Alireza <Alireza.Moshtaghi at

Hi Sean On Sun, Feb 26, 2017 at 5:10 AM, Sean Silva <chisophugis at gmail.com> wrote: > > For that triple, Clang seems to be calling into GCC driver > (/usr/bin/arm-none-eabi-gcc) for linking and GCC doesn't recognize > -fuse-ld=lld (supposedly -fuse-ld=gold selects ld.gold, -fuse-ld=bfd > selects ld.bfd and you would expect -fuse-lld=lld to select ld.lld, but it >

My target requires that text section be at 0x0 so "-Ttext 0x0" is passed to the linker. When I link with gold, it goes through; but lld fails. Instead of always returning the same calculation, when I change the calculation to the following, it links: return first->offset + (os->addr > first->addr ? os->addr - first->addr :

On Mon, Nov 16, 2020 at 9:05 AM Moshtaghi, Alireza <Alireza.Moshtaghi at netapp.com> wrote: > > My target requires that text section be at 0x0 so "-Ttext 0x0" is passed to the linker. > When I link with gold, it goes through; but lld fails. > Instead of always returning the same calculation, when I change the calculation to the following, it links: > return

Actually it is the combination of -Ttext 0x0 and --no-rosegment that cause the problem. You can reproduce using any c file using following: clang test.c -fuse-ld=lld -Wl,-Ttext,0x0 -Wl,--no-rosegment A On 11/16/20, 9:52 AM, "llvm-dev on behalf of Moshtaghi, Alireza via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: NetApp

Hi, I stopped into IRC to ask about a problem I've been having using Clang in conjunction with LLD to compile and link for an embedded project on Cortex-M ARM processor. First, I am able to separately compile with a call to clang and link with a call to lld, but I cannot use clang to link using lld using the -fuse-ld=lld flag. I have the output from `clang -v -fuse-ld=lld -target

I've been implementing ELF/AArch64 support for lld. I can now successfully link and run a simple "Hello World" app for both dynamic and static linking. I'd like to upstream this implementation, but wanted to get feedback on how people might like to see it. Would people rather see the whole thing in one shot, each file individually or somehow break it down even farther? The

make -r -C /mlsyslinux -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ OBJ=/mlsyslinux objdir=/mlsyslinux bios make[1]: Entering directory `/mlsyslinux' make -r -C /mlsyslinux/bios -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ objdir=/mlsyslinux/bios OBJ=/mlsyslinux/bios HAVE_FIRMWARE=1 \ ARCH=i386 LDLINUX=ldlinux.c32 all make[2]:

> > according to the documentation the option ucode=scan should tell XEN to > > look for a microcode update in an uncompressed initrd. > > > > While I don?t use the Debian kernel the tools to generate the initrd are > > part of Debian. The command ?cpio -i < /boot/initrd.img-4.0.2-Dom0? > > creates the directory structure

Can someone explain why this: find . -depth -print0 | cpio --null -pmd /tmp/test will copy all files in and below the current directory -and- this: find . -depth -print | grep -v .iso$ | wc -l will count all the non-iso files -and- this: find . -depth -print | grep .iso$ | wc -l will count *only* the iso files -but- this: find . -depth -print0 | grep -v .iso$ | cpio --null -pmd /tmp/test

Unlink files, symlinks, FIFOs, devices etc. (except directories) before writing them when extracting CPIOs. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non-link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2) if the first version of file foo is larger

On Thu, Oct 30, 2008 at 11:05 PM, Richard Elling <Richard.Elling at sun.com> wrote: > Philip Brown wrote: >> I''ve recently started down the road of production use for zfs, and am hitting my head on some paradigm shifts. I''d like to clarify whether my understanding is correct, and/or whether there are better ways of doing things. >> I have one question for

> -----Original Messages----- > From: "Steven Tardy" <sjt5atra at gmail.com> > Sent Time: 2018-02-26 10:48:48 (Monday) > To: "CentOS mailing list" <centos at centos.org> > Cc: > Subject: Re: [CentOS] How to update modules in iniramfs fastly > > On Sun, Feb 25, 2018 at 8:29 PM wuzhouhui <wuzhouhui14 at mails.ucas.ac.cn> > wrote:

hello, On Mon, 16 Jun 2008, Joey Hess wrote: > klibc cpio segfaults extracting various cpio files. It seems to work for > small files, but fail for larger ones, including the d-i root floppy > image. > > For example: > > joey at kodama:/tmp/empty>wget http://people.debian.org/~joeyh/d-i/images/20080401-09:01/floppy/root.img > joey at kodama:/tmp/empty>zcat

I posted this message first. But it was missing so I post again. I think there is a some bug in build configration files. Can you check up the following errors and fix it? The error has no concern with UTF-8 patch. Environment : CentOS 4.3 x86_64 Sungsoo Kim ---------------------------------- [root at saturn xapian-core-0.9.4_svn6707]# make ... ... mkdir .libs/libxapian.lax/libqueryparser.a