jimingham wrote:
> On Jan 18, 2024, at 8:41 AM, Pavel Labath ***@***.***> wrote:
>
>
> Will the value of ObjectFile::GetType ever be meaningful, then?
>
> It's partially meaningful. eTypeCoreFile, eTypeObjectFile and eTypeExecutable
> (when it is set) should mean what they say. The problem
labath wrote:
> Will the value of ObjectFile::GetType ever be meaningful, then?
It's partially meaningful. eTypeCoreFile, eTypeObjectFile and eTypeExecutable
(when it is set) should mean what they say. The problem is with
eTypeSharedLibrary (and to a lesser degree with eTypeDebugInfo). Just b
jimingham wrote:
So long as ObjectFileELF::CalculateType never returns ET_EXEC, this won't be an
issue. But if some ObjectFile that's not in fact the main binary says it has
this type, not only will this change to Append not do the right thing,
Target::GetExecutableModule will also return thi
jimingham wrote:
Will the value of ObjectFile::GetType ever be meaningful, then? Do you change
it after running based on what the loader tells you? If that's not meaningful,
then we probably should have some "ObjectFile::TypeIsMeaningful" and gate all
this logic on that as well.
Jim
> On
jimingham wrote:
This one should have been fixed by the follow-on commit. When you use a shared
library on Linux you have to bless it somehow - which in the test suite means
adding an "extra_images" argument to run_to_***_breakpoint, which I forgot to
do.
Jim
> On Jan 17, 2024, at 12:17 AM
labath wrote:
The problem is that linux/elf does not really have hard line between shared
libraries, (position-independent) executables and the dynamic linker. they all
have `e_type = ET_DYN` in their header. It is possible to create a shared
library that can also be executed (unless one is *e
petrhosek wrote:
`lldb-api :: functionalities/executable_first/TestExecutableFirst.py` is
failing on our Linux builders with the following error:
```
Script:
--
/b/s/w/ir/x/w/lldb_install/python3/bin/python3
/b/s/w/ir/x/w/llvm-llvm-project/lldb/test/API/dotest.py -u CXXFLAGS -u CFLAGS
--env AR
https://github.com/JDevlieghere approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/78360
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg approved this pull request.
Looks good to me.
https://github.com/llvm/llvm-project/pull/78360
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/78360
>From 4d53ea53a9a5d9344d41195697b3b98359af1ede Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Tue, 16 Jan 2024 14:33:29 -0800
Subject: [PATCH 1/2] Ensure that the executable module is ModuleList[0]
We claim i
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 32dd5b20973bde1ef77fa3b84b9f85788a1a303a
4d53ea53a9a5d9344d41195697b3b98359af1ede --
github-actions[bot] wrote:
:warning: Python code formatter, darker found issues in your code. :warning:
You can test this locally with the following command:
``bash
darker --check --diff -r
32dd5b20973bde1ef77fa3b84b9f85788a1a303a...4d53ea53a9a5d9344d41195697b3b98359af1ede
lldb/
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jimingham)
Changes
We claim in a couple places that the zeroth element of the module list for a
target is the main executable, but we don't actually enforce that in the
ModuleList class. As we saw, for instance, in
32dd5b20973bde1e
https://github.com/jimingham created
https://github.com/llvm/llvm-project/pull/78360
We claim in a couple places that the zeroth element of the module list for a
target is the main executable, but we don't actually enforce that in the
ModuleList class. As we saw, for instance, in
32dd5b20973
14 matches
Mail list logo
