search for: sh_info

On 2020-11-17, Igor Kudrin wrote: > >On 17.11.2020 14:05, Fāng-ruì Sòng wrote: >>On Mon, Nov 16, 2020 at 10:42 PM Igor Kudrin <ikudrin at accesssoftek.com> wrote: >>> >>>On 14.11.2020 3:42, Fāng-ruì Sòng wrote: >>>>For .debug_* in object files: >>>> >>>>DWARF32 -> SHT_PROGBITS (unchanged) >>>>DWARF64 ->

On 2020-11-12, Alexander Yermolovich wrote: >Thanks for feedback. > >I agree with patch and numbers this will be a more concrete discussion, but I wanted to judge overall receptiveness to this approach and see maybe there was a better way. > >"Whilst the majority of objects will only have a single CU in them, there will be exceptions (LTO-generated objects, -r merged objects

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

Hi Martin, Thank you for sending the script. I can reproduce the issue with it. It looks like the program crashes when it tries to call std::vector<sometype>'s ctor from a static initializer. I don't fully understand what is causing the issue yet, but here are my observations. - Since you are creating a temporary object file using `ld.gold -r`, your object file contains multiple

...INVALID_GRANT_REF (0) #define INVALID_EVTCHN (-1) -struct pci_bus_entry { - struct list_head list; - struct pci_bus *bus; -}; - #define _PDEVB_op_active (0) #define PDEVB_op_active (1 << (_PDEVB_op_active)) @@ -47,12 +42,12 @@ struct pcifront_device { struct xen_pci_sharedinfo *sh_info; struct work_struct op_work; unsigned long flags; - }; struct pcifront_sd { int domain; struct pcifront_device *pdev; + struct resource busn_res; }; static inline struct pcifront_device * @@ -67,6 +62,12 @@ static inline void pcifront_init_sd(struct pcifront_sd *sd, { sd->doma...

...INVALID_GRANT_REF (0) #define INVALID_EVTCHN (-1) -struct pci_bus_entry { - struct list_head list; - struct pci_bus *bus; -}; - #define _PDEVB_op_active (0) #define PDEVB_op_active (1 << (_PDEVB_op_active)) @@ -47,12 +42,12 @@ struct pcifront_device { struct xen_pci_sharedinfo *sh_info; struct work_struct op_work; unsigned long flags; - }; struct pcifront_sd { int domain; struct pcifront_device *pdev; + struct resource busn_res; }; static inline struct pcifront_device * @@ -67,6 +62,12 @@ static inline void pcifront_init_sd(struct pcifront_sd *sd, { sd->doma...

...INVALID_GRANT_REF (0) #define INVALID_EVTCHN (-1) -struct pci_bus_entry { - struct list_head list; - struct pci_bus *bus; -}; - #define _PDEVB_op_active (0) #define PDEVB_op_active (1 << (_PDEVB_op_active)) @@ -47,12 +42,12 @@ struct pcifront_device { struct xen_pci_sharedinfo *sh_info; struct work_struct op_work; unsigned long flags; - }; struct pcifront_sd { int domain; struct pcifront_device *pdev; + struct resource busn_res; }; static inline struct pcifront_device * @@ -67,6 +62,12 @@ static inline void pcifront_init_sd(struct pcifront_sd *sd, { sd->doma...

...he upstream kernel first as > those patches are there. According to one Qubes OS user report[1], the bug was introduced between version, which differs only by XSA-155 patches (including one for pciback), especially not XSA-157. Maybe on some code path, some value is not copied back to pdev->sh_info->op? [1] https://groups.google.com/d/msgid/qubes-devel/e64792c5-b9af-42ac-8d67-adce426b9dcb%40googlegroups.com -- Best Regards, Marek Marczykowski-G?recki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -------...

...there. > > > > According to one Qubes OS user report[1], the bug was introduced between > > version, which differs only by XSA-155 patches (including one for > > pciback), especially not XSA-157. > > Maybe on some code path, some value is not copied back to pdev->sh_info->op? > > I found two bugs (attached the draft not-compiled patches). Upstream > wise I seem to be tripping over another issue. > > There is also some more work required in there to fix the MSI-x enable op. What exactly do you have in mind here? That four patches in your next em...

Hello, all experts. When I use pid provider, my Dscript with -F option output the codepath with flowindent as you know, e.g. -> main -> f1 -> f2 however I realized that the exec file I used at that time was stripped. Does anyone know the reason why I could see the function names? Thanks in advance. -- This message posted from opensolaris.org

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

On 23 May 2018 at 23:07, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > On Wed, May 23, 2018 at 12:16 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: >> >> On Wed, May 23, 2018 at 3:25 AM, Peter Smith <peter.smith at linaro.org> >> wrote: >>> >>> Hello, >>> >>> I think that the approach of using a

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

...t mixed single input" case directly (though might allow the user to dodge the decision at least). > > Other ideas I had involved changing the section header properties. Currently DWARF sections are all SHT_PROGBITS, but we could change that to e.g. SHT_DWARF_32 or similar, and/or use the sh_info field to contain a value that would indicate the 32/64 bit nature. I'm not convinced by these ideas though, as a) I don't know if it translates well to other non-ELF formats, and b) we can't really control the producers of DWARF at this stage to conform. > > It would be nice if th...

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

...need circulating on the DWARF mailing list too, since it is more a DWARF issue than a gABI issue (unless the solution is a new section type). Further refinements to this idea that might make it more appealing to the generic group: `SHT_DEBUG` for the section type name, with the first N bytes of the sh_info used to specify the variant of debug data it represents (e.g. 0x1 for DWARF, 0x2 for SOME_OTHER_STANDARD etc), and the remainder for use as flags as defined by the standard (I'm thinking for DWARF you could encode the 64-bit/32-bit state in there, possibly the section variant (info/rnglists/lin...

...e, is that it does modify ELF format spec, and can break various tools that rely on this information. This sems somewhat of a heavy handed approach to solving this problem. Alternatively, if we do want to go with something more official then just doing it in a linker using first reloc, why not use sh_info? Seems like it's made for providing an extra information for each section_type. In this case .debug_*. With it we have a current behavior of using names which as far as I can tell the default for figuring out debug sections. If producer provides this extra information the linker can improve la...

+James for context too (always good to include the folks from the original threads for continuity) Yeah, my general attitude there was just twofold, one that the discussion had strayed fairly far from the review (so interested parties might not see it, both because it's a targeted review thread on the noisy llvm-commits, and because fo the title not having much connection to the discussion)