similar to: LLD handling of orphaned sections

On Fri, 21 Jun 2019 at 13:05, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I think Geroge (cc'ed) knows better than me in that area. > > lld is underdocumented, and in particular there is virtually no documentation about its linker script support. Our basic strategy is to follow the GNU's documentation and the implementations unless it is too hard or

lld does not seem to create the __start and __end symbols for orphan sections. I would like to keep my linker script as generic as possible so how can I tell lld to create these symbols without having to add them in the linker script? Thanks A -------------- next part -------------- An HTML attachment was scrubbed... URL:

You are right it creates them but sets the protected flag (STV_PROTECTED) which seems to be the cause of my problem. How can I tell it to set the flag as STV_DEFAULT? Thanks A On 5/28/20, 11:30 PM, "Fangrui Song" <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

On 2020-06-02, Moshtaghi, Alireza wrote: >Sorry for the cryptic code but I had to modify stuff from original >In the following example see the difference when you comment or uncomment the line in the linker script: >============ test.c ============= : >struct orphan_dummy_anno_s { > void (*func)(void); >}; > >static void dummy_export_dbg_log_init_f (void) __attribute__

I''m using the CentOS 6 bundle of xen from http://dev.centos.org/centos/6/xen-c6/ and ran into an issue when creating domains with multiple VHD tap disks. Comparing unstable to the 4.2.1 code I''m using, it seems this issue still applies. I''m using a configuration line that looks something like disk = [

Stephen, OK, I can now reproduce this hang at will, purely by pulling the plug on my desktop when logged in and then rebooting - its a gnome desktop box with few partitions and ext3 on all of them, so I guess its getting a pile of gnome or ssh related sockets kept in /tmp which is on root To recap, when the machine is suffering from this, it hangs at the point of mounting the root filesystem

Is there a list of commands for cleaning up orphaned DC's. I used ntdsutil on the Windows boxes no problem. Used an LDAP gui tool to remove the LDAP entries. Sadly Samba4 is still trying to contact the orphan. Any guidance or manual page would be appreciated. Cheers, TMS III

Dear R-Devel subscriber, I would like to raise a topic and ask for your advice, guidance. Today on R-help an issue with a certain package popped up that has been removed from CRAN, because it failed the checks and/or the dependencies are not any longer available. The package maintainer has been alerted to this issue a couple of times and kindly asked to fix the code, such that it fullfills the

Hello, yesterday I experienced following problem with my ext3 filesystem: - I had ext3 filesystem of the size of a few TB with journal. I correctly unmounted it and it was marked clean. - I then ran fsck.etx3 -f on it and it did not find any problem. - After increasing size of its LVM volume by 1.5 TB I resized the filesystem by resize2fs lvm_volume and it finished without problem. - But

On Fri, Apr 18, 2014 at 06:56:57PM +0200, Patrik Horn?k wrote: > > yesterday I experienced following problem with my ext3 filesystem: > > - I had ext3 filesystem of the size of a few TB with journal. I correctly > unmounted it and it was marked clean. > > - I then ran fsck.etx3 -f on it and it did not find any problem. > > - After increasing size of its LVM volume by

Hi, it seems you got it right! I don't know if you read email I sent you before posting to the mailing list, but I accidentally diagnosed the cause... :) I've noticed that inodes fsck warned me about, at least ones that I checked, all have all four timestamps latest in 2010... The filesystem has maximum 1281998848 inodes, which is timestamp in august 2010. I don't know how it got

Hi, i've still these orhpaned entries and don't know where to remove them. Samba-tool drs showrepl [.] CN=Configuration,DC=local,DC=laurenz,DC=ws NTDS DN: CN=NTDS Settings\0ADEL:262e2471-dc01-4d71-ae5d-f71f9d8c2d5d,CN=SHELBY\0ADEL:72a698fc -6b93-41d1-9961-504008ea2415,CN=Servers,CN=Zuhause,CN=Sites,CN=Configuration ,DC=local,DC=laurenz,DC=ws DSA

# HG changeset patch # User Roger Pau Monne <roger.pau@entel.upc.edu> # Date 1324385575 -3600 # Node ID 716d6d48e647d1d4352f7206e74e693152a4f8fa # Parent f72b99fccfca694674259cc1c03c526a827b67ec libxl: add support for yajl 2.x This patch adds support for yajl versions 2.x, while retaining 1.x compatibility. This patch adds quite a lot of #ifdefs all over the json code, so I''m open

Call update_domain_wallclock_time on hvm_latch_shinfo_size even if the bitness of the guest has already been set, this fixes the problem with the wallclock not being set for PVHVM guests on resume from migration. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: Keir Fraser <keir@xen.org> Cc: George Dunlap

Peter, Thanks for the great feedback! > The first is the use of a custom suffix, all other linker conventions, that I know of, use prefixes as these are much easier and faster to match against names. > This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match. I understand the reason of having these conventions in linkers. On the

Hi, I am doing some experimentation with xen and Ceph and have a problem booting my guest when my disk = [] uses an alternate block script. Installation from a .iso was ok since the boot device was a file but now trying to boot from the rbd neither the hvmbuilder or pygrub can start as they treat the first value after target= as the /dev node to try and use. My disk parameter looks like: disk =

The first patch is a leftover from the switch to libxl__create_qemu_logfile, and while there it also handles possible errors when opening /dev/null. The second one is a fix for the issues present in do_daemonize. Thanks, Roger.

When using a vtsc, hvm_set_guest_time changes hvm_vcpu.stime_offset, which is used in the vcpu time structure to calculate the tsc_timestamp, so after updating stime_offset we need to propagate the change to vcpu_time in order for the guest to get the right time if using the PV clock. This was not done correctly, since in context_switch update_vcpu_system_time was called before vmx_do_resume,

Resending after adding another patch to display delayed orphan scan statistics.

The aim of this patch is to define a stable way in which PVH is going to do AP bringup. Since we are running inside of a HVM container, PVH should only need to set flags, cr3 and user_regs in order to bring up a vCPU, the rest can be set once the vCPU is started using the bare metal methods. Additionally, the guest can also set cr0 and cr4, and those values will be appended to the default values