similar to: Handling DWARF "units"

Hello DWARF fans, I've just posted a set of four refactoring patches for DebugInfo/DWARF, which move in the direction of handling DWARF v4 or v5 type units and compile units more coherently. In DWARF v4, type units and compile units are strictly segregated into the .debug_types and .debug_info sections, respectively. This division was pretty ingrained into how DebugInfo/DWARF handled the

Hi all ! We have an issue with LLD, it is "relocation R_X86_64_32 out of range" (PR31109) which occurs during resolving relocations in debug sections. It looks happens because .debug_info section can be too large sometimes and 32x relocation is not enough to represent the value. One of possible solutions looks to be to deduplicate information to reduce .debug_info size. The rest of

At least one proprietary linker put a lot of effort into deduplicating and rewriting debug information. This took up the majority of the link time despite serious engineering time on performance optimisation. For example, some sections were written from scratch by the linker because that proved faster than parsing the input. Teaching LLD to dedup DWARF should be expected to dramatically slow it

Thanks for providing the experimental data! It clearly shows the value of type sections in DWARF. Regarding why type sections are off by default, aside from the issue of consumers needing to understand them, there is a size penalty to type sections that becomes more evident in smaller projects (meaning, fewer compilation units). The size penalty can be balanced against the amount of

>*nod* That's been the historic ELF+DWARF approach, but both MacOS (with dsyms+DWARF) and Windows >(COFF+CodeView+PDB) don't do it that way, and instead involve the linker to a degree. >Mostly I'm wondering if it'd be reasonable to (and if anyone would be interested in doing it) do >something more like the PDB support - fully debug-aware linking. Honestly saying I only

On 30 January 2018 at 16:39, Jan Kratochvil <jan.kratochvil at redhat.com> wrote: > On Wed, 17 Jan 2018 17:13:36 +0100, Pavel Labath via lldb-dev wrote: >> so I'm writing this email to see if there's anyone >> else interested in this topic, and to try to synchronize our efforts. > > I am sure interested in DWARF-5 .debug_names. I wrote its producer+consumer >

Hi all, I try to develop my own R package. I have a couple of standart functions like dim() and length() overloaded. #Example dim.Model <- function(this) { length(unique(this$.variables)); } I built my package, but when I try to load it... This message appears: Attaching package 'mudim': The following object(s) are masked _by_ .GlobalEnv : dim.Model,...(etc.) Any

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Thu, Jun 20, 2013 at 10:52 PM, Manman Ren <mren at apple.com> wrote: > > --------------------- > > Option b) I am going to expand David's description with more details, > correct me if I am wrong. > > I'll let David continue this part of the thread with you. > > >

>If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication. > >This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM. > >This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. >Though

https://bugzilla.mindrot.org/show_bug.cgi?id=1648 Summary: Fix IPV6_V6ONLY for -L with -g Product: Portable OpenSSH Version: -current Platform: All OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy: jan.kratochvil

Debuginfo and linker folks, we (AccessSoftek) would like to suggest a proposal for removing obsolete debug info. If you find it useful we will be happy to work on improving it. Thank you for any opinions and suggestions. Alexey.     Currently when the linker does garbage collection a lot of abandoned debug info is left behind (see Appendix A for documentation). Besides inflated debug info size,

Hi GNU command 'cp' normally looks for the block size of the destination and then uses such buffer to copy the file. Unfortunately you are settings block size for smbfs filesystems as 512 and using 'cp' then wastefully generates a lot of small (for ethernet) packets. I was surprised that using 'cat a >/net/b' is almost TWICE as fast than the traditional 'cp a

Samba Users: Here's a summary for several responses I have received since my original posting yesterday. Thanks for your help. Jan Kratochvil had a suggestion on running 'tcpdump' obtained from the Samba site. I did this for the station having difficulty, and the program core-dumped. From reading the resulting output created, that data starts to transfer and then becomes 0000 values.

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

> On Sun, 15 Nov 1998, Jan Kratochvil wrote: > Hmmm... are you saying the Ethernet driver was broken on the Windows > machine, or under Linux? I assume the DOS/Win machine.... I may look into No - Linux. :-) Becker's tulip.c was the one distributed with Linux kernel (not the one from Becker's web) and it was dropping packets massively probably due to missing PCI kludge

> On Jun 15, 2018, at 10:40 AM, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: Greg Clayton [mailto:clayborg at gmail.com <mailto:clayborg at gmail.com>] >> Sent: Friday, June 15, 2018 12:46 PM >> To: Robinson, Paul >> Cc: labath at google.com <mailto:labath at

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on

The patch below removes an outdated samba ChangeLog file. diffstat output: fs/smbfs/ChangeLog | 160 --------------------------------------------- 1 files changed, 160 deletions(-) Signed-off-by: Adrian Bunk <bunk@stusta.de> --- linux-2.6.10-rc3-mm1-full/fs/smbfs/ChangeLog 2004-10-18 23:54:55.000000000 +0200 +++ /dev/null 2004-11-25 03:16:25.000000000 +0100 @@ -1,160 +0,0 @@

I have been using Samba 1.9.18p8 in a Solaris 2.6 machine for months but suddenly this week there is a problem. Nothing's changed. I have some persistent connection of my NTSP3 client to the samba share. When I login as usual, it fails to mount the drive. It either prompt for password but whatever password the samba rejects, or give a "Access is Denied" when you try to access the