* Ulf Hermann:
> Some systems don't provide endian.h and byteswap.h. The required
> functions are trivial to define using sys/param.h and gcc builtins,
> though.
>
> Also, include endian.h in dwelf_scn_gnu_compressed_size.c as that uses
> be64toh().
This is still an issue with non-glibc, non-BSD
* Ulf Hermann:
>>> Some systems don't provide endian.h and byteswap.h. The required
>>> functions are trivial to define using sys/param.h and gcc builtins,
>>> though.
>>>
>>> Also, include endian.h in dwelf_scn_gnu_compressed_size.c as that uses
>>> be64toh().
>>
>> This is still an issue with n
* Mark Wielaard:
> On Sat, Feb 16, 2019 at 06:09:06PM +0100, Kurt Roeckx wrote:
>> On Debian's riscv64 port, this is a log of the build:
>> https://buildd.debian.org/status/fetch.php?pkg=elfutils&arch=riscv64&ver=0.176-1&stamp=1550335976&raw=0
>
> You are missing .eh_frame CFI. Without that backtr
This patch adds an elfclassify tool, mainly for the benefit of RPM's
find-debuginfo.sh.
I still need to implement an --unstripped option and fix the iteration
over the dynamic section.
Suggestions for improving the argp/help output are welcome as well. I'm
not familiar with argp at all.
I'm kee
* Mark Wielaard:
>> I still need to implement an --unstripped option and fix the
>> iteration over the dynamic section.
>
> We did already discuss some of this off-list.
Thanks for summarizing the previous discussion.
> --elf PATH return 0 whenever the file can be opened and a minimal ELF
> head
* Florian Weimer:
>> BTW. Florian, the extra options are certainly not required for you to
>> implement to get eu-elfclassify accepted. They are just suggestions,
>> which we might decide not to do/add. Or they can be added by others if
>> they think they are useful.
* Omar Sandoval:
> This makes sense. One thing I noted in the patch to export the libebl
> symbols [1] is that exporting them wouldn't necessarily mean supporting
> them as an official API. However, I can see why you'd be concerned with
> developers using them anyways.
You could ship a link-only
* Dmitry V. Levin:
>> So, I don't think the code is wrong. We might want to tweak the comment
>> a bit though, to make it less definitive?
>
> What I'm saying is that has_soname is just a hint which is probably even
> less reliable than has_program_interpreter.
If I recall correctly, I added the
* Mark Wielaard:
> On Thu, 2019-04-18 at 13:17 +0200, Florian Weimer wrote:
>> * Florian Weimer:
>>
>> > > BTW. Florian, the extra options are certainly not required for you to
>> > > implement to get eu-elfclassify accepted. They are just suggestions,
>
* Mark Wielaard:
> + if (elf == NULL)
> +{
> + /* This likely means it just isn't an ELF file, probably not a
> + real issue, but warn if verbose reporting. */
> + if (verbose > 0)
> + fprintf (stderr, "warning: %s: %s\n", current_path, elf_errmsg (-1));
> + return fa
* Mark Wielaard:
> +/* Called to process standard input if flag_stdin is not no_stdin. */
> +static void
> +process_stdin (int *status)
> +{
> + char delim;
> + if (flag_stdin == do_stdin0)
> +delim = '\0';
> + else
> +delim = '\n';
> +
> + char *buffer = NULL;
> + size_t buffer_size
* Mark Wielaard:
> Signed-off-by: Mark Wielaard
Does elfutils use DCO? Then yoy have my signoff as well:
Signed-off-by: Florian Weimer
You should you list yourself as an author somewhere in the commit
message. This is so much more than what I wrote.
Regarding the test case, I think if
* Mark Wielaard:
> On Mon, Jul 29, 2019 at 11:16:31AM +0200, Florian Weimer wrote:
>> * Mark Wielaard:
>>
>> > +/* Called to process standard input if flag_stdin is not no_stdin. */
>> > +static void
>> > +process_stdin (int *status)
>>
* Mark Wielaard:
>> Regarding the test case, I think if the build target is ELF, it makes
>> sense to check that the elfutils binaries themselves are classified as
>> expected, with the current build flags. This will detect changes
>> required due to the evolution of the toolchain.
>
> That is wh
* Mark Wielaard:
> What do you think about this change to dwelf_elf_begin?
> The change would make it possible to detect real errors in the
> elfclassify code, whether elf_begin or dwelf_elf_begin was used. So we
> would not misclassify files (but return an error status of 2).
I'm not really fami
* Mark Wielaard:
> It is already possible to select the symbol table to print by name,
> using --symbols=SECTION. This allows printing the dynamic symbol table
> with --symbols=.dynsym. binutils readelf allows printing just the
> dynamic symbol table by type using --dyn-sym. Add the same option
>
* Mark Wielaard:
> On Tue, 2019-09-03 at 09:44 +0200, Florian Weimer wrote:
>> * Mark Wielaard:
>>
>> > It is already possible to select the symbol table to print by name,
>> > using --symbols=SECTION. This allows printing the dynamic symbol table
>> >
* Jonathon Anderson:
> Just finished some modifications to the patch series, git request-pull
> output below. This rebases onto the latest master and does a little
> diff cleaning, the major change is that I swapped out the memory
> management to use the pthread_key_* alternative mentioned befo
* Mark Wielaard:
> I'll see if I can create a case where that is a problem. Then we can
> see how to adjust things to use less pthread_keys. Is there a different
> pattern we can use?
It's unclear what purpose thread-local storage serves in this context.
You already have a Dwarf *. I would consi
* Jonathon Anderson:
>> This assumes that memory allocation
>> is actually a performance problem, otherwise you could let malloc
>> handle the details.
>
> In our (Dyninst + HPCToolkit) work, we have found that malloc tends to
> be slow in the multithreaded case, in particular with many small
>
* Mark Wielaard:
>> Current glibc versions have a thread-local fast path, which should
>> address some of these concerns. It's still not a bump-pointer
>> allocator, but at least there are no atomics on that path.
>
> Since which version of glibc is there a thread-local fast path?
It was added i
* Jonathon Anderson:
> On Sun, Oct 27, 2019 at 09:59, Florian Weimer wrote:
>> * Mark Wielaard:
>>
>>>> Current glibc versions have a thread-local fast path, which should
>>>> address some of these concerns. It's still not a bump-pointer
>>&
* Frank Ch. Eigler:
> +inline bool
> +string_endswith(const string& haystack, const string& needle)
> +{
> + return (haystack.size() >= needle.size() &&
> + haystack.substr(haystack.size()-needle.size()) == needle);
> +}
I think you should use std::equal because substr allocations. So
som
* Florian Weimer:
> * Frank Ch. Eigler:
>
>> +inline bool
>> +string_endswith(const string& haystack, const string& needle)
>> +{
>> + return (haystack.size() >= needle.size() &&
>> + haystack.substr(haystack.size()-needle.size())
* Mark Wielaard:
> For some reason gcc might fail to recognize the assert (0) will never
> return and emit an implicit-fallthrough warning. Just add a break to
> silence it.
Is this with -DNDEBUG? assert (0) expands to basically nothing in that
case. I'm not sure if we should change that. We c
* Frank Ch. Eigler:
> - return string(hostname) + string(":") + string(servname);
> + // extract headers relevant to administration
> + const char* user_agent = MHD_lookup_connection_value (conn,
> MHD_HEADER_KIND, "User-Agent") ?: "";
> + const char* x_forwarded_for = MHD_lookup_connection_v
* Frank Ch. Eigler:
> Hi -
>
> I'm planning to commit this shortly:
>
> From 4ebefc8f3b4b8fb68a55c960e70122fda50a0fb9 Mon Sep 17 00:00:00 2001
> From: "Frank Ch. Eigler"
> Date: Sat, 7 Dec 2024 15:01:54 -0500
> Subject: [PATCH] debuginfod: add CORS response headers and OPTIONS method
What are th
* William Cohen:
> The dwfl_report_proc_map() will handle when things are added to the
> memory map. Is there anything to handle the inverse event when memory
> is removed from the process memory map, such as a dlcose()?
If there's something we can do here on the glibc side, please let us
know.
* Mark Wielaard:
> + [AC_MSG_ERROR([__cxa_demangle not found in libstdc++ use
> --disable-demangler to disable demangler support.])]),
Missing punctuation after libstdc++?
Thanks,
Florian
* Mark Wielaard:
> Hi Florian,
>
> On Thu, 2023-02-16 at 11:48 +0100, Florian Weimer via Elfutils-devel
> wrote:
>> * Mark Wielaard:
>>
>> > + [AC_MSG_ERROR([__cxa_demangle not found in libstdc++ use
>> > --disable-demangler to disable demangle
Include for the pause function, and add the return type
of main. Avoids an implicit function declaration and implicit int.
Signed-off-by: Florian Weimer
---
Related to:
<https://fedoraproject.org/wiki/Changes/PortingToModernC>
<https://fedoraproject.org/wiki/Toolchain/Porting
* Luke Diamand via Elfutils-devel:
> I've got a few cores where report_r_debug() in link_map.c fails to
> find all of the modules - for example I had libc.so missing. This
> obviously meant that elfutils could not backtrace my core.
>
> It seems to be related to this code:
>
> /* There can't be
* Érico Nogueira via Libc-alpha:
> This is mostly an initial PoC, and an additional comment for why this
> is needed could be added to the file.
>
> I accidentally sent the wrong patch a while ago, sorry!
extern "C++" does not have any effect for this header because it does
not declare anything t
* Rich Felker:
> As I stated in my other reply, I'm opposed to that because it does not
> admit implementation with the same (very desirable) big-O properties,
> and the "extmatch" syntax is not widely known or widely used.
The syntax comes from ksh and is used in shell scripts. (bash requires
t
* Mark Wielaard:
> Hi Manoj,
>
> On Sat, 2021-02-06 at 07:03 +, Manoj Kumar via Elfutils-devel
> wrote:
>> Hi,Using dyninst, I am trying to access local variables and arguments
>> of a function which is part of a go binary.To get local variables,
>> dyninst uses libdw to find all the modules.
* Dmitry V. Levin:
> Let's make clear what's going on here. First of all, dwfl-proc-attach.c
> does not use dlopen so it doesn't pull it in and doesn't need -ldl.
> In regular builds, dwfl-proc-attach.o is linked with ../libdw/libdw.so
> which in turn uses dlopen and is already linked with -ldl.
* Frank Ch. Eigler via Elfutils-devel:
> Hi -
>
> On Tue, Nov 30, 2021 at 12:25:41PM +0100, Mark Wielaard wrote:
>> [...]
>> The spec does explain the requirements for JSON numbers, but doesn't
>> mention any for JSON strings or JSON objects. It would be good to also
>> explain how to make the str
* Frank Ch. Eigler:
>> > Yes, and yet we have had the bidi situation recently where UTF-8 raw
>> > codes could visually confuse a human reader whereas escaped \u
>> > wouldn't. If we forbid \u unilaterally, we literally become
>> > incompatible with JSON (RFC8259 7. String. "Any character
* Evgeny Vereshchagin:
> ASan, UBSan and MSan provided by clang aren't compatible with --no-undefined
> and -z,defs:
> https://clang.llvm.org/docs/AddressSanitizer.html#usage
> https://github.com/google/sanitizers/issues/380
> so to build elfutils with clang with the sanitizers it should be possi
* Mark Wielaard:
> This seems a wrong warning since we aren't accessing the field member
> of the struct, but are taking the address of it. But we can do the
> same by adding the field offsetof to the base address. Which doesn't
> trigger a runtime error.
I think the warning is correct. I believ
* Mark Wielaard:
> Hi,
>
> On Thu, Mar 31, 2022 at 04:00:16PM +0300, Catalin Raceanu via curl-library
> wrote:
>> On 31-Mar-22 15:04, Mark Wielaard wrote:
>> > whether there is a thread-safe way to call
>> > curl_global_init at a later time (to get rid of the library constructor
>> > init functio
41 matches
Mail list logo
